Unsure of what to do re: increase vdev size after creation

[copeland3300]

Hey all,

I've been poking around for a bit and I can't seem to find a good answer to my question.

Right now I have 6 3TB drives that I have configured into a RAIDZ2.
I'd like to have the capacity to add disks to this later, but I know you can't add disks to a vdev after it's created, so my options are limited. I also know that you can swap out all of the disks one by one with bigger drives at a later date to expand the pool size. I'll probably end up going this route, honestly.

I've seen mention of creating sparse files to take the place of a disk until you add a real drive to the system, but I know that cyberjock hates this topic, and it's outside of the proper operating environment for the product.

M question remains: what would a person do if they wanted to expand with more disks later and didn't want to either kill their vdev and start over nor did they want to buy several more disks and create a second vdev as a RAIDZ2. Is there any way at the moment around this limitation?

Thanks!

 

[jgreco]

No, there is no practical way around this at the current time.

 

[Jailer]

Backup your data, destroy your pool and start over.

Other than replacing your disks one at a time as you stated that's the only way to do what you are describing without adding an additional vdev to your pool.

Boy I haven't been around this forum or freenas for very long but I've see this a lot already. Plan your storage needs and create your vdevs and pools accordingly.

 

[jgreco]

Backup your data, destroy your pool and start over.

I stand corrected, there is one practical way around this. ;-)

 

[DKarnov]

I think there's an issue with semantics here.

No, you can't add disks to a vdev. Yes, you can add vdevs to an existing pool, although this can make things messier down the line. No, your second vdev does not need to be the same kind as your first, so if you're cheap, you can add a two-disk mirror vdev to a pool with your existing six-disk Z2.

Or if you just want added storage space in your NAS you can just create a second pool and add whatever disks in whatever vdev format you want, without affecting your existing pool. No, the data won't be contiguous, but if you have datasets that will fit on the new pool you can just replicate them over and change the share mounts. It isn't the most elegant situation but for small-scale users it shouldn't be a big deal.

(Obviously these are all limited by physical chassis / power supply / SATA port etc constraints.)

 

[Jailer]

Yes, you can add vdevs to an existing pool, although this can make things messier down the line.

Can you expalin this please? From what I understand this is one of the areas where ZFS shines is in it's management of multiple vdevs and large pools.

 

[zambanini]

@Jailer
the initial poster asked, if he can expand the vdev itself....not the pool. and this is not easlily possible(replace every disk with a greater one and use autoexpand or destroy it and create a new one.)

expanding the pool with other vdevs is not messy, it is a good feature you have just to understand it. RTFM

 

[Jailer]

@Jailer
the initial poster asked, if he can expand the vdev itself....not the pool.

I understand what he asked and answered that in post #3. I was asking DKarnov to explain further his statement how adding vdevs to a pool "can make things messier down the line"

expanding the pool with other vdevs is not messy, it is a good feature you have just to understand it. RTFM

I also understand this and that's why I asked.

 

[DKarnov]

Can you expalin this please? From what I understand this is one of the areas where ZFS shines is in it's management of multiple vdevs and large pools.

The 'mess' isn't with growing the pool, it's shrinking it back.

The OP states they realize they'll eventually have to update their existing vdev with larger disks. If they add another vdev to the pool with the intent of temporarily satisfying storage demand until this time, then they can't use those disks as part of that upgrading of the original vdev, and they can't get rid of the additional vdev without nuking the pool - but if nuking the pool to expand it was undesirable before, it's likely even more so once more data has built up. So you've baked in those additional chassis / SATA port / etc requirements. It's not 'messy' in terms of ZFS at all, it's 'messy' in terms of snowballing hardware accumulation only solvable with a snowballing-size backup and rebuild. For some that's a complete non-issue, for others it goes against the point of consolidating their storage neatly into one space and power efficient pool in the first place.

 

[Jailer]

then read the f******* manual and faq posts for noobs. there it is answered.

No need to be rude.

The 'mess' isn't with growing the pool, it's shrinking it back.

The OP states they realize they'll eventually have to update their existing vdev with larger disks. If they add another vdev to the pool with the intent of temporarily satisfying storage demand until this time, then they can't use those disks as part of that upgrading of the original vdev, and they can't get rid of the additional vdev without nuking the pool - but if nuking the pool to expand it was undesirable before, it's likely even more so once more data has built up. So you've baked in those additional chassis / SATA port / etc requirements. It's not 'messy' in terms of ZFS at all, it's 'messy' in terms of snowballing hardware accumulation only solvable with a snowballing-size backup and rebuild. For some that's a complete non-issue, for others it goes against the point of consolidating their storage neatly into one space and power efficient pool in the first place.

Ok, now your previous post makes sense to me.

zambanini, DKarnov's post above is called polite clarification. See how that works?