From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Miklos Szeredi'" <miklos@szeredi.hu>,
"'Christoph Hellwig'" <hch@infradead.org>
Cc: "'NeilBrown'" <neilb@suse.de>,
"'J. Bruce Fields'" <bfields@fieldses.org>,
"'Chuck Lever'" <chuck.lever@oracle.com>,
"'Linux NFS list'" <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: Thu, 2 Sep 2021 07:16:21 -0700 [thread overview]
Message-ID: <024601d7a005$1b3863c0$51a92b40$@mindspring.com> (raw)
In-Reply-To: <CAJfpegu7rwoFXdtLusyRhrtFgMPxRShesxnBT2Q6iiC_iSGsfg@mail.gmail.com>
> On Thu, 2 Sept 2021 at 09:18, Christoph Hellwig <hch@infradead.org> wrote:
>
> > > Your attitude seems to be that this is a btrfs problem and must be
> > > fixed in btrfs.
> >
> > Yes.
>
> st_ino space issues affect overlayfs as well. The two problems are
> not the same, but do share some characteristics. And this limitation will likely
> come up again in the future.
>
> I suspect the long term solution would involve introducing new userspace API
> (variable length inode numbers) and deprecating st_ino.
> E.g. make stat return an error if the inode number doesn't fit into st_ino and add
> a statx extension to return the full number. But this would be a long process...
But then what do we do where fileid in NFS is only 64 bits?
The solution of giving each subvol a separate fsid is the only real solution to enlarging the NFS fileid space, however that has downsides on the client side.
Frank
next prev parent reply other threads:[~2021-09-02 14:24 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 ` [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export Christoph Hellwig
2021-09-01 15:22 ` 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 [this message]
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='024601d7a005$1b3863c0$51a92b40$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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).