Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Josef Bacik" <josef@toxicpanda.com>
Cc:     "J. Bruce Fields" <bfields@fieldses.org>,
        "Chuck Lever" <chuck.lever@oracle.com>, "Chris Mason" <clm@fb.com>,
        "David Sterba" <dsterba@suse.com>, linux-nfs@vger.kernel.org,
        "Wang Yugui" <wangyugui@e16-tech.com>,
        "Ulli Horlacher" <framstag@rus.uni-stuttgart.de>,
        linux-btrfs@vger.kernel.org
Subject: Re: [PATCH/RFC] NFSD: handle BTRFS subvolumes better.
In-reply-to: <edd94b15-90df-c540-b9aa-8eac89b6713b@toxicpanda.com>
References: <20210613115313.BC59.409509F4@e16-tech.com>,
 <20210310074620.GA2158@tik.uni-stuttgart.de>,
 <162632387205.13764.6196748476850020429@noble.neil.brown.name>,
 <edd94b15-90df-c540-b9aa-8eac89b6713b@toxicpanda.com>
Date:   Fri, 16 Jul 2021 09:02:16 +1000
Message-id: <162639013675.13764.11555673325105489888@noble.neil.brown.name>
Precedence: bulk

On Fri, 16 Jul 2021, Josef Bacik wrote:
>=20
> I'm going to restate what I think the problem is you're having just so I'm =
sure=20
> we're on the same page.
>=20
> 1. We export a btrfs volume via nfsd that has multiple subvolumes.
> 2. We run find, and when we stat a file, nfsd doesn't send along our bogus =

> st_dev, it sends it's own thing (I assume?).  This confuses du/find because=
 you=20
> get the same inode number with different parents.
>=20
> Is this correct?  If that's the case then it' be relatively straightforward=
 to=20
> add another callback into export_operations to grab this fsid right?  Hell =
we=20
> could simply return the objectid of the root since that's unique across the=
=20
> entire file system.  We already do our magic FH encoding to make sure we ke=
ep=20
> all this straight for NFS, another callback to give that info isn't going t=
o=20
> kill us.  Thanks,

Fairly close.
As well as the fsid I need a "mounted-on" inode number, so one callback
to provide both would do.
If zero was reported, that would be equivalent to not providing the
callback.
- Is "u64" always enough for the subvol-id?
- Should we make these details available to user-space with a new STATX
  flag?
- Should it be a new export_operations callback, or new fields in
  "struct kstat" ??

... though having asked those question, I begin to wonder if I took a
wrong turn.
I can already get some fsid information form statfs, though it is only
64bits and for BTRFS is combines the filesystem uuid and the subvol
id.  For that reason I avoided it.

But I'm already caching the fsid for the export-point.  If, when I find
a different fsid lower down, I xor the result with the export-point
fsid, the result would be fairly clean (the xor difference between the
two subvol ids) and could be safely mixed into the fsid we currently
report.

So all I REALLY need from btrfs is a "mounted-on" inode number, matching
what readdir() reports.
I wouldn't argue AGAINST getting cleaner fsid information.  A 128-bit
uuid and a 64bit subvol id would be ideal.
I'd rather see them as new STATX flags than a new export_operations
callback.

NeilBrown