Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
MIME-Version: 1.0
References: <20231024110109.3007794-1-amir73il@gmail.com> <1CFE0178-CE91-4C99-B43E-33EF78D0BEBF@redhat.com>
In-Reply-To: <1CFE0178-CE91-4C99-B43E-33EF78D0BEBF@redhat.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Tue, 24 Oct 2023 17:58:57 +0300
Message-ID: <CAOQ4uxhe5pH3yRxFS_8pvtCgbXspKB6r9aacRJ8FysGQE2Hu9g@mail.gmail.com>
Subject: Re: [PATCH] nfs: derive f_fsid from server's fsid
To:     Benjamin Coddington <bcodding@redhat.com>
Cc:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        Jeff Layton <jlayton@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Christian Brauner <brauner@kernel.org>,
        Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org,
        linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Oct 24, 2023 at 5:01=E2=80=AFPM Benjamin Coddington <bcodding@redha=
t.com> wrote:
>
> On 24 Oct 2023, at 7:01, Amir Goldstein wrote:
>
> > Fold the server's 128bit fsid to report f_fsid in statfs(2).
> > This is similar to how uuid is folded for f_fsid of ext2/ext4/zonefs.
> >
> > This allows nfs client to be monitored by fanotify filesystem watch
> > for local client access if nfs supports re-export.
> >
> > For example, with inotify-tools 4.23.8.0, the following command can be
> > used to watch local client access over entire nfs filesystem:
> >
> >   fsnotifywatch --filesystem /mnt/nfs
> >
> > Note that fanotify filesystem watch does not report remote changes on
> > server.  It provides the same notifications as inotify, but it watches
> > over the entire filesystem and reports file handle of objects and fsid
> > with events.
>
> I think this will run into trouble where an NFSv4 will report both
> fsid.major and fsid.minor as zero for the special root filesystem.   We c=
an
> expect an NFSv4 client to have one of these per server.
>
> Could use s_dev from nfs_server for a unique major/minor for each mount o=
n
> the client, but these values won't be stable against a particular server
> export.
>

That's a good point.
Not sure I understand the relation between mount/server/export.

If the client mounts the special NFSv4 root filesystem at /mnt/nfs,
are the rest of the server exports going to be accessible via the same
mount/sb or via new auto mounts of different nfs sb?

In any case, f_fsid does not have to be uniform across all inodes
of the same sb. This is the case with btrfs, where the the btrfs sb
has inodes from the root volume and from sub-volumes.
inodes from btrfs sub-volumes have a different f_fsid than inodes
in the root btrfs volume.

We try to detect this case in fanotify, which currently does not
support watching btrfs sub-volume for that reason.
I have a WIP branch [1] for handling non-uniform f_fsid in
fanotify by introducing the s_op->get_fsid(inode) method.

Anyway, IIUC, my proposed f_fsid change is going to be fine for
NFSv2/3 and best effort for NFSv4:
- For NFSv2/3 mount, f_fsid is a good identifier?
- For NFSv4 mount of a specific export, f_fsid is a good identifier?
- For the NFSv4 root export mount, f_fsid remains zero as it is now

Am I understanding this correctly?
Do you see a reason not to make this change?
Do you see a reason to limit this change for NFSv2/3?

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/inode_fsid