aboutsummaryrefslogtreecommitdiffstats
path: root/module/zfs/rrwlock.c
diff options
context:
space:
mode:
authorBrian Behlendorf <[email protected]>2019-01-18 09:47:55 -0800
committerGitHub <[email protected]>2019-01-18 09:47:55 -0800
commitce5fb2a7c6dfaa0f305350225e064e9f536bd5a4 (patch)
tree1f261b032893082bce42db884e5dff0325e7a3ee /module/zfs/rrwlock.c
parent305781da4bbe11acef8707894d7e33f8aef3ca8e (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