zfs-macOS-2.3.0

[lundman]

Upstream changelog

• RAIDZ Expansion (raidz expansion feature openzfs/zfs#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime.
• Fast Dedup (Fast Dedup openzfs/zfs#15896): A major performance upgrade to the original OpenZFS deduplication functionality.
• Direct IO (Direct IO Support openzfs/zfs#10018): Allows bypassing the ARC for reads/writes, improving performance in scenarios like NVMe devices where caching may hinder efficiency.
• JSON (JSON output support for zfs and zpool commands openzfs/zfs#16217): Optional JSON output for the most used commands.
• Long names (Longname: files/directories name upto 1023 bytes openzfs/zfs#15921): Support for file and directory names up to 1023 characters.

Bug Fixes: A series of critical bug fixes addressing issues reported in previous versions.
Numerous performance improvements throughout the code base.
Supported Platforms:

   Linux kernels 4.18 - 6.12,
   FreeBSD releases 13.3, 14.0 - 14.2.
   macOS releases 10.9 (Mavericks) - 15.0 (Sequoia)

We could probably put a macOS specific changelog here as well

---

This discussion was created from the release zfs-macOS-2.3.0.

[dgreenley]

This release appears to have broken arcstat?

$ arcstat 
    time  read  ddread  ddh%  dmread  dmh%  pread  ph%   size      c  avail
Traceback (most recent call last):
  File "/usr/local/zfs/bin/arcstat", line 817, in <module>
    main()
    ~~~~^^
  File "/usr/local/zfs/bin/arcstat", line 801, in main
    calculate()
    ~~~~~~~~~^^
  File "/usr/local/zfs/bin/arcstat", line 724, in calculate
    v["ztotal"] = (d["zfetch_hits"] + d["zfetch_future"] + d["zfetch_stride"] +
                   ~^^^^^^^^^^^^^^^
KeyError: 'zfetch_hits'

[lundman]

Hmm what did they rename it to now..

Ah

kstat.zfs.misc.zfetchstats.hits: 0
kstat.zfs.misc.zfetchstats.future: 0
kstat.zfs.misc.zfetchstats.stride: 0
kstat.zfs.misc.zfetchstats.past: 0
kstat.zfs.misc.zfetchstats.misses: 0
kstat.zfs.misc.zfetchstats.max_streams: 0
kstat.zfs.misc.zfetchstats.io_issued: 0
kstat.zfs.misc.zfetchstats.io_active: 0

[stychos]

Looks like crashes mentioned in #28 (comment) are resolved, but after a system reboot I am not able to boot into the system, looks like a kernel panic at some stage. After dual-booting into a linux and rebooting back to macOS everything is fine until the next reboot. I will try to enable verbose booting and gather some meaningful logs soon.

[term-i-nator]

It's not possible to install OpenZFSonOsX-2.3.0-Sequoia-15-arm64.pkg on my Mac mini M2 Pro, macOS Sequoia 15.5. „Installation failed“! I tried the version for Sonoma with the same result. What am I doing wrong here?

[yurikoles]

Please try installing PKG via CLI to get error output.

[hurricane-brian]

i had the same problem:
"Error Domain=KMErrorDomain Code=71 "Kernel request failed: (libkern/kext) kext is in use or retained (cannot unload) (-603946984)"

[yurikoles]

@hurricane-brian, it seems the installer failed to unload the old kext during the upgrade. Please try the following:

1. Export all ZFS pools by sudo zpool export -af and verify that zpool status shows no pools available.
2. Unload ZFS kext by sudo kmutil unload -b org.openzfsonosx.zfs and make sure it's no longer loaded by kmutil showloaded | grep -i zfs, it should output nothing, if you see org.openzfsonosx.zfs (2.3.0), then it's still loaded.
3. Try to install/upgrade again.

[a7z]

I am trying deduplication.
Works nice. The tests (240gb) show that dedup plus compression gives me 10% additional space than compression alone.
But I am unsure if I am using Fast-Dedup.
The links you gave from linux upstream telling s.th. about a pool feature "fast_dedup" that needs to be enabled and properties for ddt table size and quota.
But I can't find those. Neither in the pool nor the dataset configs.
Is fast-dedup activated by default in our OpenZFS or is it missing and I use the "legacy" dedup?
Before I go all in and fill my external drive to the brim I would like to know this.
Thanks in advance, you're doing a great job.

[dgreenley]

zpool get feature@fast_dedup

Though everything I've every read still indicates that deduping usually isn't worth it for most people's setups. eg https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/#i-dont-get-it-after-all-this-if-its-good-enough-why-shouldnt-i-enable-dedup-everywhere

[a7z]

O...M...G...
I was about to write "I have no such feature". But as of your confident and fast reply and me wondering why you have it and I don't I made the unthinkable .... : "zpool version".
I have 2.2.3 installed ! I have 2.2.3 installed. I have ...
WTF?
I HAD installed 2.3.0. I know it for sure. I was so sure that I didn't thought about looking for the version I have.
But how ...?

Ok, update of zfs and there they are the feature and properties.
Upgrade of pool and enabling fast-dedup.
The impact when coping to it on the cpu is MUCH less with fast-dedup. About a third.
The performance seems a little lower, about 10% less.

Now I need to copy all again. Tomorrow. Did by now only 30gb just for a quick test.
And before that I need to fiddle a little with recordsize to find the sweetspot between compression and deduping.

I read the part of the article you've linked to. Yes I know what you mean, but his situation is completely different to mine. He got a dedup ration of "0". Mine is 1.10 (the just written data even 1.28) and I haven't copied all my data yet.
It is just for maybe putting more data (maybe all) onto the drive than before with hfs+ (only 80%).
If there is not enough additional space by deduping I go back to hfs+.
Maybe it works, maybe not.
I'll find out.

---

But one question remains: What does "dedup_table_size 16.0E" mean? It can't be 16 exabyte.

[FunMiles]

Would the Sequoia version work on Tahoe, or should I wait for an updated version?

[lundman]

It appears to work fine.