How to expand pool size after I added another disk

[rgorbie]

I am currently running TrueNAS-12.0-U7 and am running out of disk space. Instead of deleting files, it seemed easier for me just to buy another drive and expand pool size. I came from a QNAP background where this was fairly easy to achieve, but not sure on TrueNAS. I had 5 x 14TB drives installed, creating a 35.28 TiB ZRAID2 array, allowing for 2 disk failures. I installed another identical 14TB drive and can't seem to find any how-to's or options to simply add this to the pool in order to expand this current pool size. Any advice or direction? I hope I've provided enough detail to get started with my first post to this forum. Thank you in advance...

 

[jgreco]

ZFS doesn't do this. It was designed as a large server filesystem, and Sun expected you to add disk SHELVES worth of disks at a time to expand your pool.

 

[Ericloewe]

Just to add that this sort of thing should be possible soonish™. Don't hold your breath, though.

In any case, you'll probably want to catch up on the basics of ZFS. Check out the introduction to ZFS link in my sig.

 

[jgreco]

thing should be possible soonish™

which we've been saying for many years.

 

[Ericloewe]

which we've been saying for many years.

Don't hold your breath, though.

At this point, I mostly say that to satisfy the "but btrfs!" crowd.

 

[jgreco]

Yes, yes, by all means, go put your files on BitrotFS.

 

[rgorbie]

Thanks for all the answers. Sounds like I'll have to "buy" a few 14TB drives from Costco, backup to them, wipe and re-create a pool and hope like h that one doesn't fail while copying back to the new pool. Not what I was expecting, but I had read some posts going back to 2014 with essentially the same question, I figured it had been enhanced since then.

 

[jgreco]

No, this goes to the fundamental design of how ZFS works, and the fact that it's like an order of magnitude more complex.

Classic RAID systems only care about presenting a block storage device to the OS, and so they have a long, tortured, but not particularly difficult process involved to run a "wipe" through a RAID5 array to widen the array, using the "old" math ahead of the wipe bar and the "new" math behind it on the newly rearranged part of the array.

Classic filesystems can sometimes do things like "defrag" by reorganizing the locations of files to reduce fragmentation. This works because their filesystems are typically very small (compared to ZFS), and because they don't have complications such as snapshots or dedup to consider, so you are usually only rearranging block links inside one set of metadata.

ZFS, on the other hand, can't easily defrag because that would imply making changes to not only the "current" data, but also any snapshots or dedup copies ("block pointer rewrite"). As a copy-on-write filesystem, that makes it VERY difficult to do this correctly, and, unlike your 100GB Windows NTFS filesystem, a ZFS 100TB or 1PB filesystem typically has orders of magnitude more metadata and complexity to worry about.

And now we circle around to the bad bit. Not only does expanding a RAIDZ involve that sort of challenge, but also ZFS block addresses are based on math tied to the structure of RAIDZ.

The upside is that unlike RAID5, RAIDZ is an abstraction that is entirely within ZFS's mind, so what is supposed to happen with "RAIDZ expansion" is that the actual layout of RAIDZ blocks can be modified simply by changing lines of code in ZFS, creating an abstraction layer where none existed before, that allows for RAIDZ expansion. However, this is still very difficult, and has been years in the making.

 

[The Hobbyist]

I just wanted to offer a thank you to all of you that year after year answer the same questions with deep and thorough technical answers. As much as I try to understand noob frustrations I do not have the mettle to do the work.

In addition, your answers are helpful to so many others that bump into the answers in one way or another or as a refresher to some of us that forget just how much magic is available to us.

 

[jgreco]

as a refresher to some of us that forget just how much magic is available to us.

What we've seen develop over the last fifty years is nothing short of amazing. The oldest computer I've still got in inventory is a 1975-era Synertek SYM-1, a little 1MHz 6502-based jobbie with 1KB RAM. I've also got 1985-era Sun 3/50's, 16MHz 68020's with 4MB RAM. That's a 16x increase in MHz and 4000x increase in RAM in a decade, and if you think about those numbers in the context of the smartphone in your pocket, ...

Yup, absolute frickin' magic.