zfs device evacuation/removal
This project allows top-level vdevs to be removed from the storage pool with “zpool remove”, reducing the total amount of storage in the pool. This operation copies all allocated regions of the device to be removed onto other devices, recording the mapping from old to new location. After the removal is complete, read and free operations to the removed (now “indirect”) vdev must be remapped and performed at the new location on disk. The indirect mapping table is kept in memory whenever the pool is loaded, so there is minimal performance overhead when doing operations on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries become “obsolete” because they are no longer used by any block pointers in the pool. An entry becomes obsolete when all the blocks that use it are freed. An entry can also become obsolete when all the snapshots that reference it are deleted, and the block pointers that reference it have been “remapped” in all filesystems/zvols (and clones). Whenever an indirect block is written, all the block pointers in it will be “remapped” to their new (concrete) locations if possible. This process can be accelerated by using the “zfs remap” command to proactively rewrite all indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of the data that is copied. This makes the process much faster, but if it were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be possible to copy the wrong data, when we have the correct data on e.g. the other side of the mirror. Therefore, mirror and raidz devices can not be removed.
Updated by Electric Monk almost 6 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 5cabbc6b49070407fb9610cfe73d4c0e0dea3e77 Author: Prashanth Sreenivasa <firstname.lastname@example.org> Date: 2018-01-10T16:00:10.000Z 7614 zfs device evacuation/removal Reviewed by: Alex Reece <email@example.com> Reviewed by: George Wilson <firstname.lastname@example.org> Reviewed by: John Kennedy <email@example.com> Reviewed by: Prakash Surya <firstname.lastname@example.org> Reviewed by: Matthew Ahrens <email@example.com> Reviewed by: Richard Laager <firstname.lastname@example.org> Reviewed by: Tim Chase <email@example.com> Approved by: Garrett D'Amore <firstname.lastname@example.org>