Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

nopwrites on dmu_sync-ed blocks can result in a panic #8957

Merged
merged 1 commit into from
Jun 28, 2019
Merged

nopwrites on dmu_sync-ed blocks can result in a panic #8957

merged 1 commit into from
Jun 28, 2019

Conversation

grwilson
Copy link
Member

After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:

  1. an attempt to issue an IOCTL in vdev_indirect_io_start()
  2. a failed comparison of zio->io_bp and zio->io_bp_orig in
    zio_done()
    To resolve both of these panics, nopwrites of blocks on indirect
    vdevs should be ignored and new allocations should be performed on
    concrete vdevs.

Signed-off-by: George Wilson gwilson@delphix.com

@behlendorf behlendorf added the Status: Code Review Needed Ready for review and testing label Jun 25, 2019
@codecov
Copy link

codecov bot commented Jun 26, 2019 •
edited
Loading

Codecov Report

Merging #8957 into master will increase coverage by 0.22%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8957      +/-   ##
==========================================
+ Coverage   78.54%   78.76%   +0.22%     
==========================================
  Files         388      388              
  Lines      119950   119886      -64     
==========================================
+ Hits        94213    94428     +215     
+ Misses      25737    25458     -279
Flag Coverage Δ
#kernel 79.46% <100%> (+0.04%) ⬆️
#user 66.75% <71.42%> (+0.65%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 679b0f2...0f7a60b. Read the comment docs.

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Jun 26, 2019
@grwilson
nopwrites on dmu_sync-ed blocks can result in a panic
0f7a60b 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Signed-off-by: George Wilson <gwilson@delphix.com>
@behlendorf behlendorf merged commit 681a85c into openzfs:master Jun 28, 2019
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Aug 13, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
cba2b75 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes openzfs#8957
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Aug 22, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
92cb882 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes openzfs#8957
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Aug 23, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
569ed30 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes openzfs#8957
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Sep 17, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
f7d40b9 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes openzfs#8957
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Sep 18, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
fe8be51 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes openzfs#8957
tonyhutter pushed a commit that referenced this pull request Sep 26, 2019
@grwilson @tonyhutter
nopwrites on dmu_sync-ed blocks can result in a panic
7d2489c 
After device removal, performing nopwrites on a dmu_sync-ed block
will result in a panic. This panic can show up in two ways:
1. an attempt to issue an IOCTL in vdev_indirect_io_start()
2. a failed comparison of zio->io_bp and zio->io_bp_orig in
   zio_done()
To resolve both of these panics, nopwrites of blocks on indirect
vdevs should be ignored and new allocations should be performed on
concrete vdevs.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
Closes #8957
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@behlendorf behlendorf behlendorf approved these changes

@ikozhukhov ikozhukhov ikozhukhov approved these changes

@pzakha pzakha pzakha approved these changes

@don-brady don-brady don-brady approved these changes

Assignees
No one assigned
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@grwilson @behlendorf @ikozhukhov @pzakha @don-brady