From owner-freebsd-stable@freebsd.org Sat Mar 3 12:56:54 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 ECFFFF39BB3; Sat, 3 Mar 2018 12:56:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 66B088005E; Sat, 3 Mar 2018 12:56:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 5B11442B126; Sat, 3 Mar 2018 23:56:50 +1100 (AEDT) Date: Sat, 3 Mar 2018 23:56:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: tech-lists cc: Dimitry Andric , FreeBSD Filesystems , FreeBSD Stable Subject: Re: zfs problems after rebuilding system [SOLVED] In-Reply-To: Message-ID: <20180303234236.M3811@besplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VJytp5HX c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=SY9sppriGsu9APizm8IA:9 a=6AGLiD1o6bKYU7sQ:21 a=jMnuJzigikWx0_6H:21 a=CjuIK1q_8ugA:10 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 12:56:54 -0000 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. Bruce