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=3D208882 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 subsyste= m.=20 A root hold is placed for each usb bus while it is scanned, and released wh= en the scan is complete. That allows any umass devices on the bus to be creat= ed before releasing the hold. The problem is that a umass device is not the t= hing that hosts the root filesystem, it needs to attach to CAM and eventually ha= ve a da device created, then geom needs to taste that device and create all geom= s 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 ha= ve 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 devic= es.=20 All this same extra plumbing of holds would have to be replicated in the mm= c/sd subsystem as well. Because of all the existing races you can't actually re= ly 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/somethi= ng 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 t= hem based on names in /dev, so there's no way the existing root mount hold syst= em 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, a= nd 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 mou= nt hold system to continue to exist as well, but removing it is more complicat= ed and should be handled separately after this simple fix is comitted. --=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-208882-3630-pAn1B7FsaG>