svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common
Andriy Gapon
avg at FreeBSD.org
Wed Feb 27 13:10:11 UTC 2019
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 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
More information about the svn-src-head
mailing list