Open
Description
Describe the problem you're observing
Device removal (of top-level vdevs) doesn't work with pools that have RAIDZ vdevs. This violates the principle of "everything works with everything else", i.e. all ZFS features interoperate cleanly.
Here are some aspects of a potential solution:
- Remove checks that prevent operation with raidz, add checks that all vdevs are the same "type" (e.g. same number of disks in each raidz group, same amount of parity in each raidz group) and ensure that vdev manipulation works correctly with raidz (e.g. replacing the raidz vdev with the indirect vdev).
- On RAIDZ, allocations of "continuation" segments must be properly aligned. I.e. if the first allocation for a segment ends on child 2, then the allocation for the remainder of this segment must begin on child 3. This ensures that a "split block" (which spans two mapping segments) does not have its data and parity unevenly distributed among the blocks, which could cause us to be unable to reconstruct it if a device fails.
- On RAIDZ, allocations must be a multiple of P+1 (i.e. one more than the number of parity devices). Therefore we can only split a chunk at a multiple of P+1 sectors from the beginning of the chunk. Combined with the above requirement, this substantially constrains where the remainder of a split block can start – in the worst case it must be aligned to N*(P+1) (N=devices in group; P=parity count)
- Once RAIDZ expansion integrates (see [WIP] raidz expansion, alpha preview 1 #8853), it should be possible to support removing a RAIDZ vdev where the remaining vdevs are wider than the removed vdev.