From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 199F4342529 for ; Sat, 21 Feb 2026 07:07:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771657627; cv=none; b=WzR/wITWmtgAi72NmwEy3opAwCu2xo2WPjPfeBRrjsXabIlj9++jPEP67aGiKdTItVjRTZZQT3u1/+QfaoM/1gKF5TRWq+MPnz1qZHL+8bghpPzltyPK9eYR5eU+nfZ+X13GthUsvNvh9cG0P7L5q3kWFbr3jOfHVYwxqqVpxfQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771657627; c=relaxed/simple; bh=lMcD6bLCd5KeMlL8cuic9Qf1RrV6sB375uD3CsS2Nd8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uysVrxmWBBuShq9SkEXVGZQkZptA+dwcO7PHsuSQ+1Uar/Vj+6qWJ9nZl93+/A/4OiKwlhSgTBWC2ERppjDiZ7YAYS71vvV/j7qVWNRFO9x7z2hRmaJ7FBOPZkRDWJ+V/OSaDV8gIG8skrXszTMfEcyypYwKZa25zXXhczxHJEE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S3QO1fWm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S3QO1fWm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 995D5C4CEF7; Sat, 21 Feb 2026 07:07:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771657626; bh=lMcD6bLCd5KeMlL8cuic9Qf1RrV6sB375uD3CsS2Nd8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S3QO1fWmk6kKy3LVsTn44ImAS+DGMaS8FpDa68HifEpvPxR6OySG2AOxZ0h0V+nwJ aCp+nNfferiZSAgR4t4wvLsiPeNkP1jxqDgMqr+ZWRJmyRzIpEb5XiT5zsqkptmEMw SYBEeBbnxPhU+E+qrmiuHzF+vWA7sZ1k61edogEY52RmNCZlToZgKzd+uAp4/aRmOj 2nMDeasEhPx4y9+6O9nIPjEqLbgL5/V7mmhT0UTzVM2Q+Bp8y1yYwFq6dJHxRM38Js hE3egPWF0dXMcUyJCOqs1g1grxByez8fxxwdzPk4hYZsV0orBdF/IxwNl1wOw5Z+aM 3HpZsAOjNuvBA== Date: Fri, 20 Feb 2026 23:07:05 -0800 From: "Darrick J. Wong" To: Demi Marie Obenour Cc: Jan Kara , Joanne Koong , Miklos Szeredi , Amir Goldstein , linux-fsdevel@vger.kernel.org, John Groves , Bernd Schubert , Luis Henriques , Horst Birthelmer , lsf-pc Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more Message-ID: <20260221070705.GA11120@frogsfrogsfrogs> References: <20260206060922.GG7693@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Feb 21, 2026 at 01:07:55AM -0500, Demi Marie Obenour wrote: > On 2/6/26 01:09, Darrick J. Wong wrote: > > On Wed, Feb 04, 2026 at 11:43:05AM +0100, Jan Kara wrote: > >> On Wed 04-02-26 01:22:02, Joanne Koong wrote: > >>> On Mon, Feb 2, 2026 at 11:55 PM Miklos Szeredi wrote: > >>>>> I think that at least one question of interest to the wider fs audience is > >>>>> > >>>>> Can any of the above improvements be used to help phase out some > >>>>> of the old under maintained fs and reduce the burden on vfs maintainers? > >>> > >>> I think it might be helpful to know ahead of time where the main > >>> hesitation lies. Is it performance? Maybe it'd be helpful if before > >>> May there was a prototype converting a simpler filesystem (Darrick and > >>> I were musing about fat maybe being a good one) and getting a sense of > >>> what the delta is between the native kernel implementation and a > >>> fuse-based version? In the past year fuse added a lot of new > >>> capabilities that improved performance by quite a bit so I'm curious > >>> to see where the delta now lies. Or maybe the hesitation is something > >>> else entirely, in which case that's probably a conversation better > >>> left for May. > >> > >> I'm not sure which filesystems Amir had exactly in mind but in my opinion > >> FAT is used widely enough to not be a primary target of this effort. It > > > > OTOH the ESP and USB sticks needn't be high performance. > > Yup. Also USB sticks are not trusted. > > >> would be rather filesystems like (random selection) bfs, adfs, vboxfs, > >> minix, efs, freevxfs, etc. The user base of these is very small, testing is > >> minimal if possible at all, and thus the value of keeping these in the > >> kernel vs the effort they add to infrastructure changes (like folio > >> conversions, iomap conversion, ...) is not very favorable. > > > > But yeah, these ones in the long tail are probably good targets. Though > > I think willy pointed out that the biggest barrier in his fs folio > > conversions was that many of them aren't testable (e.g. lack mkfs or > > fsck tools) which makes a legacy pivot that much harder. > > Does it make sense to keep these filesystems around? If all one cares > about is getting the data off of the filesystem, libguestfs with an > old kernel is sufficient. If the VFS changes introduced bugs, an old > kernel might even be more reliable. If there is a way to make sure > the FUSE port works, that would be great. However, if there is no > way to test them, then maybe they should just be dropped. > > >> For these the biggest problem IMO is actually finding someone willing to > >> invest into doing (and testing) the conversion. I don't think there are > >> severe technical obstacles for most of them. > > > > Yep, that's the biggest hurdle -- convincing managers to pay for a bunch > > of really old filesystems that are no longer mainstream. > > Could libguestfs with old guest kernels be a sufficient replacement? > It's not going to be fast, but it's enough for data preservation. In principle it might work, though I have questions about the quality of whatever's internally driving guestmount. Do you know how exactly libguestfs/guestmount accesses (say) an XFS filesystem? I'm curious because libxfs isn't a shared library, so either it would have to manipulate xfs_db (ugh!), run the kernel in a VM layer, or ... do they have their own implementation ala grub? --D > libguestfs supports "fixed appliances", which allow using whatever > kernel one wants. They even provide some as precompiled binaries. > -- > Sincerely, > Demi Marie Obenour (she/her/hers)