Re: git: f5f277728ade - main - nfsd: Fix NFS access to .zfs/snapshot snapshots

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Sat, 25 Nov 2023 00:15:06 UTC
On Fri, Nov 24, 2023 at 3:35 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Fri, Nov 24, 2023 at 8:16 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Fri, Nov 24, 2023 at 7:58 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> > >
> > > On Fri, Nov 24, 2023 at 5:18 AM Mike Karels <mike@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 IThelp@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 <rmacklem@FreeBSD.org>
> > > > >>> AuthorDate: 2023-11-23 15:23:33 +0000
> > > > >>> Commit:     Rick Macklem <rmacklem@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.
> > > >