Date: Sat, 8 Apr 2017 11:59:00 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Pete French <petefrench@ingresso.co.uk>, stable@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0 Message-ID: <20170408105900.GA14604@brick> In-Reply-To: <CANCZdfpUa6GX2OVT70g4fCM2SwAcdN2ghMFO9UPeN%2BDC3Pa%2B6Q@mail.gmail.com> References: <6b397d83-e802-78ca-e24e-6d0713f07212@FreeBSD.org> <E1coUAY-0000ou-8i@dilbert.ingresso.co.uk> <CANCZdfpx7gO8O-%2Bt41HwS5tkjakzMntw7WJ9N5pnR%2B88DzJL=Q@mail.gmail.com> <CANCZdfpUa6GX2OVT70g4fCM2SwAcdN2ghMFO9UPeN%2BDC3Pa%2B6Q@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 0316T1004, Warner Losh wrote:
> [[ stupid mouse ]]
>
> On Thu, Mar 16, 2017 at 10:01 AM, Warner Losh <imp@bsdimp.com> wrote:
> > On Thu, Mar 16, 2017 at 6:06 AM, Pete French <petefrench@ingresso.co.uk> 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.
Not sure what you mean. The problem we handle ZFS and NFS in
a different way (always waiting) is _exactly_ so that we don't
have a way to wait for the individual device, like we can for
eg UFS, and we have to fall back to mount tokens, which were
used unconditionally before 11.0.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170408105900.GA14604>