Upcoming testing...

[lundman]

Ah I'll give rollback some exercise and see if I can trigger anything here.

[lundman]

Did not panic for me, but I can certainly make it deadlock. Which could be a panic on arm64 with a watchdog timeout or
something, but that wasn't the panic message you got. Did it take a while before panic, as if it was a timeout? (like, 10 seconds)

I also noticed the "poke Finder to update" after rollback doesn't seem to be working, but that's minor.

[lundman]

OK fixed the deadlock, and working on the Finder-wakeup. But my remote mac stopped responding for some reason.

[lundman]

Ah ok, so there were a few minor panic bugs in there;

https://github.com/openzfsonosx/openzfs-fork/compare/a71edf216017%5E...5a544ed3509f

So at least 2 panics found, and fixed the findernotify thread code, and added refresh code for
after rollback. Feel that should make rollback, wake-from-sleep, behave better.

If you want to try a test build, let me know if you want x64 or arm64.

[dmz]

I'm definitely seeing some panics under the current build (with file-based pools fix) on Ventura on the Mac Studio, where I was not seeing panics previously... seems to happen under heavy rsync activity to/from from two remote sites simultaneously (so two rsyncs accessing the same filesystem), but I haven't been able to get a panic report out of it for some reason (nothing in Library/Logs/DIagnosticReports/retired, maybe I'm waiting too long to look there). So if you've fixed some panics since that build, I'd like to give a fixed build a shot.

[o3x_prokyon]

It's a little quiet here... I guess the development is done on github...

Some observations from my latest installation:

Code: Select all

zfs-2.1.99-1874_gb0e5563eb
zfs-kmod-2.1.99-1874_gb0e5563eb

Arm64 assembly works great with this version, the transfer rates are close to the maximum possible values of my disks.

But if my ZFS pool is imported and active, the system crashes, every time I eject/unmount/deactivate any other APFS volume/disk in Finder or Disk Utility.
Furthermore, the fixes of the xattr-problems, we discussed in another thread, have gone again with this version (setting finder icons, setting the user-immutable flag).

No Idea if this is related to xattr, too, but Carbon Copy Cloner (which uses rsync, as far as I know) updates a lot of files over and over again on the pool, even if nothing has changed.

Thanks a lot, and I'm looking forward to the release of the official 2.1.7.

[lundman]

Sorry, had a wedding to attend to in UK, so was not active for the last 10 or so days. Getting back into the swing of things today.

[o3x_prokyon]

Welcome back

2.1.7rc3 is very promising. I've not checked, if my system still crashes when ejecting other external drives, but setting the user-immutable flag now works. Still missing is the possibility to set/change folder icons...

At the moment I'm running a Carbon Copy Cloner (CCC) backup to my zfs pool and it seems, that still a big amount of data is transfered, even if nothing has changed (pictures, movies, music...). This might be a normal behaviour, keeping in mind, that during the last backups those files have been replaced over and over again, too, but maybe not in the way, they should have been. On the next backup, I will see, if those files are still „updated“ over and over again. CCC uses rsync in the background, so maybe this behaviour is related to rsync...

[o3x_prokyon]

Ok, here are some findings for 2.1.7 rc3:

Carbon Copy Cloner still „updates“ a lot of unchanged files on every backup. A possible reason might be this:

Code: Select all

xattr -l file.name

states this for the original file (internal APFS SSD):

Code: Select all

co.eclecticlight.dintch.hash#S: ��t���g�Q�)am�(��\w�Ϯ��F�V�%
com.apple.FinderInfo:
com.apple.lastuseddate#PS: �
com.apple.metadata:kMDItemIsScreenCapture: bplist00
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00�#@�h
com.apple.metadata:kMDItemScreenCaptureType: bplist00Yselection

and the copy on my external zfs pool:

Code: Select all

com.apple.FinderInfo:
com.apple.lastuseddate#PS: �
com.apple.decmpfs: fpmc
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00�#@�h
com.apple.metadata:kMDItemIsScreenCapture: bplist00
co.eclecticlight.dintch.hash#S: ��t���g�Q�)am�(��\w�Ϯ��F�V�%
com.apple.metadata:kMDItemScreenCaptureType: bplist00Yselection
com.apple.ResourceFork:

I guess, the different order is not so relevant, but on the zfs pool there are two new xattrs:
"com.apple.ResourceFork" and
"com.apple.decmpfs: fpmc"

The zfs-settings of the pool are:

Code: Select all

aclmode=discard
aclinherit=restricted
xattr=sa
utf8only=on
normalization=formD
casesensitivity=insensitive
acltype=nfsv4
com.apple.mimic=apfs

And in /etc/zfs/zsysctl.conf:

Code: Select all

kstat.zfs.darwin.tunable.zfs.xattr_compat=1
kstat.zfs.darwin.tunable.force_formd_normalized=1

I hope, this helps... now I will test the eject-crash...

[o3x_prokyon]

Ok, so, my mac (Mac mini M2, macOS Ventura 13.4) still panics while ejecting any other external USB disk or even a ramdisk(!) before exporting the zfs pool. If the pool has been exported, everything is fine. Next, I try to deinstall OpenZFS completely, reboot and then re-install it again. Maybe this helps. If not...? No Idea.