From owner-freebsd-stable@freebsd.org Thu Mar 16 16:04:29 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9572DD0F2C6 for ; Thu, 16 Mar 2017 16:04:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 734E114C6 for ; Thu, 16 Mar 2017 16:04:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 72B39D0F2C5; Thu, 16 Mar 2017 16:04:29 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 725CAD0F2C4 for ; Thu, 16 Mar 2017 16:04:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A7F314C4 for ; Thu, 16 Mar 2017 16:04:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x244.google.com with SMTP id u69so7676970ita.3 for ; Thu, 16 Mar 2017 09:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/k6LudOukSOZvTaJTp2IV6yhnOL+n4EJL/YQAjadGWM=; b=eWAu8osUQvIubuOeOY9LafstAh6D7p6fkS1dJD9Uk9t36a8VJrSaaBERYUZFTcLAHl ZsDhP8iIR+snmKJsLoffNtOmU8vqE6VWDMpQNwQddpW9W87h6Gic54pc3wWtnAozXCon +k466NLou9GT4oahJppEgR23UsavL2H2p7ggbDBylFo93XIQEVCuy7gGQQnwA21DN8pN AsRh/YCAm8Lf2GK1LJPaSllOvXaUGspdPUJGistBVyzEVY/1FhihD3ErOxXbRqO3UQye q7PlrPBEKbbhfk3BbG/nexL2MOIg8+5Ci8ueamLxx19qVOP2wOPZv1iet/mPE5jucihR hcfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/k6LudOukSOZvTaJTp2IV6yhnOL+n4EJL/YQAjadGWM=; b=AUUcY6ZN/U03AnVSnh2RE7g3wUxg6A79U48NYEDfBxEsNQ3NF0Xw0cVF36sD2c1pLf CmqeU/7xrLsiFqNHLs+sFKrJDK4Hv/9yX3zU2LwWMcgJah65sYnoC4AOOfop7AjB6tJ0 AgA8U4uQKO/eadMYVHoUAk/eG/oMMRuCmVx3qH6kVpG3JqS/qhlmWlUGIFzWjt+AqnQ7 a4MEu5aoaIiULxiunyB129wpkMwSCPr+gwKmcSw0jg7zUZlK7fXLRO60Rv+U/fOTsx+E 9UMqUmFP0B9E1O+oZXVCnYGcgagTjtuX6XgZ64MzNd9W9uTt2xWMT0Lp6xQ9zygPH++I lT1g== X-Gm-Message-State: AFeK/H1qapUzcAx2E+9efKXymQ20m9nqPMf7NmKz2CVsSny7/d4zRw0fqoqTdsAuU9A0FVtekGumlPUCUNh05A== X-Received: by 10.107.198.193 with SMTP id w184mr11044452iof.19.1489680268458; Thu, 16 Mar 2017 09:04:28 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Thu, 16 Mar 2017 09:04:27 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::ad] In-Reply-To: References: <6b397d83-e802-78ca-e24e-6d0713f07212@FreeBSD.org> From: Warner Losh Date: Thu, 16 Mar 2017 10:04:27 -0600 X-Google-Sender-Auth: 0Hp18A9KOqPwy5N30aO1Vq_6coc Message-ID: Subject: Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0 To: Pete French Cc: Andriy Gapon , stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:04:29 -0000 [[ stupid mouse ]] On Thu, Mar 16, 2017 at 10:01 AM, Warner Losh wrote: > On Thu, Mar 16, 2017 at 6:06 AM, Pete French wrote: >>> I don't like the delay and retry approach at all. >> >> Its not ideal, but it is what we do for UFS after all... >> >>> Imagine that you told the kernel that you want to mount your root from a ZFS >>> pool which is on a USB driver which you have already thrown out. Should the >>> kernel just keep waiting for that pool to appear? >> >> I'm not talking about an infinite loop here, just making it honour >> the 'vfs.mountroot.timeout' setting like it does ofr UFS. So it >> should wait for the timeout I have set and then proceed as it would if >> there had been no timeout. Default behaviout is for it to behave as it >> does now, its onyl when you need the retry that you enable it. > > Put another way: With UFS is keeps retrying until the timeout expires. > If the first try succeeds, the boot is immediate. > >> Right now this works for UFS, but not for ZFS, which is an inconsistency >> that I dont like, and also means I am being forced down a UFS root >> path if I require this. > > Yes. ZFS is special, but I don't think the assumptions behind its > specialness are quite right: > > /* > * In case of ZFS and NFS we don't have a way to wait for > * specific device. Also do the wait if the user forced that > * behaviour by setting vfs.root_mount_always_wait=1. > */ > if (strcmp(fs, "zfs") == 0 || strstr(fs, "nfs") != NULL || > dev[0] == '\0' || root_mount_always_wait != 0) { > vfs_mountroot_wait(); > return (0); > } > > So you can make it always succeed by forcing the wait, but that's lame... Later we check to see if a device by a given name is present. Since ZFS doesn't present its pool names as devices to the rest of the system, that's not going to work quite right. That's the real reason that ZFS is special. It isn't that we can't wait for individual devices, it's that we can't wait for the 'mount token' that we use for what to mount to be 'ready'. NFS suffers from the same problem, but since its device is always ready since it's stateless, it isn't as noticeable. Warner