mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2026-05-24 19:28:53 +03:00
RAID-Z expansion feature
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 Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Mark Maybee <mark.maybee@delphix.com> Authored-by: Matthew Ahrens <mahrens@delphix.com> Contributions-by: Fedor Uporov <fuporov.vstack@gmail.com> Contributions-by: Stuart Maybee <stuart.maybee@comcast.net> Contributions-by: Thorsten Behrens <tbehrens@outlook.com> Contributions-by: Fmstrat <nospam@nowsci.com> Contributions-by: Don Brady <dev.fs.zfs@gmail.com> Signed-off-by: Don Brady <dev.fs.zfs@gmail.com> Closes #15022
This commit is contained in:
+20
-12
@@ -767,6 +767,14 @@ as soon as it is enabled and will never return to being
|
||||
.Sy disabled .
|
||||
\*[remount-upgrade]
|
||||
.
|
||||
.feature org.openzfs raidz_expansion no none
|
||||
This feature enables the
|
||||
.Nm zpool Cm attach
|
||||
subcommand to attach a new device to a RAID-Z group, expanding the total
|
||||
amount usable space in the pool.
|
||||
See
|
||||
.Xr zpool-attach 8 .
|
||||
.
|
||||
.feature com.delphix redaction_bookmarks no bookmarks extensible_dataset
|
||||
This feature enables the use of redacted
|
||||
.Nm zfs Cm send Ns s ,
|
||||
@@ -784,6 +792,18 @@ and so cannot be safely mounted, and their contents cannot be safely read.
|
||||
For more information about redacted receives, see
|
||||
.Xr zfs-send 8 .
|
||||
.
|
||||
.feature com.delphix redaction_list_spill no redaction_bookmarks
|
||||
This feature enables the redaction list created by zfs redact to store
|
||||
many more entries.
|
||||
It becomes
|
||||
.Sy active
|
||||
when a redaction list is created with more than 36 entries,
|
||||
and returns to being
|
||||
.Sy enabled
|
||||
when no long redaction lists remain in the pool.
|
||||
For more information about redacted sends, see
|
||||
.Xr zfs-send 8 .
|
||||
.
|
||||
.feature com.datto resilver_defer yes
|
||||
This feature allows ZFS to postpone new resilvers if an existing one is already
|
||||
in progress.
|
||||
@@ -947,18 +967,6 @@ once all filesystems that have ever had their
|
||||
property set to
|
||||
.Sy zstd
|
||||
are destroyed.
|
||||
.
|
||||
.feature com.delphix redaction_list_spill no redaction_bookmarks
|
||||
This feature enables the redaction list created by zfs redact to store
|
||||
many more entries.
|
||||
It becomes
|
||||
.Sy active
|
||||
when a redaction list is created with more than 36 entries,
|
||||
and returns to being
|
||||
.Sy enabled
|
||||
when no long redaction lists remain in the pool.
|
||||
For more information about redacted sends, see
|
||||
.Xr zfs-send 8 .
|
||||
.El
|
||||
.
|
||||
.Sh SEE ALSO
|
||||
|
||||
Reference in New Issue
Block a user