From: Christoph Hellwig <hch@infradead.org>
To: NeilBrown <neilb@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>,
linux-nfs@vger.kernel.org, Josef Bacik <josef@toxicpanda.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
Date: Wed, 1 Sep 2021 08:20:06 +0100 [thread overview]
Message-ID: <YS8ppl6SYsCC0cql@infradead.org> (raw)
In-Reply-To: <163038594541.7591.11109978693705593957@noble.neil.brown.name>
On Tue, Aug 31, 2021 at 02:59:05PM +1000, NeilBrown wrote:
> Making the change purely in btrfs is simply not possible. There is no
> way for btrfs to provide nfsd with a different inode number. To move
> the bulk of the change into btrfs code we would need - at the very least
> - some way for nfsd to provide the filehandle when requesting stat
> information. We would also need to provide a reference filehandle when
> requesting a dentry->filehandle conversion. Cluttering the
> export_operations like that just for btrfs doesn't seem like the right
> balance. I agree that cluttering kstat is not ideal, but it was a case
> of choosing the minimum change for the maximum effect.
So you're papering over a btrfs bug by piling up cludges in the nsdd
code that has not business even knowing about this btrfs bug, while
leaving other users of inodes numbers and file handles broken?
If you only care about file handles: this is what the export operations
are for. If you care about inode numbers: well, it is up to btrfs
to generate uniqueue inode numbers. It currently doesn't do that, and
no amount of papering over that in nfsd is going to fix the issue.
If XORing a little more entropy into the inode number is a good enough
band aid (and I strongly disagree with that), do it inside btrfs for
every place they report the inode number. There is nothing NFS-specific
about that.
next parent reply other threads:[~2021-09-01 7:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <162995209561.7591.4202079352301963089@noble.neil.brown.name>
[not found] ` <162995778427.7591.11743795294299207756@noble.neil.brown.name>
[not found] ` <YSkQ31UTVDtBavOO@infradead.org>
[not found] ` <163010550851.7591.9342822614202739406@noble.neil.brown.name>
[not found] ` <YSnhHl0HDOgg07U5@infradead.org>
[not found] ` <163038594541.7591.11109978693705593957@noble.neil.brown.name>
2021-09-01 7:20 ` Christoph Hellwig [this message]
2021-09-01 15:22 ` [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export J. Bruce Fields
2021-09-02 4:14 ` NeilBrown
2021-09-05 16:07 ` J. Bruce Fields
2021-09-06 1:29 ` NeilBrown
2021-09-11 14:12 ` Amir Goldstein
2021-09-13 0:43 ` NeilBrown
2021-09-13 10:04 ` Amir Goldstein
2021-09-13 22:59 ` NeilBrown
2021-09-14 5:45 ` Amir Goldstein
2021-09-20 22:09 ` NeilBrown
2021-09-02 7:11 ` Christoph Hellwig
2021-09-02 4:06 ` NeilBrown
2021-09-02 7:16 ` Christoph Hellwig
2021-09-02 7:53 ` Miklos Szeredi
2021-09-02 14:16 ` Frank Filz
2021-09-02 23:02 ` NeilBrown
2021-07-27 22:37 [PATCH/RFC 00/11] expose btrfs subvols in mount table correctly NeilBrown
2021-08-13 1:45 ` [PATCH] VFS/BTRFS/NFSD: provide more unique inode number for btrfs export NeilBrown
2021-08-15 7:39 ` Goffredo Baroncelli
2021-08-15 19:35 ` Roman Mamedov
2021-08-15 22:17 ` NeilBrown
2021-08-23 4:05 ` [PATCH v2] BTRFS/NFSD: " NeilBrown
2021-08-23 8:17 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YS8ppl6SYsCC0cql@infradead.org \
--to=hch@infradead.org \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=josef@toxicpanda.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).