zfs-tests: Fix raidz_003/004_pos.ksh kill after timeout expiration #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn't sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks). == Initiating expansion == A new device (disk) can be attached to an existing RAIDZ vdev, by running `zpool attach POOL raidzP-N NEW_DEVICE`, e.g. `zpool attach tank raidz2-0 sda`. The new device will become part of the RAIDZ group. A "raidz expansion" will be initiated, and the new device will contribute additional space to the RAIDZ group once the expansion completes. The `feature@raidz_expansion` on-disk feature flag must be `enabled` to initiate an expansion, and it remains `active` for the life of the pool. In other words, pools with expanded RAIDZ vdevs can not be imported by older releases of the ZFS software. == During expansion == The expansion entails reading all allocated space from existing disks in the RAIDZ group, and rewriting it to the new disks in the RAIDZ group (including the newly added device). The expansion progress can be monitored with `zpool status`. Data redundancy is maintained during (and after) the expansion. If a disk fails while the expansion is in progress, the expansion pauses until the health of the RAIDZ vdev is restored (e.g. by replacing the failed disk and waiting for reconstruction to complete). The pool remains accessible during expansion. Following a reboot or export/import, the expansion resumes where it left off. == After expansion == When the expansion completes, the additional space is available for use, and is reflected in the `available` zfs property (as seen in `zfs list`, `df`, etc). Expansion does not change the number of failures that can be tolerated without data loss (e.g. a RAIDZ2 is still a RAIDZ2 even after expansion). A RAIDZ vdev can be expanded multiple times. After the expansion completes, old blocks remain with their old data-to-parity ratio (e.g. 5-wide RAIDZ2, has 3 data to 2 parity), but distributed among the larger set of disks. New blocks will be written with the new data-to-parity ratio (e.g. a 5-wide RAIDZ2 which has been expanded once to 6-wide, has 4 data to 2 parity). However, the RAIDZ vdev's "assumed parity ratio" does not change, so slightly less space than is expected may be reported for newly-written blocks, according to `zfs list`, `df`, `ls -s`, and similar tools. Sponsored-by: The FreeBSD Foundation Sponsored-by: iXsystems, Inc. Sponsored-by: vStack Authored-by: Matthew Ahrens <[email protected]> Contributions-by: Fedor Uporov <[email protected]> Contributions-by: Stuart Maybee <[email protected]> Contributions-by: Thorsten Behrens <[email protected]> Contributions-by: Fmstrat <[email protected]> Contributions-by: Don Brady <[email protected]> Signed-off-by: Don Brady <[email protected]>
Add support to zloop to drive testing raidz expansion In the ZTS test, make sure to reset RAIDZ_EXPAND_MAX_OFFSET_PAUSE Signed-off-by: Don Brady <[email protected]>
- The test no longer takes a guessed value. It stops at 25,50 and 75 percent of reflow amount. - Simplified the way we fill up the pool in ztest_rzx_thread. - Refactored ztest_raidz_expand_run and ztest_run to remove duplicate code Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]> Requires-builders: arch,style,centos7,centos8,fedora38,freebsd13,coverage
Also add ztest -X to zloop mix Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Make scratch object verification logic more robust to decrease number of verification assertions triggering. Remove reflow pause from verification logic and add additional scratch object states. Implement verification based on these new scratch states added. Signed-off-by: Don Brady <[email protected]>
also remove more diagnostic logging Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
also fixed some comment typos Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
Signed-off-by: Don Brady <[email protected]>
don-brady
force-pushed
the
raidz-expansion
branch
from
7dfb7a1 to
c3f8a29
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
It is happen because vdev_raidz_map_alloc_expanded() is used by raidz_test and the test timings increase multiple times.
The sweep mode (-S) in raidz_test basically contain three phases:
When all tasks were started (https://github.com/don-brady/openzfs/blob/raidz-expansion/cmd/raidz_test/raidz_test.c#L767), there is no way to stop raidz_test by timeout expiration event, like in case of tasks creation/starting (https://github.com/don-brady/openzfs/blob/raidz-expansion/cmd/raidz_test/raidz_test.c#L729).
Add check, that sweep test timeout expired.