Date: Wed, 27 Feb 2019 05:04:28 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Baptiste Daroussin <bapt@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-head@FreeBSD.ORG, Jack Halford <jack@gandi.net> Subject: Re: svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common Message-ID: <201902271304.x1RD4S6U051477@slippy.cwsent.com> In-Reply-To: Message from Andriy Gapon <avg@FreeBSD.org> of "Wed, 27 Feb 2019 09:12:13 %2B0200." <0563e72c-c9e3-a476-ce43-d4a67c454508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <0563e72c-c9e3-a476-ce43-d4a67c454508@FreeBSD.org>, Andriy Gapon wri tes: > On 26/02/2019 22:58, Cy Schubert wrote: > > I was talking about nested datasets, i.e. tank/freebsd/git/current and > > tank/freebsd/git/ports are four levels deep. > > We usually don't call them "nested". In fact, I don't think that we call the > m > anything special because having N levels deep datasets (N > 1) is just a comm > on > thing. We may call them subordinate or child datasets when mentioning a > relation to a parent dataset. > > > In my case the ports > > dataset was mounted while the current dataset was not, though zfs > > believed it was. unmounting the current dataset and remounting it, zfs > > umount .../current; zfs mount .../current worked around the issue. > > Are you sure that it was not mounted? Yes. > Have you checked that by looking at mount output? Yes > I suspect that it was mounted, just not where you expected and its mount path > was covered by another filesystem. If you read my original email a zfs umount followed by a zfs mount for each affected filesystem worked around the problem. zfs properties showed that each and every filesystem was mounted. mount(1) and df(1) confirmed they were not. Furthermore nullfs mounts with the late attribute failed to mount because their underlying zfs datasets were not mounted -- this is what clued me into the problem in the first place, a FreeBSD system dropping into single user at boot. And, no, fstab on that machine had not been changed for months, them machine failed to boot. So, no, I was not mistaken. I was rather displeased because I had to try to fix the problem using ssh on a phone to a machine connected to a console server. > > E.g., lets consider this hypothetical case. > I have two same level datasets tank/freebsd/src and tank/freebsd/sys where > tank/freebsd/src is mounted at /usr/src and tank/freebsd/sys is mounted at > /usr/src/sys (a child directory of /usr/src). > If tank/freebsd/src is mounted first, then everything is okay, tank/freebsd/s > ys > would be mounted on top of sys directory in tank/freebsd/src. > If, however, tank/freebsd/sys is mounted first (assuming that path /usr/src/s > ys > exists in a root filesystem), then mounting tank/freebsd/src would simply hid > e > tank/freebsd/sys "below" it as /usr/src/sys would be sys directory in > tank/freebsd/src. > > I guess that this is a kind of problem that could be introduced with parallel > mounting. And I guess that this is a kind of problem that you might actually > have. But it's just a guess. No. I had not mistakenly mounted the datasets elsewhere, mistakenly deleted them or mistakenly changed their mount attributes. It was a real, not imagined, regression fixed by the patch posted near the end of the email thread. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201902271304.x1RD4S6U051477>