[Bug 208882] zfs root filesystem mount failure on startup in FreeBSD 10.3-RELEASE if USB hdd with zpool is attached to another port

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208882

Ian Lepore <ian at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|freebsd-fs at FreeBSD.org      |ian at FreeBSD.org
                 CC|                            |ian at FreeBSD.org
             Status|New                         |Open

--- Comment #20 from Ian Lepore <ian at 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.