Testing 2.1.6 RC4 on older versions

[Arne]

It's looking pretty good. I'll start doing compiles back in time, see how far back I can get before it's a hassle.
Call out if you need a specific old version

If it means you would compile for older versions like El Capitan than I can test it if it works under 10.11

[Arne]

I tested the 2.1.6. rc4.
Creating a new pool, exporting, importing worked.
Datasets creating worked. I created 2, one with xattr=sa, the other with xattr=dir.
Tried to copy a file from the applictions directory to "sa" and a reboot occured right when the copying process started.
I tried with libreoffice.app: reboot. Maybe smaller (mail.app, vlc.app): reboot.
A small txt file (2k) from my homedirectory was copied to "sa" successfully.
Copying to "dir" seemed to work for files from the applications location.

Here is what the report said, when the mac had rebooted:

Code: Select all

Anonymous UUID:       53B66508-B262-45C7-A3E1-56206F29582C

Fri Nov  4 16:13:03 2022

*** Panic Report ***
panic(cpu 0 caller 0xffffff80187cfdab): Kernel trap at 0xffffff801859005b, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000000008, CR3: 0x000000002a919000, CR4: 0x00000000000026e0
RAX: 0xffffff8885a788a3, RBX: 0xffffff8885a78800, RCX: 0x0000000000000001, RDX: 0x0000000000000008
RSP: 0xffffff88a1abb588, RBP: 0xffffff88a1abb5e0, RSI: 0x0000000000000008, RDI: 0xffffff8885a788a3
R8:  0xffffff8885a788ab, R9:  0x0000000000000008, R10: 0xffffff8021f15490, R11: 0xffffff88a1abb460
R12: 0xffffff8880b73400, R13: 0x000000000000002b, R14: 0x0000000000000008, R15: 0xffffff8880f7ed40
RFL: 0x0000000000010212, RIP: 0xffffff801859005b, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000000008, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0

Backtrace (CPU 0), Frame : Return Address
0xffffff88a1abb210 : 0xffffff80186dab52
0xffffff88a1abb290 : 0xffffff80187cfdab
0xffffff88a1abb470 : 0xffffff80187ebc03
0xffffff88a1abb490 : 0xffffff801859005b
0xffffff88a1abb5e0 : 0xffffff7f98f8f4e3
0xffffff88a1abb6c0 : 0xffffff7f98fd67bb
0xffffff88a1abb730 : 0xffffff7f98fd61b5
0xffffff88a1abb7b0 : 0xffffff7f98fd5f6b
0xffffff88a1abb800 : 0xffffff7f98fd0912
0xffffff88a1abb940 : 0xffffff80189296d4
0xffffff88a1abb9b0 : 0xffffff801891ce9a
0xffffff88a1abbc90 : 0xffffff801890d034
0xffffff88a1abbf60 : 0xffffff8018c28341
0xffffff88a1abbfb0 : 0xffffff80187ec3f6
      Kernel Extensions in backtrace:
         org.openzfsonosx.zfs(2.1.6)[BBDFE1D3-4440-300A-B3DB-1F46EC863D75]@0xffffff7f98e7b000->0xffffff7f99573fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[DC1AAB7C-F417-3238-BB3F-2A5B84D67B90]@0xffffff7f98e4c000

BSD process name corresponding to current thread: DesktopServicesH

Mac OS version:
15G22010

Kernel version:
Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64
Kernel UUID: 7564B0E7-EB5D-3887-BA79-59C870165AB1
Kernel slide:     0x0000000018400000
Kernel text base: 0xffffff8018600000
__HIB  text base: 0xffffff8018500000
System model name: Macmini3,1 (Mac-F22C86C8)

System uptime in nanoseconds: 569517695360
last loaded kext at 317043991038: com.apple.filesystems.msdosfs   1.10 (addr 0xffffff7f9b774000, size 69632)
last unloaded kext at 444100998082: com.apple.filesystems.msdosfs   1.10 (addr 0xffffff7f9b774000, size 61440)
loaded kexts:
org.openzfsonosx.zfs   2.1.6
org.dungeon.driver.SATSMARTDriver   0.8.2
com.logitech.manager.kernel.driver   6.94.1
com.apple.driver.AudioAUUC   1.70
com.apple.driver.AppleHWSensor   1.9.5d0
com.apple.driver.AGPM   110.22.0
com.apple.driver.ApplePlatformEnabler   2.6.0d0
com.apple.filesystems.autofs   3.0
com.apple.driver.AppleOSXWatchdog   1
com.apple.driver.AppleHDA   274.12
com.apple.GeForceTesla   10.0.0
com.apple.driver.ACPI_SMC_PlatformPlugin   1.0.0
com.apple.driver.AppleUpstreamUserClient   3.6.1
com.apple.driver.AppleMCCSControl   1.2.13
com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport   4.4.6f4
com.apple.driver.pmtelemetry   1
com.apple.iokit.IOUserEthernet   1.0.1
com.apple.iokit.IOBluetoothSerialManager   4.4.6f4
com.apple.Dont_Steal_Mac_OS_X   7.0.0
com.apple.driver.AppleHV   1
com.apple.driver.AppleIntelSlowAdaptiveClocking   4.0.0
com.apple.driver.AppleLPC   3.1
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless   1.0.0d1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib   1.0.0
com.apple.BootCache   38
com.apple.driver.AppleIRController   327.6
com.apple.driver.AppleUSBStorageCoexistentDriver   3.7.1
com.apple.iokit.SCSITaskUserClient   3.7.7
com.apple.iokit.IOAHCIBlockStorage   2.8.5
com.apple.driver.AirPortBrcm43224   700.38.27
com.apple.driver.AppleFWOHCI   5.5.4
com.apple.driver.AppleAHCIPort   3.1.8
com.apple.nvenet   2.0.22
com.apple.driver.usb.AppleUSBEHCIPCI   1.0.1
com.apple.driver.usb.AppleUSBOHCIPCI   1.0.1
com.apple.driver.AppleRTC   2.0
com.apple.driver.AppleHPET   1.8
com.apple.driver.AppleACPIButtons   4.0
com.apple.driver.AppleSMBIOS   2.1
com.apple.driver.AppleACPIEC   4.0
com.apple.driver.AppleAPIC   1.7
com.apple.driver.AppleIntelCPUPowerManagementClient   218.0.0
com.apple.nke.applicationfirewall   163
com.apple.security.quarantine   3
com.apple.security.TMSafetyNet   8
com.apple.driver.AppleIntelCPUPowerManagement   218.0.0
com.apple.AppleGraphicsDeviceControl   3.12.9
com.apple.kext.triggers   1.0
com.apple.driver.AppleHIDKeyboard   181
com.apple.driver.DspFuncLib   274.12
com.apple.kext.OSvKernDSPLib   525
com.apple.driver.IOPlatformPluginLegacy   1.0.0
com.apple.driver.AppleSMBusController   1.0.14d1
com.apple.iokit.IOBluetoothHostControllerUSBTransport   4.4.6f4
com.apple.iokit.IOSurface   108.3.2
com.apple.iokit.IOSerialFamily   11
com.apple.driver.CoreCaptureResponder   1
com.apple.nvidia.classic.NVDANV50HalTesla   10.0.0
com.apple.nvidia.classic.NVDAResmanTesla   10.0.0
com.apple.driver.AppleHDAController   274.12
com.apple.iokit.IOHDAFamily   274.12
com.apple.iokit.IOAudioFamily   204.4
com.apple.vecLib.kext   1.2.0
com.apple.iokit.IOSlowAdaptiveClockingFamily   1.0.0
com.apple.iokit.IOFireWireIP   2.2.6
com.apple.driver.AppleSMC   3.1.9
com.apple.driver.IOPlatformPluginFamily   6.0.0d7
com.apple.iokit.IONDRVSupport   2.4.1
com.apple.iokit.IOGraphicsFamily   2.4.1
com.apple.driver.usb.IOUSBHostHIDDevice   1.0.1
com.apple.driver.usb.AppleUSBHub   1.0.1
com.apple.iokit.IOSCSIBlockCommandsDevice   3.7.7
com.apple.iokit.IOUSBMassStorageClass   4.0.2
com.apple.iokit.IOUSBMassStorageDriver   1.0.0
com.apple.driver.usb.cdc   5.0.0
com.apple.driver.usb.networking   5.0.0
com.apple.driver.usb.AppleUSBHostCompositeDevice   1.0.1
com.apple.iokit.IOSCSIMultimediaCommandsDevice   3.7.7
com.apple.iokit.IOBDStorageFamily   1.8
com.apple.iokit.IODVDStorageFamily   1.8
com.apple.iokit.IOCDStorageFamily   1.8
com.apple.iokit.IOAHCISerialATAPI   2.6.2
com.apple.iokit.IOSCSIArchitectureModelFamily   3.7.7
com.apple.iokit.IO80211Family   1110.26
com.apple.driver.corecapture   1.0.4
com.apple.iokit.IOFireWireFamily   4.6.1
com.apple.iokit.IOAHCIFamily   2.8.1
com.apple.iokit.IONetworkingFamily   3.2
com.apple.driver.usb.AppleUSBOHCI   1.0.1
com.apple.driver.usb.AppleUSBEHCI   1.0.1
com.apple.driver.NVSMU   2.2.9
com.apple.driver.AppleEFINVRAM   2.0
com.apple.driver.AppleEFIRuntime   2.0
com.apple.iokit.IOSMBusFamily   1.1
com.apple.security.sandbox   300.0
com.apple.kext.AppleMatch   1.0.0d1
com.apple.driver.AppleKeyStore   2
com.apple.driver.AppleMobileFileIntegrity   1.0.5
com.apple.driver.AppleCredentialManager   1.0
com.apple.driver.DiskImages   417.4
com.apple.iokit.IOStorageFamily   2.1
com.apple.driver.IOBluetoothHIDDriver   4.4.6f4
com.apple.iokit.IOBluetoothFamily   4.4.6f4
com.apple.iokit.IOReportFamily   31
com.apple.iokit.IOUSBHIDDriver   900.4.1
com.apple.iokit.IOHIDFamily   2.0.0
com.apple.driver.AppleFDEKeyStore   28.30
com.apple.iokit.IOUSBFamily   900.4.1
com.apple.iokit.IOUSBHostFamily   1.0.1
com.apple.driver.AppleUSBHostMergeProperties   1.0.1
com.apple.driver.AppleACPIPlatform   4.0
com.apple.iokit.IOPCIFamily   2.9
com.apple.iokit.IOACPIFamily   1.4
com.apple.kec.Libm   1
com.apple.kec.pthread   1
com.apple.kec.corecrypto   1.0



I switched back to 1.9.4

[lundman]

OK that was quite an interesting bug, took me all evening (8 episodes) to figure out. If you have energy some day, can you
try out this build: zfs-kmod-2.1.6-12_gfba35a40b

OpenZFSonOsX-2.1.6rc4-Catalina-10.15.pkg

(16.24 MiB) Downloaded 379 times

Oh hmm you need older, in the morning

OpenZFSonOsX-2.1.6rc4-EL.CAPITAN-10.11.pkg

(15.75 MiB) Downloaded 396 times

[Arne]

Thanks for compiling a new version.

Ok, I've done it.
All went well. Creating, copying data on it, deleting data, export, import.
Made 2 datasets (with xattr=dir and xattr=sa) and all was good. I could copy Mail.app and Libreoffice.app (and other files) with no sudden reboot.

But...
As I mentioned in an earlier post here, I had now again the problem with a pdf that I edited with skim.app (to highlight parts of the text). When I copy it with finder, rsync or cp from hfs to "xattr=sa" it transfered only a fraction of the xattr where skim.app saves the highlighted text, and there are no highlights anymore in skim.app. Copying to "dir" works.

From 149 xattr entries the copy process transfered only 33.

Code: Select all

$ xattr /Volumes/WD2TB/Personal\ Development/Tony\ Robbins/Re-Awaken_the_Giant_Within_Highres.pdf | wc -l
     149

$ xattr /Volumes/zfs/sa/Re-Awaken_the_Giant_Within_Highres.pdf | wc -l
     33


I tested another file that has no connection to skim.app, just a file with almost the same amount of xattr contents. And the xattr are the same after copying it to the dataset with "xattr=sa".
The main difference to the pdf is that it has only 2 xattr entries, com.apple.FinderInfo and com.apple.ResourceFork.

The complete amount of contents of both files (number of lines, words and bytes) is almost the same but the amount of xattr entries is different (149 vs 2).

Code: Select all

$ xattr -l /Volumes/WD2TB/Personal\ Development/Tony\ Robbins/Re-Awaken_the_Giant_Within_Highres.pdf | wc
   18730  333304 1448653

$ xattr -l "/Users/arne/AddressBook (4)"  | wc
   18050  326190 1407634


My conclusion till now is
- there might be a limit of the numbers of xattr entries (only 33 of the pdf where transfered)
- or the skim.app makes something weird with the entries cause the other file was copied with all xattr

Thinking about not using "sa" in the future, so when I finally switch to 2.1.6 I copy all data to the new pool with "xattr=dir".
I use "sa" on 1.9.4 cause it seems a little faster than "dir" out of less overhead when writing and reading the xattr.
I wish I could find out if it is really only skim that makes those problems with "sa".

[lundman]

"to 64K of data may be stored per-file in the space reserved for
system
attributes. If there is not enough space available for an
extended attribute then it will be automatically
written as a directory based xattr." (man zfsprops)

and yet we do appear to have a limit:

root@Catalina(/Users/lundman/src/zfs/openzfs-fork) xattr -l /Volumes/BOOM/sa/file | wc
227 454 61256

I appear unable to go over that.

Digging deeper.

[lundman]

OK, so we set xattr_sa first, and if that fails (too big), set xattr_dir instead.

However, the xattr_sa code would "consume" the uio when attempting to set it, which means the uio
is now "empty". So xattr_dir would do nothing.

Can you try this build attempting to fix this issue?

OpenZFSonOsX-2.1.6rc4-EL.CAPITAN-10.11.pkg

(15.74 MiB) Downloaded 392 times

[Arne]

It works!

But what about my file "AddressBook" that has a lot more than your allowed number of bytes (61256 < 1.4 Million)?
I tested this file with 1.9.4, too. And it is copied by Finder with all xattr contents to a dataset with xattr=sa. Independ of being copied from hfs or "dir".
Strange.

This file has:
com.apple.quarantine
com.apple.system.Security
com.apple.FinderInfo
com.apple.ResourceFork

The ResourceFork is in a "<xattr-dir>" according to a "zfs diff". The first 3 are in "sa" format I guess.

When I copy the pdf "Re-Awaken..." with the many xattrs from hfs to "sa" (copying from "dir" doesn't work with 1.9.4) the first 31 xattr entries are stored as "sa" and the rest is in "<xattr-dir>" (according to a "zfs diff").

So it seems that under 2.1.6rc4 there was a hickup when switching from saving in "sa" to "dir" at the point of overflow.

But anyway, everything works well with 2.1.6rc4 now.

So thanks for fixing this issue.

Allthough it worked well with 2.1.6rc4 I am a little uncertain switching to 2.1.6.
When the final version of 2.1.6 is ready, is there any chance to use it with my 1.9.4 pool?
Or only the datasets with "xattr=dir" cause "sa" is handled differently with 1.9.4?
Will upgrading the pool make the trick?
Or am I doomed to copy all my data from my hfs-backup to a new zfs-2.1.6 pool?

And if I have to copy all over into a new pool, is "sa" better/saver than "dir" or vice versa?

[lundman]

Yes, if you use xattr=sa, it is supposed to prefer to use SA, until it gets too full, then, fallback to xattr=dir.

What was broken was that fallback. So it is working as expected if some are in SA, and the rest in DIR.

Thanks for testing it thoroughly.