Looks like we need to modify that
zfs-inplace-rebalancing script to have `cp --reflink=never` with OpenZFS 2.2 because of how file copies work on datasets in the pool.
I'm also uncertain if it messes with file creation times.
I think transferring the pool and transferring it back seems like the safest and fastest approach. One of my datasets is ~30 TiB, and that has me worried, but I have enough space to make the transition as well as a bunch of large drives on-tap. Since this is a mirrored pool, it's a simple `zpool add`.
For the script, I'm thinking something like this:
Code:
zfs snap -r POOL/DATASET@backupTransfer # Creates a snapshot for transferring this dataset.
zfs send -RLI POOL/DATASET@backupTransfer | pv -Wbraft | zfs recv -Fuv -o recordsize=1M POOL/DATASET.new # Copies all data to a new dataset.
zfs destroy -rv POOL/DATASET@backupTransfer # Destroys the temporary snapshot.
zfs destroy -rv POOL/DATASET.new@backupTransfer # Destroys the temporary snapshot.
zfs destroy -rv POOL/DATASET@* # Destroys all snapshots in the original dataset.
zfs destroy -v POOL/DATASET # Destroys the original dataset.
zfs rename POOL/DATASET.new POOL/DATASET # Subs in the new dataset in place of the old one.
This is a combination of both your suggestions.
Is this safe?
With `zfs send -L`, I don't have to get rid of any snapshots either, it'll transfer all of them!
Is there an easy way to
restart from where I left off if I have to restart the server during one of these? `-I` enables restarting, but I don't know how to capture the last snapshot. Is it in the logs?
When I do `zfs recv -o recordsize=16M`, does that create the new pool at 16M, or does it only do it for the data I'm sending, and I have to set the dataset to 16M separately?
To make this a bit safer, I think it'd be good to run the first 4 steps (where it takes a snapshot and sends) twice. That way, if any changes come in right as the dataset is being deleted, it ensures they get pulled over.