Don't excise DTLs from unreadable vdev #2613
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
An offline or unreadable vdev may trip the following assertion
during a resilver scan in ztest:
ztest: ../../module/zfs/vdev.c:1746: Assertion
`scn->scn_phys.scn_min_txg <= vdev_dtl_min(vd) (0x4e3 <= 0x3)' failed.
child died with signal 6
The following analysis is by George Wilson:
The current scan is only resilvering a few txgs [70f, 711] but yet
this vdev has a min txg of 3. The problem is that this vdev is
currently not readable and as a result when the scan that was doing
the resilver it actually finished but didn't copy any of the data to
this device.
Now a second scan comes through and the device is still offline (ie.
not readable) so once again this device was did not have any data
copied over to it. This time when we check if we should excise the
DTLs from this device we determine we should since the scan is for a
txg much higher than the max value in this device's dtl range but we
end up tripping over this assertion:
If the device is not readable than we don't want to ever excise any
of its dtls so we should return B_FALSE and not even bother with
anything further.
References: https://www.illumos.org/issues/4890
Issue #2302
Signed-off-by: Ned Bass [email protected]