From: Christoph Hellwig <hch@infradead.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Amir Goldstein <amir73il@gmail.com>,
Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.com>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>, Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>,
Hongbo Li <lihongbo22@huawei.com>,
Chunhai Guo <guochunhai@vivo.com>,
Carlos Maiolino <cem@kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
Viacheslav Dubeyko <slava@dubeyko.com>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
Luis de Bethencourt <luisbg@kernel.org>,
Salah Triki <salah.triki@gmail.com>,
Phillip Lougher <phillip@squashfs.org.uk>,
Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Bharath SM <bharathsm@microsoft.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Mike Marshall <hubcap@omnibond.com>,
Martin Brandenburg <martin@omnibond.com>,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Ryusuke Konishi <konishi.ryusuke@gmail.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Dave Kleikamp <shaggy@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>, Jan Kara <jack@suse.cz>,
Andreas Gruenbacher <agruenba@redhat.com>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
David Laight <david.laight.linux@gmail.com>,
Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@infradead.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-xfs@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, linux-unionfs@vger.kernel.org,
devel@lists.orangefs.org, ocfs2-devel@lists.linux.dev,
ntfs3@lists.linux.dev, linux-nilfs@vger.kernel.org,
jfs-discussion@lists.sourceforge.net,
linux-mtd@lists.infradead.org, gfs2@lists.linux.dev,
linux-f2fs-devel@lists.sourceforge.net,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 02/31] exportfs: add new EXPORT_OP_STABLE_HANDLES flag
Date: Mon, 19 Jan 2026 23:50:13 -0800 [thread overview]
Message-ID: <aW8ztQ-RbhxwzMk7@infradead.org> (raw)
In-Reply-To: <20260119-exportfs-nfsd-v2-2-d93368f903bd@kernel.org>
On Mon, Jan 19, 2026 at 11:26:19AM -0500, Jeff Layton wrote:
> + EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are
> + stable across the lifetime of a file. This is a hard requirement for export
> + via nfsd. Any filesystem that is eligible to be exported via nfsd must
> + indicate this guarantee by setting this flag. Most disk-based filesystems
> + can do this naturally. Pseudofilesystems that are for local reporting and
> + control (e.g. kernfs, pidfs, nsfs) usually can't support this.
Suggested rewording, taking some of the ideas from Dave Chinners earlier
comments into account:
EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are
stable across the lifetime of a file. A file in this context is an
instantiated inode reachable by one or more file names, or still open after
the last name has been unlinked. Reuses of the same on-disk inode structure
are considered new files and must provide different file handles from the
previous incarnation. Most file systems designed to store user data
naturally provide this capability. Pseudofilesystems that are for local
reporting and control (e.g. kernfs, pidfs, nsfs) usually can't support this.
This flags is a hard requirement for export via nfsd. Any filesystem that
is eligible to be exported via nfsd must indicate this guarantee by
setting this flag.
next prev parent reply other threads:[~2026-01-20 7:50 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 16:26 [PATCH v2 00/31] fs: require filesystems to explicitly opt-in to nfsd export support Jeff Layton
2026-01-19 16:26 ` [PATCH v2 01/31] Documentation: document EXPORT_OP_NOLOCKS Jeff Layton
2026-01-20 7:44 ` Christoph Hellwig
2026-01-20 13:20 ` Jeff Layton
2026-01-20 14:12 ` Jeff Layton
2026-01-20 14:35 ` Jeff Layton
2026-01-21 9:17 ` Christoph Hellwig
2026-01-21 9:58 ` NeilBrown
2026-01-21 12:29 ` Jeff Layton
2026-01-21 22:47 ` NeilBrown
2026-01-19 16:26 ` [PATCH v2 02/31] exportfs: add new EXPORT_OP_STABLE_HANDLES flag Jeff Layton
2026-01-19 16:41 ` Amir Goldstein
2026-01-20 7:50 ` Christoph Hellwig [this message]
2026-01-20 8:40 ` Jan Kara
2026-01-21 9:17 ` Christoph Hellwig
2026-01-20 13:21 ` Jeff Layton
2026-01-19 16:26 ` [PATCH v2 03/31] tmpfs: add EXPORT_OP_STABLE_HANDLES flag to export operations Jeff Layton
2026-01-19 16:26 ` [PATCH v2 04/31] ext4: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 05/31] ext2: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 06/31] erofs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 07/31] efs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 08/31] xfs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 09/31] ceph: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 10/31] btrfs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 11/31] befs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 12/31] ufs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 13/31] udf: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 14/31] affs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 15/31] squashfs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 16/31] smb/client: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 17/31] ovl: " Jeff Layton
2026-01-19 16:42 ` Amir Goldstein
2026-01-19 16:26 ` [PATCH v2 18/31] orangefs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 19/31] ocfs2: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 20/31] ntfs3: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 21/31] nilfs2: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 22/31] nfs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 23/31] jfs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 24/31] jffs2: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 25/31] isofs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 26/31] gfs2: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 27/31] fuse: " Jeff Layton
2026-01-19 16:43 ` Amir Goldstein
2026-01-19 16:26 ` [PATCH v2 28/31] fat: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 29/31] f2fs: " Jeff Layton
2026-01-19 16:26 ` [PATCH v2 30/31] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES Jeff Layton
2026-01-19 16:51 ` Chuck Lever
2026-01-19 16:26 ` [PATCH v2 31/31] nfsd: convert dprintks in check_export() to tracepoints Jeff Layton
2026-01-19 16:47 ` Chuck Lever
2026-01-20 13:42 ` Jeff Layton
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=aW8ztQ-RbhxwzMk7@infradead.org \
--to=hch@infradead.org \
--cc=Dai.Ngo@oracle.com \
--cc=adilger.kernel@dilger.ca \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=amarkuze@redhat.com \
--cc=amir73il@gmail.com \
--cc=anna@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bharathsm@microsoft.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=chao@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=clm@fb.com \
--cc=corbet@lwn.net \
--cc=david.laight.linux@gmail.com \
--cc=david@fromorbit.com \
--cc=devel@lists.orangefs.org \
--cc=dhavale@google.com \
--cc=dsterba@suse.com \
--cc=dwmw2@infradead.org \
--cc=gfs2@lists.linux.dev \
--cc=guochunhai@vivo.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=hubcap@omnibond.com \
--cc=hughd@google.com \
--cc=idryomov@gmail.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=jefflexu@linux.alibaba.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jlayton@kernel.org \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=konishi.ryusuke@gmail.com \
--cc=lihongbo22@huawei.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luisbg@kernel.org \
--cc=mark@fasheh.com \
--cc=martin@omnibond.com \
--cc=miklos@szeredi.hu \
--cc=neil@brown.name \
--cc=ntfs3@lists.linux.dev \
--cc=ocfs2-devel@lists.linux.dev \
--cc=okorniev@redhat.com \
--cc=pc@manguebit.org \
--cc=phillip@squashfs.org.uk \
--cc=richard@nod.at \
--cc=ronniesahlberg@gmail.com \
--cc=salah.triki@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=shaggy@kernel.org \
--cc=slava@dubeyko.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=xiang@kernel.org \
--cc=zbestahu@gmail.com \
/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