Date: Sat, 3 Mar 2018 21:26:38 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Bruce Evans <brde@optusnet.com.au>, tech-lists <tech-lists@zyxst.net> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: zfs problems after rebuilding system [SOLVED] Message-ID: <5A9AB09E.6090500@grosbein.net> In-Reply-To: <20180303234236.M3811@besplex.bde.org> References: <21c64a2d-b9f9-24c8-88ec-ff1210891f60@zyxst.net> <CAOtMX2jfmh%2BAMccAMcPSRq-DcQgs6wioqSSUHncEfPruD=w_Ag@mail.gmail.com> <1dc2b8ef-2914-8182-e2b0-ac637e6b2095@zyxst.net> <CAOtMX2gHm_UdYzn5J6Lm76r8KakkYMzEcxddFYLqkmGYwkihuQ@mail.gmail.com> <65372449-53f1-8002-981a-e20f4a592e26@zyxst.net> <CAOtMX2g79aqkinu0meBzhLbui7n9H9yiEwxKm6cxpZSaxbWqbg@mail.gmail.com> <f0e9385c-4d62-a68d-ea93-f013bc456b5d@zyxst.net> <CAOjFWZ4Yq4cnWN_qucbN4W-6qtf4NYNzjNKe4QL17DU-Q=N%2B_g@mail.gmail.com> <CAOjFWZ53WaOtCvRtNpsL1OqgE7rDu8jWNEHRVPZ5Z3Q_n1bnqw@mail.gmail.com> <CAOjFWZ6gF3=N8=v3aXQaiG=pd8kmZ-xpvN2jHYj9%2Bh8fCm=rsw@mail.gmail.com> <CAOjFWZ7nPFdKr_G2qHihXdcHUBed7V0uLLHM9=p1PKzJMZNemw@mail.gmail.com> <CAOjFWZ6J7UV_xXxtASqnonS8qatqaSSEqJUKyi9nw%2Bms%2BUg1QQ@mail.gmail.com> <5CFC89E9-57BE-4CB7-9C55-0D3CCF1E8D3D@FreeBSD.org> <edfb5da8-3fad-168f-4dbc-6da9b0822c76@zyxst.net> <20180303234236.M3811@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
03.03.2018 19:56, Bruce Evans wrote:
> On Sat, 3 Mar 2018, tech-lists wrote:
>
>> On 03/03/2018 00:23, Dimitry Andric wrote:
>>> Indeed. I have had the following for a few years now, due to USB drives
>>> with ZFS pools:
>>>
>>> --- /usr/src/etc/rc.d/zfs 2016-11-08 10:21:29.820131000 +0100
>>> +++ /etc/rc.d/zfs 2016-11-08 12:49:52.971161000 +0100
>>> @@ -25,6 +25,8 @@
>>>
>>> zfs_start_main()
>>> {
>>> + echo "Sleeping for 10 seconds to let USB devices settle..."
>>> + sleep 10
>>> zfs mount -va
>>> zfs share -a
>>> if [ ! -r /etc/zfs/exports ]; then
>>>
>>> For some reason, USB3 (xhci) controllers can take a very, very long time
>>> to correctly attach mass storage devices: I usually see many timeouts
>>> before they finally get detected. After that, the devices always work
>>> just fine, though.
>
> I have one that works for an old USB hard drive but never works for a not
> so old USB flash drive and a new SSD in a USB dock (just to check the SSD
> speed when handicapped by USB). Win7 has no problems with the xhci and
> USB flash drive combination, and FreeBSD has no problems with the drive
> on other systems.
>
>>> Whether this is due to some sort of BIOS handover trouble, or due to
>>> cheap and/or crappy USB-to-SATA bridges (even with brand WD and Seagate
>>> disks!), I have no idea. I attempted to debug it at some point, but
>>> a well-placed "sleep 10" was an acceptable workaround... :)
>>
>> That fixed it, thank you again :D
>
> That won't work for the boot drive.
>
> When no boot drive is detected early enough, the kernel goes to the
> mountroot prompt. That seems to hold a Giant lock which inhibits
> further progress being made. Sometimes progress can be made by trying
> to mount unmountable partitions on other drives, but this usually goes
> too fast, especially if the USB drive often times out.
In fact, we have enough loader.conf quirks for that:
kern.cam.boot_delay "Bus registration wait time" # miliseconds
vfs.mountroot.timeout "Wait for root mount" # seconds
vfs.root_mount_always_wait "Wait for root mount holds even if the root device already exists" # boolean
No need in extra hacks to zfs rc.d script.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A9AB09E.6090500>