svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common

[Cy Schubert]

In message <0563e72c-c9e3-a476-ce43-d4a67c454508 at 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 at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.