Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
MIME-Version: 1.0
References: <20231024110109.3007794-1-amir73il@gmail.com> <1CFE0178-CE91-4C99-B43E-33EF78D0BEBF@redhat.com>
 <CAOQ4uxhe5pH3yRxFS_8pvtCgbXspKB6r9aacRJ8FysGQE2Hu9g@mail.gmail.com>
 <2382DA9B-D66B-41D9-8413-1C5319C01165@redhat.com> <CAOQ4uxho0ryGuq7G+LaoTvqHRR_kg2fCNL2sGMLvNujODA8YPQ@mail.gmail.com>
 <41F5B54F-0345-4C44-99FB-6E2A6C9F365C@redhat.com>
In-Reply-To: <41F5B54F-0345-4C44-99FB-6E2A6C9F365C@redhat.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Wed, 25 Oct 2023 06:20:02 +0300
Message-ID: <CAOQ4uxgFybKV5WG5fQtzG0HD3TkxcGD-+CuwU7DBwNG4HOvQNQ@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 9:01=E2=80=AFPM Benjamin Coddington <bcodding@redha=
t.com> wrote:
>
> On 24 Oct 2023, at 13:12, Amir Goldstein wrote:
> > On Tue, Oct 24, 2023 at 6:32=E2=80=AFPM Benjamin Coddington <bcodding@r=
edhat.com> wrote:
> >> Yes, but if the specific export is on the same server's filesystem as =
the
> >> "root", you'll still get zero.  There are various ways to set fsid on
> >> exports for linux servers, but the fsid will be the same for all expor=
ts of
> >> the same filesystem on the server.
> >>
> >
> > OK. good to know. I thought zero fsid was only for the root itself.
>
> Yes, but by "root" here I always mean the special NFSv4 root - the specia=
l
> per-server global root filehandle.
>
> ...
>
> >> I'm not familiar with fanotify enough to know if having multiple fsid =
0
> >> mounts of different filesystems on different servers will do the right
> >> thing.  I wanted to point out that very real possibility for v4.
> >>
> >
> > The fact that fsid 0 would be very common for many nfs mounts
> > makes this patch much less attractive.
> >
> > Because we only get events for local client changes, we do not
> > have to tie the fsid with the server's fsid, we could just use a local
> > volatile fsid, as we do in other non-blockdev fs (tmpfs, kernfs).
>
> A good way to do this would be to use the nfs_server->s_dev's major:minor=
 -
> this represents the results of nfs_compare_super(), so it should be the s=
ame
> value if NFS is treating it as the same filesystem.
>

Yes, that would avoid local collisions and this is what we are going
to do for most of the simple fs with anon_bdev [1].

But anon_bdev major is 0 and minor is quickly recyclable.
fanotify identified objects by {f_fsid, f_handle} pair.
Since nfs client encodes persistent file handles, I would like to try to ho=
ld
its f_fsid to higher standards than those of the simple fs.

You say that server->fsid.minor is always 0.
Perhaps we should mix server->fsid.major with server->s_dev's minor?

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/20231023143049.2944970-1-amir73il=
@gmail.com/