From owner-freebsd-stable@freebsd.org Thu Mar 16 16:01:37 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 24994D0F085 for ; Thu, 16 Mar 2017 16:01:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 0301C1142 for ; Thu, 16 Mar 2017 16:01:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 02114D0F084; Thu, 16 Mar 2017 16:01:37 +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 01B12D0F083 for ; Thu, 16 Mar 2017 16:01:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 C6E22113E for ; Thu, 16 Mar 2017 16:01:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id g138so49170333itb.0 for ; Thu, 16 Mar 2017 09:01:36 -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=oZmRsnBGn0zPaE2QXetdFys2m1AtFZhubF+gVNfUbcE=; b=i/lC6sPEHrEhnN1KNHRSyBG/DtxQ/5QRy5NdwcaoF3nETLJdRLQIWPnL1uNhnpvG/W 7xqhuzqF6CQTw33wO0r2R3KhdvaqdQQs1N4l/5HuKjt0wvVY45MOk7CCiyyybqY2kZYu zWebdtnvAevJKxI5FIxk52D1LNA+51hxvs5nJTenYL050Jak6VCUtkhwfQSmmKjQwqmI d4CgwM3wgcs2XnyYGC7c78ji/mkd4LZHGKnYpkCbNxs7NkfaHgV7EHw+eow1hlVMMd6I 6HfIFMk+D4bShWCIov18v2JWngNzyQI9RaMTJyMS+gEF0pLzM4awRfdPgV2bIhOgN0ma XNWA== 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=oZmRsnBGn0zPaE2QXetdFys2m1AtFZhubF+gVNfUbcE=; b=N019ocPefj0OT7sa8A8QIJVGCrQkMtmpH/2B/b7KW2hBcSVfcjMs8nB0WyePIkWRTY 3OA2CL/IMVMl9WqRqXJuU6ZTjlfA/YmhQrSzN1rjV+bLlvSyYBUMI/lAEJmWJ/z84jfk wEFzBwExIKHtLjlfLRK013Gg1uFmGWW72Kpo+NOVCQUfNsY0UaWaVBAZu6aCzD+GxBFC Rq77BuAtKi36UN8G7pSi4vtF+AGaMzrrSr/2PGQliOFLvt1UI2c4XN39cn8rhmfbaSw3 J9OEIeOUx0SSTkry2zcFbSlzu+9Y+K4eu9WQ/SouBh9R1fcNnoRodYeAvX1qdCayhIU1 VzvQ== X-Gm-Message-State: AFeK/H2Bc641SSbkUqvtcd540fGK1DJUG2ANe1XJlHR62McpmhihyrfClrKFGXQEPdl8uqeJ15T2vJez2BO+Gw== X-Received: by 10.107.174.220 with SMTP id n89mr11693976ioo.166.1489680093844; Thu, 16 Mar 2017 09:01:33 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Thu, 16 Mar 2017 09:01:33 -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:01:33 -0600 X-Google-Sender-Auth: uz-sR8VUeqlE6YQ9dj2u8Xpx1io 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:01:37 -0000 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...