It never gets smaller


Well, we've had nine months of iSCSI least for two of us. To review, we have FreeNAS with 3 big disks in a ZFS RAIDZ1 configuration for protection against single disk failures. I started out mapping each home directory, one each for myself and my two test subjects...I mean sons, to a ZFS partition and exporting it via the netatalk Apple Filer Protocol daemon built into FreeNAS. As pointed out before, this had some problems. So, I created ZFS Volumes for myself and son #2, exported them via iSCSI to the Mountain Lion Server, created HFS+ partitions, and re-exported via AFP. Eazy Peazy!

Fast forward six months and both my son and I are encroaching on the size limits of the disk volumes that I started out with. Who ever gets rid of anything these days, right? High Def copies of Prometheus and The Avengers don't exactly have a small footprint on the disk. Throw in lots of raw digital photos and it starts getting a little crowded.

If the disk were a local drive and had some empty space, you might be able to resize the partition to get more room. Not so simple with the three layers of abstraction sitting between the usable home folder and the actual ZFS Volume. I suppose I could just "brute force" it: make sure the backups are up to date, resize the ZFS Volume, destroy the existing HFS+ partition, recreate the HFS+ partition with a bigger size, restore all the data from backup. But, where's the fun in that? Plus, do you know how long it takes to restore 300GB across a 1Gbit Ethernet, probably 5-6 hours and I just don't have the patience for that.

I should be able to do this dynamically without restoring from backups. ZFS is a wonderful thing which I complicated by using ZFS Volumes instead of ZFS filesystems. ZFS filesystems can be resized on the fly and the user just sees the bigger size. ZFS Volumes can also be resized, but now I have an iSCSI layer and the HFS+ partitioning in the way. Still there just has to be a way to do this.

As always, make sure you have a current backup of everything. I didn't need to use mine, but consider yourself warned.

ZFS Volume Resize

Before starting, quiesce the ZFS volume. Eject the HFS+ volume and disconnect the appropriate iSCSI drive from the Mac end.

zfs set volsize=<biggersize>g tank/<aVolumeName>

where 'biggersize' is the number of gigabytes you want, and 'aVolumeName' is the name of the specific volume to grow. That's really it.


You're about to restart the iSCSI daemon on FreeNAS. I'm not positive, but this might interrupt iSCSI connections for all iSCSI connections, so I would disconnect all iSCSI connections before proceeding.

At this point, the Mountain Lion Server doesn't see a change on its of the iSCSI, so let's trick FreeNAS into restarting the iSCSI daemon, istgt. Do this through the FreeNAS GUI by selecting the appropriate Device Extent via the GUI and then clicking the "OK" button without changing anything. This restarts istgt and now the Mountain Lion Server sees a larger disk.


We're almost there. The last piece is to resize the Mac OS Extended (HFS+) partition. This is where it gets scary. Disk Utility looks like it wants to help, but it's just in over its head here. Normally, Disk Utility can handle a partition resize, but this is no ordinary disk and the partition table details aren't quite right. After some Google-fu, I found the special sauce to fix the partition table:

sudo gpt show /dev/disk5

sudo gpt add -b 409640 -s nnnnnnnn

sudo gpt add -b 40 -s 409600 -t <correct UUID from 'gpt show' output> /dev/disk5

sudo gpt show /dev/disk5

The output of that last command should reflect the resizing that was done in the first 'gpt add' command. Now eject with disk utility, then disconnect/connect the iSCSI disk in GlobalSan System Preferences. As a last check, verify the mounted disk using disk utility.