From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F07F5D4662E for ; Thu, 15 Jan 2026 21:38:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 473286B008A; Thu, 15 Jan 2026 16:38:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4201D6B00CE; Thu, 15 Jan 2026 16:38:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F81E6B00CF; Thu, 15 Jan 2026 16:38:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1C49A6B008A for ; Thu, 15 Jan 2026 16:38:04 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C259013B144 for ; Thu, 15 Jan 2026 21:38:03 +0000 (UTC) X-FDA: 84335511246.19.F0DBA93 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf13.hostedemail.com (Postfix) with ESMTP id AAF5D20004 for ; Thu, 15 Jan 2026 21:38:01 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cNYvRCtA; spf=pass (imf13.hostedemail.com: domain of cel@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cel@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1768513081; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bIvvdJO8RSmQOYhZYgNuTCBL8X7KIXl7wt2Qia9EIAk=; b=MmocyqqLHzcnWqL3ssT0y3Znkz4FNAEnlhQCGqz99WHiYmLo85KiCDwn2uI6kqSxHcGbmp DjTn3oAVcKuePc3Snnem+LbiZWhCi5jDe8sjAs5qqEo3gTspbNnyGIJg01PGd0ZWVMYUAJ WaH03Hx4OHxTzuoWVMyCTvXrYPOjD/I= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cNYvRCtA; spf=pass (imf13.hostedemail.com: domain of cel@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cel@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1768513081; a=rsa-sha256; cv=none; b=npvY/ROEk3QQZTxU5WVPmYqqeiDaMPA11VSdy9hu4/yIGggCBMkX2hwTLGWPkgulYjUMS5 KNUuxDJyFU3qdRIq+PfJ311VSlYVSe+y2h2PGxwLF71PFvSwCYkap/rxWiJyqmDW7wE61B jn94vtGtmUQ7CU8tGwfKNyu32HEO6Eo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 653E060167; Thu, 15 Jan 2026 21:38:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10E7EC4AF0E; Thu, 15 Jan 2026 21:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768513080; bh=0fqCmxD4yKmMSe6/QFTJtZ3ssoTn2Cuf5H+QMDU346c=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=cNYvRCtAFr3nio6ZJmSXonm+4Nbnqg0ooZICNUqxoP7XTHZvA1sq5emt+58bZli1v oJkAFDqsC8s9exFsPnwjrufRoIKYcNVLkronVW7KfwhObFyoMdVkQc5HZF/9RGxbhF F8t+tIqxHXmQeBkIAg74UokUULOqKsZjdX1zKlQqnLNffUaBGWeNAgAEVlrJmM1boN LUW1r4fLYT+64uz3Pbcw+N6aibwePtoH6t9exvd7VQjlJQQfeBnIAca7oYTbPKx1xL 5lZKkhqKesuIWnoeYbXAqAZWFIhec2xBYGvSLr8p1N4f33jTCoUrpWPHuga5OksBPp OM0ntrYikD9aw== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id F1990F4006D; Thu, 15 Jan 2026 16:37:57 -0500 (EST) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Thu, 15 Jan 2026 16:37:58 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduvdejudehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfvehhuhgt khcunfgvvhgvrhdfuceotggvlheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpeegheduieeiveevheelheelueeghffhtddtheelhfdutddtheeileetkeelvedtjeen ucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheptghhuhgtkhhlvghvvghrodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduieefgeelleelheelqdefvdelkeeggedvfedqtggvlh eppehkvghrnhgvlhdrohhrghesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthho peehtddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepnhgvihhlsegsrhhofihnrd hnrghmvgdprhgtphhtthhopegrughilhhgvghrrdhkvghrnhgvlhesughilhhgvghrrdgt rgdprhgtphhtthhopehslhgrvhgrseguuhgsvgihkhhordgtohhmpdhrtghpthhtohepjh hlsggvtgesvghvihhlphhlrghnrdhorhhgpdhrtghpthhtohepmhgrrhhksehfrghshhgv hhdrtghomhdprhgtphhtthhopegtlhhmsehfsgdrtghomhdprhgtphhtthhopegurghvih gusehfrhhomhhorhgsihhtrdgtohhmpdhrtghpthhtoheprghmihhrjeefihhlsehgmhgr ihhlrdgtohhmpdhrtghpthhtohepihgurhihohhmohhvsehgmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: ifa6e4810:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id B4F44780070; Thu, 15 Jan 2026 16:37:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: A7-j_yKLHrMN Date: Thu, 15 Jan 2026 16:37:27 -0500 From: "Chuck Lever" To: "Dave Chinner" Cc: "Amir Goldstein" , "Jeff Layton" , "Christian Brauner" , "Alexander Viro" , "Chuck Lever" , NeilBrown , "Olga Kornievskaia" , "Dai Ngo" , "Tom Talpey" , "Hugh Dickins" , "Baolin Wang" , "Andrew Morton" , "Theodore Tso" , "Andreas Dilger" , "Jan Kara" , "Gao Xiang" , "Chao Yu" , "Yue Hu" , "Jeffle Xu" , "Sandeep Dhavale" , "Hongbo Li" , "Chunhai Guo" , "Carlos Maiolino" , "Ilya Dryomov" , "Alex Markuze" , "Viacheslav Dubeyko" , "Chris Mason" , "David Sterba" , "Luis de Bethencourt" , "Salah Triki" , "Phillip Lougher" , "Steve French" , "Paulo Alcantara" , "Ronnie Sahlberg" , "Shyam Prasad N" , "Bharath SM" , "Miklos Szeredi" , "Mike Marshall" , "Martin Brandenburg" , "Mark Fasheh" , "Joel Becker" , "Joseph Qi" , "Konstantin Komarov" , "Ryusuke Konishi" , "Trond Myklebust" , "Anna Schumaker" , "Dave Kleikamp" , "David Woodhouse" , "Richard Weinberger" , "Jan Kara" , "Andreas Gruenbacher" , "OGAWA Hirofumi" , "Jaegeuk Kim" , "Christoph Hellwig" , 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 Message-Id: <06dcc4b6-7457-4094-a1c6-586ce518020f@app.fastmail.com> In-Reply-To: References: <20260115-exportfs-nfsd-v1-0-8e80160e3c0c@kernel.org> <4d9967cc-a454-46cf-909b-b8ab2d18358d@kernel.org> Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AAF5D20004 X-Stat-Signature: s4djty5dxgsj8ymdxj8em5zh93gx16sr X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1768513081-198291 X-HE-Meta: U2FsdGVkX1+XyecEK+eHauQdBcRv+d4HnUC5lwNFLv/XQ6ccH28SprMxLkCY7o9qJU2o467LcCEoirJrW9gk3ixo3UC+tM1CE8lvXCuilJSjwlYEuLJb3WyLTrv6hoqNgciMtEX42BJVYMOG0k82erajuCYrRcg1q4ZRXCISzQe1yGuQa0SpkzuZuGv586ZOZyezuL3wkiDe4+MhDVuwfkJjqiJ+bm9HiYFeaCAvIuV3soWJdqt/HVYh86JCusI7i1UJbi3VzvW6ES5DPCn3rkGUUsN3bhRSLIlvIIwp/xorzKPm7v/7xTqHxkfseyMvAzuNYQbUHh3NjaHkTPWjxLsY6fHyCJ6Jhk93rfFoGYz+H338krqQrrpEOCWdfIV83PoYRYv5sEs3dKncWu7MHh/FOCBc/4VyrV/xawrCTRByHPlBXK0n4tUrRwmYMq1Z3ldB6hozR/4nUjt6tJ0+z/KYO6M5HDFI41hX8X+tn00ozXkzKw/VU1iRJQgxxn1fgR3kMjItk3KaWQpVQeX0eU0PYTKYxb+QNyvJr88r3Ih+NT9STd9oBPE45iUzHh89Ejy/BkvJjyMezPeWz2Z27eNBg5Z3cWH+KrzdqpWlR/JznZqmxzcHPNS8D2R6N8EeOZeWLxfNT70lOqisl8sIFy1gUPWU9ewA6iiIl+pYcbZZBZ+5yJothE7VJLYstkg+Cl5igJqWzH9dQIYdR+8BjZhhYBHf/tG5fRJKsBCOtbTzddTjBaVSUjf8uqLk+Uf/+tMtFUswBWYil745pZfLfg4RcTwO+5hNzCLKSW9sDV7vJESqbR7GKaBkhY4A2SXQGg9Aflb148I0vI4NG8lfxalehygHOyeQrve9ATxdDR4HozBGzgWg1E5qh4u3NJeWc6rUZpObmL2N5eimCcgMffUv5BH3H4PpDy0qPs+sy6ibkiW16HVAzzxYVtCChL/HoKjha1CTmAwbaPD5Qtw 16IndwAm 5JVUctghDtrI0HrUbdy9F6hN6cfFcLj40xYUml55Pv8lil1Zjxa3nCngyx6WXYgUugvoQt7DgernEvF7AthEmdgWILn90CY38KEEaQzbCu1+7rnx958B81QsVntBzyiMrK3Qub7jRoMjcRJaABTqWZghMJp+lTEJN7fYLuNPyB0qSBjWeK8qIqwStq4e8MXmiwEX2y/iSzUSRwTXGAx8ZgTgrrVNLuYJ0dC8AFNrCZtT3D74kqXvYxR6XG1f+2GRhNkpre6zS2eggim/wmqeQGKKNhyGkG9n8N3sjXIKmuXq1OWY7yHscQCJczTOUFvhIJWv7xaR0Q4Ef8QM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 15, 2026, at 4:09 PM, Dave Chinner wrote: > On Thu, Jan 15, 2026 at 02:37:09PM -0500, Chuck Lever wrote: >> On 1/15/26 2:14 PM, Amir Goldstein wrote: >> > On Thu, Jan 15, 2026 at 7:32=E2=80=AFPM Chuck Lever wrote: >> >> >> >> >> >> >> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote: >> >>> On Thu, Jan 15, 2026 at 6:48=E2=80=AFPM Jeff Layton wrote: >> >>>> >> >>>> In recent years, a number of filesystems that can't present stab= le >> >>>> filehandles have grown struct export_operations. They've mostly = done >> >>>> this for local use-cases (enabling open_by_handle_at() and the l= ike). >> >>>> Unfortunately, having export_operations is generally sufficient = to make >> >>>> a filesystem be considered exportable via nfsd, but that require= s that >> >>>> the server present stable filehandles. >> >>> >> >>> Where does the term "stable file handles" come from? and what doe= s it mean? >> >>> Why not "persistent handles", which is described in NFS and SMB s= pecs? >> >>> >> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked >> >>> by both Christoph and Christian: >> >>> >> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-= 12018e93c00c@brauner/ >> >>> >> >>> Am I missing anything? >> >> >> >> PERSISTENT generally implies that the file handle is saved on >> >> persistent storage. This is not true of tmpfs. >> >=20 >> > That's one way of interpreting "persistent". >> > Another way is "continuing to exist or occur over a prolonged perio= d." >> > which works well for tmpfs that is mounted for a long time. >>=20 >> I think we can be a lot more precise about the guarantee: The file >> handle does not change for the life of the inode it represents. It > > > > File handles most definitely change over the life of a /physical/ > inode. Unlinking a file does not require ending the life of the > physical object that provides the persistent data store for the > file. > > e.g. XFS dynamically allocates physical inodes might in a life cycle > that looks somewhat life this: > > allocate physical inode > insert record into allocated inode index > mark inode as free > > while (don't need to free physical inode) { > ... > allocate inode for a new file > update persistent inode metadata to generate new filehandle > mark inode in use > ... > unlink file > mark inode free > } > > remove inode from allocated inode index > free physical inode > > i.e. a free inode is still an -allocated, indexed inode- in the > filesystem, and until we physically remove it from the filesystem > the inode life cycle has not ended. > > IOWs, the physical (persistent) inode lifetime can span the lifetime > of -many- files. However, the filesystem guarantees that the handle > generated for that inode is different for each file it represents > over the whole inode life time. > > Hence I think that file handle stability/persistence needs to be > defined in terms of -file lifetimes-, not the lifetimes of the > filesystem objects implement the file's persistent data store. Fair enough, "inode" is the wrong term to use here. --=20 Chuck Lever