Any downsides to mixed vdev sizes?

[Fish]

I've got a pool which is just a pair of mirrored 12TB drives currently. I'm looking to expand this to include another mirrored pair of drives.

Prices of drives have of course dropped since I built this pool so I can get 16TB drives now and stay within my budget. Are there any downsides to having a 12TB vdev and 16TB vdev in a pool together?

Also, will single files get striped across multiple vdevs? Could I theoretically lose 1 disk from each vdev and not lose any data?

 

[Stux]

yeah, files sortof get sprayed across the available vdevs, more or less, and thus get striped across the available vdevs. And yes, you could lose 1 disk from each vdev and not lose any data.

And yes, might as well go for the 16TB for your next vdev.

Obviously, if you think about it:

1) files already on the 12TB vdev will not reflow across to the 16TB
2) your 16TB vdev will have more space available and is larger, so will be able to store more... so more blocks should land on the 16TB in the future...

Ie its more likely the spray will land on the larger faster emptier vdev.

 

[Fish]

I should also mention that the pool is a bit older and I always get notifications that there are new features available if I do a zpool upgrade. Would it make sense then to:

- add the new vdev
- upgrade the pool
- move the existing datasets off the pool, then back on, in order to distribute the writes evenly and take advantage of any new features

 

[Stux]

I should also mention that the pool is a bit older and I always get notifications that there are new features available if I do a zpool upgrade. Would it make sense then to:

- add the new vdev
- upgrade the pool
- move the existing datasets off the pool, then back on, in order to distribute the writes evenly and take advantage of any new features

Yes. I think that would optimize the preexisting data

 

[Etorix]

Just backup, destroy the old pool and recreate it with the new vdev: It will have the current feature set.

 

[Fish]

Just backup, destroy the old pool and recreate it with the new vdev: It will have the current feature set.

I would do that if I had enough free space on other pools, but I don't. Only enough space to juggle a dataset at a time

 

[Stux]

I would do that if I had enough free space on other pools, but I don't. Only enough space to juggle a dataset at a time

Is it worth it?

I never bother personally. If speed were that important you’d be using SSD.

And I have 9 mirrors so far ;)

 

[Jailer]

Just backup, destroy the old pool and recreate it with the new vdev: It will have the current feature set.

Why on earth would you go through the hassle of doing that when a simple zpool upgrade poolname would do the same thing nearly instantaneously?

 

[Etorix]

Because OP also wanted to rebalance data across vdevs…

 

[Jailer]

Because OP also wanted to rebalance data across vdevs…

Ok I missed that part. Personally though I think for most users re balancing data is a fools errand. Now in an enterprise situation doing block storage it may make sense for performance and fragmentation reasons. But for an average user accessing data over 1Gb connection it doesn't make much sense to me.

But then again I'm just a hobbyist/home user and not in the tech biz so take my opinion for what it's worth.

 

[Davvo]

Generally you want to zpool upgrade only if you want a specific new feature. You won't have any significant downside with mirrors of different sizes besides someone's OCD flaring up.
If you want to rebalance you can use the following script.

GitHub - markusressel/zfs-inplace-rebalancing: Simple bash script to rebalance pool data between all mirrors when adding vdevs to a pool.

Simple bash script to rebalance pool data between all mirrors when adding vdevs to a pool. - markusressel/zfs-inplace-rebalancing

github.com