[Bug 263473] ZFS drives fail to mount datasets when rebooting - 13.1-RC4
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 16 Aug 2022 07:17:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263473 --- Comment #14 from Maxim Sobolev <sobomax@FreeBSD.org> --- OK, little bit more info about this issue. It also happening on purely ZFS system as well running on m5 AWS instance also after upgrading from 12.2. Only boot pool is imported on boot, not 3 more pools that this disk has connected to it. Interestingly enough, the vfs.root_mount_always_wait=1 did not help in that case. I've done a bit of a investigation: it turns out to be the result of the OpenZFS import. The new default in 13.1 just disables autoimport of zfs pools. From the quick grep through sources, it seems that Linux has some mechanism to do import in userland (i.e. "rc.d" magic), while FreeBSD doesn't. ^3b0ce0e28db module/zfs/spa_config.c (Matt Macy 2020-08-24 22:48:19 +0000 71) int zfs_autoimport_disable = 1; As such, I suggest the default needs to be reverted to 0 (i.e. autoimport to be enabled again) until and when we get some other way to provide this feature. Unfortunately, that code path seems 100% untested, as setting autoimport_disable to 0 just causes kernel to panic when ZFS is initialized. Timecounters tick every 10.000 msec calling spa_init()... calling spa_config_load()... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x1d0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff806aa7d9 stack pointer = 0x28:0xffffffff8167be70 frame pointer = 0x28:0xffffffff8167be70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 3 time = 1 KDB: stack backtrace: #0 0xffffffff8061f685 at kdb_backtrace+0x65 #1 0xffffffff805d5f6f at vpanic+0x17f #2 0xffffffff805d5de3 at panic+0x43 #3 0xffffffff808fac35 at trap_fatal+0x385 #4 0xffffffff808fac8f at trap_pfault+0x4f #5 0xffffffff808d1f68 at calltrap+0x8 #6 0xffffffff80580972 at pwd_ensure_dirs+0x1f2 #7 0xffffffff8118a508 at zfs_file_open+0x28 #8 0xffffffff810e0b9d at spa_config_load+0x5d #9 0xffffffff810e9aae at spa_init+0x11e #10 0xffffffff81190bb2 at zfs_kmod_init+0x32 #11 0xffffffff81007db0 at zfs_modevent+0x30 #12 0xffffffff805b3d54 at module_register_init+0xa4 #13 0xffffffff8056674f at mi_startup+0xdf #14 0xffffffff802ca022 at btext+0x22 Comparing implementation of the zfs_file_open() with the kobj_file_open() in 12.x that it replaced, the former is not designed to run before root is mounted. So I had also to disable call to the spa_config_load() from the spa_init() and just leave one in the spa_boot_init(), that seems to DTRT in all cases (zfs loaded from the loader, zfs loaded from the multi-user). Patch is attached, feedback is welcome. -- You are receiving this mail because: You are the assignee for the bug.