From owner-freebsd-stable@freebsd.org Sat Mar 3 14:26:57 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18CE8F40926; Sat, 3 Mar 2018 14:26:57 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BC0E8378A; Sat, 3 Mar 2018 14:26:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w23EQlkH001512 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Mar 2018 15:26:48 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: brde@optusnet.com.au Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w23EQhih095788 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 Mar 2018 21:26:43 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: zfs problems after rebuilding system [SOLVED] To: Bruce Evans , tech-lists References: <21c64a2d-b9f9-24c8-88ec-ff1210891f60@zyxst.net> <1dc2b8ef-2914-8182-e2b0-ac637e6b2095@zyxst.net> <65372449-53f1-8002-981a-e20f4a592e26@zyxst.net> <5CFC89E9-57BE-4CB7-9C55-0D3CCF1E8D3D@FreeBSD.org> <20180303234236.M3811@besplex.bde.org> Cc: FreeBSD Filesystems , FreeBSD Stable , Dimitry Andric From: Eugene Grosbein Message-ID: <5A9AB09E.6090500@grosbein.net> Date: Sat, 3 Mar 2018 21:26:38 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20180303234236.M3811@besplex.bde.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 14:26:57 -0000 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.