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 E471B3EBF05 for ; Fri, 6 Feb 2026 06:09:23 +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=1770358164; cv=none; b=QYPdKdSWcD1Yg8Ti0c4wGxaFy7nVRG6q8iI3xT7Pyzc5JAGzd0IhEP0662z5mmijJ+d8BKsFcLJzoRT8ECqSxCUbgJo6IPrHyP1S3ozQn4MoncYzpfh72Lu2dVAPCMm1mMCFD1/DkToMBk5IEECfCReW1vFzPMHTAGMYCRUjETU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770358164; c=relaxed/simple; bh=AxeOdYyxAOVfeRDsxMgguG3fXSHWRueIOlepD2l91lg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kPYEhdicC1L1CQ5AbQXfDuUxVlpEiv1Y5XuXN/WytqYWZiZnZAZJadffD4L2wA33KYwpEV2CmFypNrJKQj5azcXzK22o0sRxXzGk22JgVY1d4zBUE0hNgemAJtQCgexrx8sPZFSncSdfHB6sw5f+xlCJRXmA+PXfM9ZWzn01vxs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nuTtsxg1; 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="nuTtsxg1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 736E1C116C6; Fri, 6 Feb 2026 06:09:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770358163; bh=AxeOdYyxAOVfeRDsxMgguG3fXSHWRueIOlepD2l91lg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nuTtsxg1XFlEILNoi33DL4E1/o1vrLmrXsJxn5Szu2hpyQUfJqWXQss4soivCBCfG LFpEMqPGtVAbru0qK2dtkoCoANIy/EKQLky7MYfbuUe63fQSBfmcfVIsQCOAEngAEu BaVHJJRmCh+rTxS06WUIa4vqP39CAvC68mnjlrcAcdSoJisX1kCLEq/mXVU+OqrY5X R//tAqZ2kl5HrbJ25ySiEltTDT62a7kYu8wGDsMXXJ8vkwQ+yYQ6jVzT3BJdvixX0P YMdeH1hUedNfoSePUD1HFUNhFzmndUfigY55cCJ2pSZid1kodIHq23AfKE609R3d4S RpLbV6mPMwbzQ== Date: Thu, 5 Feb 2026 22:09:22 -0800 From: "Darrick J. Wong" To: Jan Kara Cc: 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: <20260206060922.GG7693@frogsfrogsfrogs> References: 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 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. > 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. > 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. --D > Honza > -- > Jan Kara > SUSE Labs, CR >