From owner-freebsd-stable@freebsd.org  Thu Mar 16 12:06:24 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
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 C80B2D0EC6D
 for <freebsd-stable@mailman.ysv.freebsd.org>;
 Thu, 16 Mar 2017 12:06:24 +0000 (UTC)
 (envelope-from petefrench@ingresso.co.uk)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
 [IPv6:2001:1900:2254:206a::50:5])
 by mx1.freebsd.org (Postfix) with ESMTP id B398C1726
 for <freebsd-stable@freebsd.org>; Thu, 16 Mar 2017 12:06:24 +0000 (UTC)
 (envelope-from petefrench@ingresso.co.uk)
Received: by mailman.ysv.freebsd.org (Postfix)
 id B011FD0EC6C; Thu, 16 Mar 2017 12:06:24 +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 AFC2AD0EC6B
 for <stable@mailman.ysv.freebsd.org>; Thu, 16 Mar 2017 12:06:24 +0000 (UTC)
 (envelope-from petefrench@ingresso.co.uk)
Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 30BBC1725;
 Thu, 16 Mar 2017 12:06:24 +0000 (UTC)
 (envelope-from petefrench@ingresso.co.uk)
Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6]
 helo=dilbert.ingresso.co.uk)
 by constantine.ingresso.co.uk with esmtps
 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD))
 (envelope-from <petefrench@ingresso.co.uk>)
 id 1coUAY-0007mN-AU; Thu, 16 Mar 2017 12:06:14 +0000
Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.89
 (FreeBSD)) (envelope-from <petefrench@ingresso.co.uk>)
 id 1coUAY-0000ou-8i; Thu, 16 Mar 2017 12:06:14 +0000
To: avg@FreeBSD.org, petefrench@ingresso.co.uk, stable@FreeBSD.org
Subject: Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11
 due to lack of waiting for da0
In-Reply-To: <6b397d83-e802-78ca-e24e-6d0713f07212@FreeBSD.org>
Message-Id: <E1coUAY-0000ou-8i@dilbert.ingresso.co.uk>
From: Pete French <petefrench@ingresso.co.uk>
Date: Thu, 16 Mar 2017 12:06:14 +0000
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>, 
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 12:06:24 -0000

> 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.

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.

> Microsoft provides support for FreeBSD Hyper-V drivers.
> Please try to discuss this problem on virtualization@ or with sephe@ directly.

OK, will do, thanks...

-pete.