[Bug 263473] ZFS drives fail to mount datasets when rebooting - 13.1-RC4

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.