My primary array currently has 3 18 TB SATA drives in Z1 and as now have 5 18 TB SAS drives that I want to use to replace them with, also in Z1.
If at all possible I would prefer to keep the Pool the same with the same path and name.
I know if it was the same number of drives I could do a slow but sure 1 by 1 replace and resilver but I don’t see how that would work when adding 2 extra drives.
It know it’s possible to add a new ZVOL to the pool with the new drives in a Z1 arrangement for expansion; but is it possible to force the data to move to it?
I think you’re thinking of a vdev, and you’d need at least three disks to do that.
You can simply add the two disks, one at a time, to your vdev, following the guide Samuel linked, and then replace the other three, leaving you with a five-wide RAIDZ1 vdev. However, RAIDZ expansion keeps the existing data:parity ratio for any existing data, and often results in available space being reported incorrectly. You can address this, at least to a degree, using zfs rewrite, as described in more detail here:
This does not re-stripe data, at least according to the manual page. This “rewrite” applies to blocks, not files, so it can’t really re-stripe the file to any newly expanded RAID-Zx width.
While that command is useful, the old full copy script DOES re-stripe the data blocks in a file. Further, it appears that “rewrite” does not change block size, but the old fully copy script should do so.
Thanks for the clarification. So would it be safe to say that zfs rewrite would be beneficial to, e.g., rebalance data when you add a new vdev to a pool, but not to address RAIDZ expansion?
Wow, first I heard of this and it doesn’t seem to exist on my CORE installation, but is available on my FreeBSD 15.0 server so this must be relatively new.
Does that mean that you can now rebalance your pool simply by doing zfs rewrite -r /path/to/dataset?
Seems only to operate at the file level, instead of the dataset or pool level. Probably need to use find /mnt/<pool name> -execdir zfs rewrite '{}' \; to apply it to the pool.
And to re-do compression, checksum, copies and de-dup, within existing ZFS blocks for files.
Probably. I’ve not used such, but it seems to be the proper tool.
We probably need a standard blurb about how RAID-Zx writes data, including the variable width stripes. And that you can have large files, like a 1GB file that if written slowly, (like a log file), would end up using small stripes. Even single data column stripes. Thus, more metadata and parity that if it was copied as a single operation.
Sorry to toss a monkey wrench here, but if possible i would suggest creating a separate pool and duplicate of the datasets and then doing some sore of ZFS renaming operations might be safer if possible.
It’s too late for this operation but I will have other pools to move.
I didn’t think it was possible to rename pools safely.
What would your method be here?
