My NAS was full, in the way storage is always eventually full, and I'd run out of bays to throw new disks at. The pool was a single raidz2 vdev of six drives, which had seemed enormous when I built it and now did not. The question was how to grow it without buying a second chassis or copying everything off and back again.
The answer with ZFS is the disk shuffle, and it's one of those operations that feels like it shouldn't work but does. You can't add a disk to an existing raidz vdev. What you can do is replace every disk in that vdev with a larger one, one at a time, and once the last one is in, the vdev quietly grows to use the new space.
The procedure is patient rather than clever. For each disk:
zpool offline tank /dev/disk/by-id/old-disk
# physically swap the drive
zpool replace tank /dev/disk/by-id/old-disk /dev/disk/by-id/new-disk
zpool status tank # watch the resilver
Then you wait. Each resilver rebuilds that disk's share of the data from parity, and on a reasonably full pool of large drives that is hours, not minutes. You do not start the next one until the last has finished and the pool is back to a healthy state, because running with reduced redundancy mid-resilver is exactly the moment a second disk likes to fail. I learned long ago that the homelab gods punish impatience here specifically.
The one setting that matters: autoexpand. If it's off, you'll do the whole shuffle, swap every drive, and find the pool stubbornly the same size as before, which is a deeply unsatisfying way to end three days of resilvering.
zpool set autoexpand=on tank
With that on, the pool grows automatically once the final disk lands. Without it, you're hunting through documentation at midnight wondering what you did wrong, which is, I will admit, how I learned that the setting exists.
A week and six resilvers later, the pool was half again as large, no data had moved, no service had gone down, and the only cost was electricity and patience. ZFS gets a reputation for demanding RAM and ceremony, and some of that is fair, but operations like this are where it earns its keep. The whole thing happened underneath a running system that never knew the floor was being replaced beneath it.