Date: Wed, 27 Feb 2019 15:10:00 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: 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: <19c0f590-4327-d2c8-4660-bd9f5df12b50@FreeBSD.org> In-Reply-To: <201902271304.x1RD4S6U051477@slippy.cwsent.com> References: <201902271304.x1RD4S6U051477@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/02/2019 15:04, Cy Schubert wrote: > 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 Apologies, I failed to read your original email when I first saw it. I pressed Page Down a few times but was still seeing only a quoted text, so I gave up. > 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. Okay. Great that it is fixed and sorry for my noise. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19c0f590-4327-d2c8-4660-bd9f5df12b50>