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

[Cy Schubert]

In message <201902261659.x1QGxkl0046685 at pdx.rh.CN85.dnsmgr.net>, 
"Rodney W. Gri
mes" writes:
> > On Tue, Feb 26, 2019 at 10:14 AM Cy Schubert <Cy.Schubert at cschubert.com>
> > wrote:
> > 
> > > On February 26, 2019 7:48:27 AM PST, Cy Schubert <
> > > Cy.Schubert at cschubert.com> wrote:
> > > >On February 26, 2019 12:18:35 AM PST, Baptiste Daroussin
> > > ><bapt at FreeBSD.org> wrote:
> > >
> > 
> > [trimming the unneeded pile of commit body]
> > 
> > 
> > > >This broke my systems, many filesystems fail to mount causing nullfs
> > > >late mounts to fail. No details now until tonight.
> > > >
> > > >Suggest we back this out until it is properly tested.
> > >
> > > Nested zfs filesystems seem not to be handled properly or possibly not
> > > supported any more. This explains my mail gateway also not mounting all
> > > filesystems in /home. It was odd that dovecot stopped working.
> > >
> > > The symptom of the problem is zfs mount -a no longer mounts all
> > > filesystems. Zfs mount fails saying the filesystem is already mounted. Th
> e
> > > workaround is to zfs umount each affected zfs dataset by hand and zfs mou
> nt
> > > it by hand.
> > >
> > > Generally this has screwed up sites that have hundreds (in my case 122)
> > > zfs datasets. The work around might be to script testing each mount,
> > > unmounting and remounting if necessary.
> > >
> > > I'm being sarcastic about creating an rc script to clean this up. This
> > > needs to be backed out and tested properly before being committed.
> > >
> > >
> > I don't know what you mean by "nested zfs filesystems" -- do you mean a
> > zpool within a zvol?
> > That has been unsupported for a long time, IIRC.  And
> That had better not be unsupported, that is the prefered technology
> for all of the virtualization stuff, bhyve, virtualbox, qemu, etc.
>
> I think by nested zfs it sounds like he is talking about datasets
> inside of other datasets just from reading "all filesystems in /home"
>
>
> > I'm not sure what else "nested filesystems" would be, since having (e.g.)
> > separate zfs filesystems for /usr and /usr/ports is so common that surely
> > it has already been tested...
>
> It might be when the intervening dataset is marked canmount=off?
> Though that should fail for the /usr /usr/foo case, as usr is normally
> marked this way.  Maybe some other special case.

I do have some mountpoint=none datasets with mountpoint=/somewhere-else.
 My tank/var tree is a good example of the complete mix using none, 
legacy and specified mountpoints.


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