diff options
author | Brian Behlendorf <[email protected]> | 2019-01-18 09:47:55 -0800 |
---|---|---|
committer | GitHub <[email protected]> | 2019-01-18 09:47:55 -0800 |
commit | ce5fb2a7c6dfaa0f305350225e064e9f536bd5a4 (patch) | |
tree | 1f261b032893082bce42db884e5dff0325e7a3ee /module/zfs/rrwlock.c | |
parent | 305781da4bbe11acef8707894d7e33f8aef3ca8e (diff) |
ztest: scrub verification
By design ztest will never inject non-repairable damage in to the
pool. Update the ztest_scrub() test case such that it waits for
the scrub to complete and verifies the pool is always repairable.
After enabling scrub verification two scenarios were encountered
which are the result of how ztest manages failure injection.
The first case is straight forward and pertains to detaching a
mirror vdev. In this case, the pool must always be scrubbed prior
the detach. Failure to do so can potentially lock in previously
repairable data corruption by removing all good copies of a block
leaving only damaged ones.
The second is a little more subtle. The child/offset selection
logic in ztest_fault_inject() depends on the calculated number of
leaves always remaining constant between injection passes. This
is true within a single execution of ztest, but when using zloop.sh
random values are selected for each restart. Therefore, when ztest
imports an existing pool it must be scrubbed before failure injection
can be safely enabled. Otherwise it is possible that it will inject
non-repairable damage.
Reviewed by: Matt Ahrens <[email protected]>
Reviewed by: Tom Caputi <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes #8269
Diffstat (limited to 'module/zfs/rrwlock.c')
0 files changed, 0 insertions, 0 deletions