On Fri, Nov 24, 2023 at 3:35 PM Rick Macklem <rick.mack...@gmail.com> wrote:
>
> On Fri, Nov 24, 2023 at 8:16 AM Rick Macklem <rick.mack...@gmail.com> wrote:
> >
> > On Fri, Nov 24, 2023 at 7:58 AM Rick Macklem <rick.mack...@gmail.com> wrote:
> > >
> > > On Fri, Nov 24, 2023 at 5:18 AM Mike Karels <m...@karels.net> wrote:
> > > >
> > > > CAUTION: This email originated from outside of the University of 
> > > > Guelph. Do not click links or open attachments unless you recognize the 
> > > > sender and know the content is safe. If in doubt, forward suspicious 
> > > > emails to ith...@uoguelph.ca.
> > > >
> > > >
> > > > On 24 Nov 2023, at 7:02, Konstantin Belousov wrote:
> > > >
> > > > > On Fri, Nov 24, 2023 at 08:50:22AM +0100, Alexander Leidinger wrote:
> > > > >> Am 2023-11-23 16:25, schrieb Rick Macklem:
> > > > >>> The branch main has been updated by rmacklem:
> > > > >>>
> > > > >>> URL: 
> > > > >>> https://cgit.FreeBSD.org/src/commit/?id=f5f277728adec4c5b3e840a1fb16bd16f8cc956d
> > > > >>>
> > > > >>> commit f5f277728adec4c5b3e840a1fb16bd16f8cc956d
> > > > >>> Author:     Rick Macklem <rmack...@freebsd.org>
> > > > >>> AuthorDate: 2023-11-23 15:23:33 +0000
> > > > >>> Commit:     Rick Macklem <rmack...@freebsd.org>
> > > > >>> CommitDate: 2023-11-23 15:23:33 +0000
> > > > >>>
> > > > >>>     nfsd: Fix NFS access to .zfs/snapshot snapshots
> > > > >>>
> > > > >>>     When a process attempts to access a snapshot under
> > > > >>>     /<dataset>/.zfs/snapshot, the snapshot is automounted.
> > > > >>>     However, without this patch, the automount does not
> > > > >>>     set mnt_exjail, which results in the snapshot not being
> > > > >>>     accessible over NFS.
> > > > >>>
> > > > >>>     This patch defines a new function called vfs_exjail_clone()
> > > > >>>     which sets mnt_exjail from another mount point and
> > > > >>>     then uses that function to set mnt_exjail in the snapshot
> > > > >>>     automount.  A separate patch that is currently a pull request
> > > > >>>     for OpenZFS, calls this function to fix the problem.
> > > > >>
> > > > >> May the same/similar fix like for ZFS be needed / useful for nullfs 
> > > > >> mounted
> > > > >> stuff?
> > > > >>
> > > > >> I have a ZFS dataset which is mounted via nullfs into a jail. This
> > > > >> nullfs-mount is then exported via samba. In samba I have the 
> > > > >> shadow-copy
> > > > >> stuff enabled, but it doesn't work, as the jails can't access the 
> > > > >> snapshot.
> > > > >
> > > > > Jails cannot access snapshots because, as I understand, snapshots
> > > > > are mounts. Nullfs does not provide an option to recursively bypass
> > > > > into mounts. The patch you responded to does not automatically mounts
> > > > > snapshots on clients, it only allows them to mount if wanted.
> > > >
> > > > It works for me, with main and this change, or 13.2 without a patch.
> > > > I don't know the mechanics, but it doesn't use nullfs, and the snapshot
> > > > does not show up as a separate filesystem with the mount command.
> > > Yes. ZFS essentially does an automount of the snapshots under 
> > > .zfs/snapshot.
> > > (As I understand it, there are non-default ZFS options that allow these 
> > > to be
> > >  mounted manually instead.)
> > > I can now see that these automounts are 'real mounts" in the
> > > mountlist. The only reason
> > > they are not visible is that they have MNT_IGNORE set on them.
> > Oh and I forgot to mention that this automount is for some weird in
> > memory file system that does just enough so you can see the snapshots.
> > Once you "cd <some-snapshot>", the vnodes are associated with the ZFS
> > mount (dataset) and not this weird snapshot fs. (That is why it doesn't 
> > need to
> > be exported, but did need mnt_exjail to be set properly.)
> >
> > I might be able to test a nullfs over ZFS case later to-day and will
> > post if I do so.
> Yes, it is broken in a similar way. With a nullfs mount on top of a ZFS mount
> that is exported to an NFS client, you can access the snapshots under
> .zfs/snapshot
> if the mnt_exjail checks are commented out.
> However, if the checks are done, they fail.
>
> So, yes, something similar to what ZFS will do is needed for nullfs.
> Now I have to figure out how/when it can be done. I will play with it to-day,
> but it probably won't get fixed until late Dec.
Oops. Now my test is not working, even when the mnt_exjail check is
commented out.
(When I NFS mount the ZFS <dataset>, I can see the snapshots under
.zfs/snapshot,
but when I NFS mount the nullfs mount that is on top of the ZFS
<dataset> I do not see it.

So, I think Kostik is correct and it does not see the .zfs/snapshot automount.

I don't know how I screwed up on the first test after I disabled the
mnt_exjail check, but
it does not appear to have broken this case after all.

rick

>
> Again, sorry for the breakage, rick
>
> >
> > rick
> >
> > >
> > > Now, as for what happens when nullfs is on top of ZFS, I do not know.
> > > What Kostik says about nullfs recursing into mounts suggests it will not 
> > > work.
> > > I will look at it, but since I am headed to Florida for a few weeks, it 
> > > may
> > > not happen until the end of the year.
> > >
> > > If someone can test this case and determine if there is no NFS client 
> > > access
> > > for snapshots under .zfs after applying the patch that is an
> > > attachment in PR#275200
> > > when nullfs is over the ZFS file system, that would be appreciated.
> > >
> > > rick
> > >
> > > >
> > > >                 Mike
> > > >
> > > > > You might try to set up something with autofs, no idea if it could be 
> > > > > made
> > > > > to work usefully.
> > > >

Reply via email to