Date: Tue, 16 Aug 2022 07:17:06 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 263473] ZFS drives fail to mount datasets when rebooting - 13.1-RC4 Message-ID: <bug-263473-3630-CiPZ5UXm4E@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263473-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-263473-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263473 --- 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. O= nly boot pool is imported on boot, not 3 more pools that this disk has connecte= d to it. Interestingly enough, the vfs.root_mount_always_wait=3D1 did not help i= n 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 poo= ls. >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=20=20= =20=20=20 2020-08-24 22:48:19 +0000 71) int zfs_autoimport_disable =3D 1; As such, I suggest the default needs to be reverted to 0 (i.e. autoimport t= o 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 =3D 3; apic id =3D 03 fault virtual address =3D 0x1d0 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff806aa7d9 stack pointer =3D 0x28:0xffffffff8167be70 frame pointer =3D 0x28:0xffffffff8167be70 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (swapper) trap number =3D 12 panic: page fault cpuid =3D 3 time =3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263473-3630-CiPZ5UXm4E>