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

Cy Schubert Cy.Schubert at cschubert.com
Wed Feb 27 13:24:48 UTC 2019


In message <19c0f590-4327-d2c8-4660-bd9f5df12b50 at FreeBSD.org>, Andriy 
Gapon wri
tes:
> On 27/02/2019 15:04, Cy Schubert wrote:
> > 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 c
> omm
> >> 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 p
> ath
> >> 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.

That was my fault but given I was using an email client on my phone, 
removing the quoted text would have taken forever. Usually in that 
circumstance I wait until I get to a real keyboard before firing off an 
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/freebs
> d/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/sr
> c/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 paral
> lel
> >> mounting.  And I guess that this is a kind of problem that you might actua
> lly
> >> 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.

NP. I'm glad it's fixed too.


-- 
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.




More information about the svn-src-head mailing list