|
|
|
|
|
by cyphar
2339 days ago
|
|
The first operations I mentioned (adding or removing a device from a vdev, or adding a new vdev) are one command with no downtime: % zpool attach <pool> <vdev> <device> // add to a vdev
% zpool detach <pool> <vdev> <device> // remove from a vdev
% zpool add <pool> <vdev> <devices...> // add a new vdev
In the newest ZFS versions, you can also remove mirror and singleton vdevs (this does require some time -- because the data needs to be copied from the drives) but it's all done in the background: % zpool remove <pool> <vdev>
Shrinking a pool "the old way" (which is still sometimes necessary depending on what you're doing) is definitely more involved -- you have to create a new pool with the layout you need and then do a zfs send/recv from your old pool to the new one. This does only take a handful of commands but I would definitely consider it to be a much more complicated affair than the operations I mentioned above.I would not (nor did I) compare LVM (or md-raid) to btrfs or ZFS -- those technologies have fundamental limitations regarding the integrity of your data that ZFS (and btrfs) don't have. And don't get me wrong -- I don't have a problem with btrfs (I run btrfs on all of my machines except my home server -- which runs ZFS), I just disagree with GP's point that ease of use is an argument for btrfs over ZFS. There are many arguments for either technology. > btrfs is also mainline, which increases how painless it is to use. I agree that this is one argument to pick btrfs over ZFS (though on most distributions it isn't really that hard to install ZFS, the fact that btrfs requires zero extra work to use on Linux is a benefit). |
|