Date: Sat, 10 Mar 2018 19:46:25 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 208882] zfs root filesystem mount failure on startup in FreeBSD 10.3-RELEASE if USB hdd with zpool is attached to another port Message-ID: <bug-208882-3630-pAn1B7FsaG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-208882-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-208882-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=208882 Ian Lepore <ian@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |ian@FreeBSD.org CC| |ian@FreeBSD.org Status|New |Open --- Comment #20 from Ian Lepore <ian@FreeBSD.org> --- To expand a little bit on Warner's comment, based on a discussion we had on irc... The current root mount hold system is incomplete, and it may be inadequate overall to ever help with the zfs situations. One way the current system is incomplete is illustrated by the usb subsystem. A root hold is placed for each usb bus while it is scanned, and released when the scan is complete. That allows any umass devices on the bus to be created before releasing the hold. The problem is that a umass device is not the thing that hosts the root filesystem, it needs to attach to CAM and eventually have a da device created, then geom needs to taste that device and create all geoms on it, and so on. All this work ends up happening asynchronously after the usb bus root hold is released. To fix this properly, the umass device would have to place its own root hold which didn't get released until CAM had created and attached the da device(s). CAM would have to place its own root holds that would have to remain in place until geom had finished tasting the new devices. All this same extra plumbing of holds would have to be replicated in the mmc/sd subsystem as well. Because of all the existing races you can't actually rely on the releasing of all mount holds to indicate that devices are ready. So the scheme only works for devices that are mounted by specifying a /dev/something name, because that allows the code in vfs_mountroot.c to keep looping until a name lookup succeeds. Which brings us to zfs, a way to host root filesystems that doesn't mount them based on names in /dev, so there's no way the existing root mount hold system and detection of availability can even be extended to zfs. A much simpler alternative is the idea contained in the patch with this PR: detect the availability of the root filesystem by attempting to mount it, and if that fails, pause briefly and try again, until the timeout expires. With this new retry loop in place, there is little reason for the whole root mount hold system to continue to exist as well, but removing it is more complicated and should be handled separately after this simple fix is comitted. -- 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-208882-3630-pAn1B7FsaG>