2.1.6RC4 Feedback

Developer discussions.

2.1.6RC4 Feedback

Postby roemer » Fri Nov 04, 2022 5:30 am

I started testing 2.1.6rc4 on an M1 Macbook with an existing zfs zmirror pool on an external USB 3.1 enclosure (OWC Mercury Elite Pro dual) and 2 SSDs.

Good news: importing and accessing pool, including natively encrypted dataset, works fine.

Performance-wise, I have the impression that zfs 1.9.4 was faster on the encrypted dataset, even though that test was on an older iMac with just USB 3 (5 GBps) interface, while I can drive the same enclose now with USB 3.1 (10 GBps) via a hub. But I do see only about the same write speeds, and actually lower read speeds.

One potential bug:
After importing the pool and running some tests, I put the laptop to sleep without exporting the pool.
When I tried to wake-up the laptop, I got a kernel panic:

panic(cpu 1 caller 0xfffffe00279b933c): userspace watchdog timeout: no successful checkins from opendirectoryd since wake
service: logd, total successful checkins since wake (60 seconds ago): 1, last successful checkin: 60 seconds ago
service: WindowServer, total successful checkins since wake (60 seconds ago): 7, last successful checkin: 0 seconds ago
service: opendirectoryd, no successful checkins since wake (60 seconds ago)

Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 21G217
Kernel version: Darwin Kernel Version 21.6.0: Thu Sep 29 20:13:56 PDT 2022; root:xnu-8020.240.7~1/RELEASE_ARM64_T6000
Fileset Kernelcache UUID: 603142F13EA24952E54126A5A0E9A870
Kernel UUID: E202255D-AD3E-3468-B44A-1ED133066AC3
iBoot version: iBoot-7459.141.1
secure boot?: YES
Paniclog version: 13
KernelCache slide: 0x000000001f6b4000
KernelCache base: 0xfffffe00266b8000
Kernel slide: 0x000000001fe78000
Kernel text base: 0xfffffe0026e7c000
Kernel text exec slide: 0x000000001ff60000
Kernel text exec base: 0xfffffe0026f64000
mach_absolute_time: 0x15374f39fef
[...]
Panicked task 0xfffffe1667a88678: 3917 pages, 4 threads: pid 362: watchdogd
Panicked thread: 0xfffffe24cdd52180, backtrace: 0xfffffe5a69483170, tid: 3939
lr: 0xfffffe0026fbd5e4 fp: 0xfffffe5a694831e0
lr: 0xfffffe0026fbd2ac fp: 0xfffffe5a69483250
lr: 0xfffffe0027104668 fp: 0xfffffe5a69483270
lr: 0xfffffe00270f63f8 fp: 0xfffffe5a694832e0
lr: 0xfffffe00270f3fdc fp: 0xfffffe5a694833a0
lr: 0xfffffe0026f6b7f8 fp: 0xfffffe5a694833b0
lr: 0xfffffe0026fbcf30 fp: 0xfffffe5a69483750
lr: 0xfffffe0026fbcf30 fp: 0xfffffe5a694837c0
lr: 0xfffffe00277e6994 fp: 0xfffffe5a694837e0
lr: 0xfffffe00279b933c fp: 0xfffffe5a69483800
lr: 0xfffffe00279b8b00 fp: 0xfffffe5a69483820
lr: 0xfffffe00279b75d8 fp: 0xfffffe5a69483940
lr: 0xfffffe0027745590 fp: 0xfffffe5a69483ad0
lr: 0xfffffe00270c3fc0 fp: 0xfffffe5a69483bf0
lr: 0xfffffe0026fc38e0 fp: 0xfffffe5a69483c90
lr: 0xfffffe0026f952c0 fp: 0xfffffe5a69483cf0
lr: 0xfffffe0026fb0614 fp: 0xfffffe5a69483d80
lr: 0xfffffe00270e90c4 fp: 0xfffffe5a69483e50
lr: 0xfffffe00270f436c fp: 0xfffffe5a69483f10
lr: 0xfffffe0026f6b7f8 fp: 0xfffffe5a69483f20
Kernel Extensions in backtrace:
com.apple.driver.AppleARMWatchdogTimer(1.0)[72EC2B21-27B2-3F71-9696-A9091457DA3A]@0xfffffe00279b4ce0->0xfffffe00279b97db
dependency: com.apple.driver.AppleARMPlatform(1.0.2)[D9108641-9ED7-3597-82E7-EB86737A996D]@0xfffffe002796a640->0xfffffe00279b4cdb
last started kext at 3783751962: com.apple.iokit.SCSITaskUserClient 456.140.3 (addr 0xfffffe0026c909e0, size 2190)

Otherwise great work - many thanks for building these arm64 versions!
roemer
 
Posts: 73
Joined: Sat Mar 15, 2014 2:32 pm

Re: 2.1.6RC4 Feedback

Postby lundman » Sat Nov 05, 2022 4:54 am

These are the worst bugs, no mention of ZFS or the load address of ZFS, so can't even lookup symbols.

I'll try to replicate.
User avatar
lundman
 
Posts: 1335
Joined: Thu Mar 06, 2014 2:05 pm
Location: Tokyo, Japan

Re: 2.1.6RC4 Feedback

Postby jawbroken » Sun Nov 06, 2022 2:39 am

Could it be the same kernel allocation bug that has already been tracked down by rottegift? There's no mention of setting “sudo sysctl kstat.zfs.darwin.tunable.zfs_arc.max=16106127360” or similar, and it smells like the same kind of random bug I would get in arbitrary other kernel extensions before setting that.
jawbroken
 
Posts: 61
Joined: Wed Apr 01, 2015 4:46 am

Re: 2.1.6RC4 Feedback

Postby lundman » Sun Nov 06, 2022 2:27 pm

It could indeed, but hard to prove. Probably worth setting a limit and see if it helps.
User avatar
lundman
 
Posts: 1335
Joined: Thu Mar 06, 2014 2:05 pm
Location: Tokyo, Japan

Re: 2.1.6RC4 Feedback

Postby roemer » Sun Nov 06, 2022 8:55 pm

jawbroken wrote:Could it be the same kernel allocation bug that has already been tracked down by rottegift? There's no mention of setting “sudo sysctl kstat.zfs.darwin.tunable.zfs_arc.max=16106127360” or similar, and it smells like the same kind of random bug I would get in arbitrary other kernel extensions before setting that.


I can't rule this out as I indeed did not change the zfs_arc.max before the kernel panic, and my machine has more than 16 GB RAM...
I have set the limit now, and will see whether it occurs again...
roemer
 
Posts: 73
Joined: Sat Mar 15, 2014 2:32 pm


Return to OpenZFS on OS X Development

Who is online

Users browsing this forum: No registered users and 19 guests