Hi. Maybe different problem (as mav@ noted) with Garrett's but related to parallel-mounting.
*For Garrett's problem, +1 with Trond. For myself, I incorporate drive type and No. in pool name to avoid collision between 2 physical drives (one working, and one emergency) in the same host. After ZFS parallel mounting is committed (both head and stable/12), auto-mounting from manually-imported non-root pool(s) looks racy and usually fails (some datasets are shown as mounted, but not accessible until manual unmount/remount is proceeded). *I'm experiencing the problem when I import another root pool by `zpool import -R /mnt -f poolname`. Patch from ZoL on bug 237517 [1] seems to fix the parallel mounting race. (Named ZoL fix by fullermd.) As it seemed to be race condition, I'm not 100% shure the patch is really correct. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237517 On Sun, 21 Jul 2019 17:41:59 -0400 Alexander Motin <m...@freebsd.org> wrote: > Hi, > > I am not sure how the original description leads to conclusion that > problem is related to parallel mounting. From my point of view it > sounds like a problem that root pool mounting happens based on name, not > pool GUID that needs to be passed from the loader. We have seen problem > like that ourselves too when boot pool names collide. So I doubt it is > a new problem, just nobody got to fixing it yet. > > On 20.07.2019 06:41, Eugene Grosbein wrote: > > CC'ing Alexander Motin who comitted the change. > > > > 20.07.2019 1:21, Garrett Wollman wrote: > > > >> I recently upgraded several file servers from 11.2 to 11.3. All of > >> them boot from a ZFS pool called "tank" (the data is in a different > >> pool). In a couple of instances (which caused me to have to take a > >> late-evening 140-mile drive to the remote data center where they are > >> located), the servers crashed at the root mount phase. In one case, > >> it bailed out with error 5 (I believe that's [EIO]) to the usual > >> mountroot prompt. In the second case, the kernel panicked instead. > >> > >> The root cause (no pun intended) on both servers was a disk which was > >> supplied by the vendor with a label on it that claimed to be part of > >> the "tank" pool, and for some reason the 11.3 kernel was trying to > >> mount that (faulted) pool rather than the real one. The disks and > >> pool configuration were unchanged from 11.2 (and probably 11.1 as > >> well) so I am puzzled. > >> > >> Other than laboriously running "zpool labelclear -f /dev/somedisk" for > >> every piece of media that comes into my hands, is there anything else > >> I could have done to avoid this? > > > > Both 11.3-RELEASE announcement and Release Notes mention this: > > > >> The ZFS filesystem has been updated to implement parallel mounting. > > > > I strongly suggest reading Release documentation in case of troubles > > after upgrade, at least. Or better, read *before* updating. > > > > I guess this parallelism created some race for your case. > > > > Unfortunately, a way to fall back to sequential mounting seems undocumented. > > libzfs checks for ZFS_SERIAL_MOUNT environment variable to exist having any > > value. > > I'm not sure how you set it for mounting root, maybe it will use kenv, > > so try adding to /boot/loader.conf: > > > > ZFS_SERIAL_MOUNT=1 > > > > Alexander should have more knowledge on this. > > > > And of course, attaching unrelated device having label conflicting > > with root pool is asking for trouble. Re-label it ASAP. > > > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Tomoaki AOKI <junch...@dec.sakura.ne.jp> _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
