Hacker News Reader

Comment by ScottBurson | Hacker News Reader

There is another way to grow a pool: replace each disk with a larger one, resilvering after each replacement.

But yeah, sizing your pool very generously when first building it is a good idea. I found that 6x 4TB drives in a raidz2 pool was within my budget, and it will take me a long time to fill 16TB.

View on HN

What does the gp mean by saying there's no way to resize a pool? You can resize a pool by adding disks like you say, so what's the alternative? Resizing by only adding one disk? But it's RAID-Z, where will the parity go? Does anyone support this use case?

Btrfs supports it. The parity stays exactly where it is, but new files will use the new device. You can (and far too often have to, when btrfs decides there is no free space left) also perform a 'balance' operation, which recreates all the b-trees on the disks, optionally with different parity options.

Hmm, I don't understand how that's possible on RAID-Z? You can only have as much space per disk as the parity, no? I.e. you can't have three 500 GB disks for a total of 1 GB space, and replace one with a 1 GB disk and get more space, can you?

The idea is to add disks rather than replace. So to go from 3x500GB to 4x500GB.

Oh, I see. In that case, it's odd to me that ZFS doesn't support that, hmm.

Well, it was designed for by a company targeting enterprise customers. I guess this feature would be secondary for that market.

That doesn't make much sense, how can you change parity on the fly? I suspect it does the same thing as ZFS; it just adds another vdev

For each chunk of on-disk data, the fs stores which devices it is stored on and the used parity configuration. You can take one such chunk of data, and clone it into a new chunk with identical contents but a different parity configuration in the free space of the devices that are part of the file system. (Just like you'd allocate new chunks for storing new files in the same parity configuration). Once that copy is created, all references to the old chunk are changed to point to the new chunk and so the old chunk is now free space. Repeat this process for all chunks in the file system, and the whole file system is converted to use a different parity configuration.

SnapRAID and BTRFS both support adding disks.

On BTRFS you simply use the new space or rebalance the pool to use the new disk properly.

On SnapRAID the next scan will add the disk to the parity drive contents.

For low-cost home usage, it is much much more cost effective to only buy single disks and start with small pools over buying large pools or even replacing entire pools.

Since I presume you have verifiable backups of your pool couldn't you just remake the pool with the increased number of disks and copy back to it?

Recovering from my current backup solution is expensive, the additional cost is not worth it.

Remaking the entire pool is also a hassle and incurs unnecessary downtime.

Additionally, not all data is backed up, which I will loose, as this is not important data, it's okay to loose during a house fire, but not just for resizing the disk.

Lastly, this operation would likely take a long time, days probably, I'd rather just be able to just ram in another disk and be done with it.

I had assumed you would have a second array as backup for the current pool ensuring zero data loss and easy backup. This would seem to be optimal. Remote backup is obviously a good thing to have too.

Such a solution is extremely expensive and inefficient for a home setup.

All things considered your house will probably never experience a major disaster remote storage has got to be many times more expensive.

Remote storage is on B2, several Terabytes, it's not very expensive, restoring however is.

Reply on news.ycombinator.com