Get Info shows incorrect volume size for ZFS pool on MacOs Catalina

Question

I'm currently running ZFS on MacOS Catalina, version

zfs-1.9.4-0
zfs-kmod-1.9.4-0

After replacing my 3TB disks with 6TB ones ZFS sees the current sizing as

 SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
5.46T  2.59T  2.87T        -         -    15%    47%  1.00x  ONLINE  -

However Get Info on the volume shows 4.71TB with 2.97TB free. Any ideas why this is the case and should I be worried about the disparity in free space? i.e. could this cause issues down the track where the OS sees more available space than exists?

Answer 1

You don't need to worry, I think.

Short and quick explanation

• Get Info's "Available" is correct, but "Capacity" is not what you intuitively expect it be. It's actually used space + available space of the corresponding ZFS dataset (not the pool! it's the dataset inside the pool).
• Moreover, Get Info uses decimal units, zfs uses binary units.

A more detailed explanation follows.

There are two different things going on here.

Decimal units and binary units.

First of all, Finder's Get Info returns Kilobytes, Gigabytes and Terabytes in base 10 (KB, GB and TB), while command line tools such as df, zfs and zpool report values that use base 2 (KiB, Gib, TiB).

This means that 1GB = 1000^3 = 10^9 bytes, not the same number of bytes as 1GiB = 1024^3 = 2^30. In fact, 1GB = ~0.931GiB. Google provides a handy digital sizes converter to play with these conversions.

This is true of any filesystem you use on your Mac. On my system, I have a HFS+ partition. Its size is reported as such:

• 60GB by Get Info;
• 56G by df -h.

Capacity, as reported by the ZFS datasets to the OS, is not the underlying pool size, but something else.

ZFS is not just a filesystem, but a Volume Manager too. You could have any ZFS Dataset inside your pool, sharing the same available space, each consuming up a portion of it. You start with a root dataset, but you could add any number.

What does your "Get Info" report? Hint, it's not the size of your pool, even though intuitively, you were probably expecting that. My guess is, it probably reports a number regarding your root ZFS dataset (which is not the same as your pool!), and that number should be USED bytes + AVAILABLE bytes.

Let's check it on a real system.

I have a pool named Tank on my system. zpool list's output is:

NAME   SIZE  ALLOC   FREE
Tank  1.81T  1.32T   509G

I have three datasets inside it: the root, Tank, and two nested datasets, Tank/DataOne and Tank/DataTwo. zfs list's output is:

NAME           USED   AVAIL   REFER
Tank          1.32T    451G    336K
Tank/DataOne  45.9G    451G   45.8G
Tank/DataTwo  1.27T    451G   1.21T

Note that I don't keep any real data inside the root dataset. USED reports all space consumed by the datasets, its snapshots, its nested datasets and their snapshots. REFER reports space used by the filesystem itself at the current time (no snapshots, no nested stuff). You can see that most of the data is in DataTwo, with 0.06TiB of snapshots too. There are finer grained options to zfs list if you want to: zfs list -o space adds also the columns USEDSNAP USEDDS USEDREFRESERV USEDCHILD).

Let's go on and see what non-ZFS tools say. df -h output is:

Filesystem        Size  Used Avail
/dev/disk2s1      451G  336K  451G
Tank/DataOne      497G   46G  451G
Tank/DataTwo      1.7T  1.3T  451G

Get Info says:

Name     Capacity  Available
Tank     483.81GB   483.81GB 
DataOne  533.02GB   483.81GB
DataTwo    1.82TB   483.81GB

Conclusions

You can easily see that the values of df's "SIZE" and Get Info's "Capacity" are the same number of bytes, with different units. Rounding up the results: 483.8GB = 451GiB, 533GB = 497GiB, and 1.82TB = 1.7TiB.

More important, let's see if the sum of zfs's AVAIL + REFER values equals df and Get Info values, or not.

NAME    AVAIL  + REFER
Tank     451G  +  336K = 451GiB = 483GB
DataOne  451G  + 45.8G = 497GiB = 533GB
DataTwo  451G  + 1.21T = 1.65TiB = 1.81TB

The last value differs slightly, but I think it's due to rounding ups here and there that skew the result. Apart from that, everything checks perfectly.