From: "Darrick J. Wong" <djwong@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Joanne Koong <joannelkoong@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel@vger.kernel.org, John Groves <John@groves.net>,
Bernd Schubert <bernd@bsbernd.com>,
Luis Henriques <luis@igalia.com>,
Horst Birthelmer <horst@birthelmer.de>,
lsf-pc <lsf-pc@lists.linux-foundation.org>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more
Date: Thu, 5 Feb 2026 22:09:22 -0800 [thread overview]
Message-ID: <20260206060922.GG7693@frogsfrogsfrogs> (raw)
In-Reply-To: <yndtg2jbj55fzd2kkhsmel4pp5ll5xfvfiaqh24tdct3jiqosd@jzbfzf3rrxrd>
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 <miklos@szeredi.hu> 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. <shrug>
> 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 <jack@suse.com>
> SUSE Labs, CR
>
next prev parent reply other threads:[~2026-02-06 6:09 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aYIsRc03fGhQ7vbS@groves.net>
2026-02-02 13:51 ` [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more Miklos Szeredi
2026-02-02 16:14 ` Amir Goldstein
2026-02-03 7:55 ` Miklos Szeredi
2026-02-03 9:19 ` [Lsf-pc] " Jan Kara
2026-02-03 10:31 ` Amir Goldstein
2026-02-04 9:22 ` Joanne Koong
2026-02-04 10:37 ` Amir Goldstein
2026-02-04 10:43 ` [Lsf-pc] " Jan Kara
2026-02-06 6:09 ` Darrick J. Wong [this message]
2026-02-21 6:07 ` Demi Marie Obenour
2026-02-21 7:07 ` Darrick J. Wong
2026-02-21 22:16 ` Demi Marie Obenour
2026-02-23 21:58 ` Darrick J. Wong
2026-02-04 20:47 ` Bernd Schubert
2026-02-06 6:26 ` Darrick J. Wong
2026-02-03 10:15 ` Luis Henriques
2026-02-03 10:20 ` Amir Goldstein
2026-02-03 10:38 ` Luis Henriques
2026-02-03 14:20 ` Christian Brauner
2026-02-03 10:36 ` Amir Goldstein
2026-02-03 17:13 ` John Groves
2026-02-04 19:06 ` Darrick J. Wong
2026-02-04 19:38 ` Horst Birthelmer
2026-02-04 20:58 ` Bernd Schubert
2026-02-06 5:47 ` Darrick J. Wong
2026-02-04 22:50 ` Gao Xiang
2026-02-06 5:38 ` Darrick J. Wong
2026-02-06 6:15 ` Gao Xiang
2026-02-21 0:47 ` Darrick J. Wong
2026-03-17 4:17 ` Gao Xiang
2026-03-18 21:51 ` Darrick J. Wong
2026-03-19 8:05 ` Gao Xiang
2026-03-22 3:25 ` Demi Marie Obenour
2026-03-22 3:52 ` Gao Xiang
2026-03-22 4:51 ` Gao Xiang
2026-03-22 5:13 ` Demi Marie Obenour
2026-03-22 5:30 ` Gao Xiang
2026-03-23 9:54 ` [Lsf-pc] " Jan Kara
2026-03-23 10:19 ` Gao Xiang
2026-03-23 11:14 ` Jan Kara
2026-03-23 11:42 ` Gao Xiang
2026-03-23 12:01 ` Gao Xiang
2026-03-23 14:13 ` Jan Kara
2026-03-23 14:36 ` Gao Xiang
2026-03-23 14:47 ` Jan Kara
2026-03-23 14:57 ` Gao Xiang
2026-03-24 8:48 ` Christian Brauner
2026-03-24 9:30 ` Gao Xiang
2026-03-24 9:49 ` Demi Marie Obenour
2026-03-24 9:53 ` Gao Xiang
2026-03-24 10:02 ` Demi Marie Obenour
2026-03-24 10:14 ` Gao Xiang
2026-03-24 10:17 ` Demi Marie Obenour
2026-03-24 10:25 ` Gao Xiang
2026-03-24 11:58 ` Demi Marie Obenour
2026-03-24 12:21 ` Gao Xiang
2026-03-26 14:39 ` Christian Brauner
2026-03-26 15:10 ` Gao Xiang
2026-03-26 16:11 ` Gao Xiang
2026-03-26 16:24 ` Amir Goldstein
2026-03-26 16:37 ` Gao Xiang
2026-03-23 12:08 ` Demi Marie Obenour
2026-03-23 12:13 ` Gao Xiang
2026-03-23 12:19 ` Demi Marie Obenour
2026-03-23 12:30 ` Gao Xiang
2026-03-23 12:33 ` Gao Xiang
2026-03-22 5:14 ` Gao Xiang
2026-03-23 9:43 ` [Lsf-pc] " Jan Kara
2026-03-23 10:05 ` Gao Xiang
2026-03-23 10:14 ` Jan Kara
2026-03-23 10:30 ` Gao Xiang
2026-02-04 23:19 ` Gao Xiang
2026-02-05 3:33 ` John Groves
2026-02-05 9:27 ` Amir Goldstein
2026-02-06 5:52 ` Darrick J. Wong
2026-02-06 20:48 ` John Groves
2026-02-07 0:22 ` Joanne Koong
2026-02-12 4:46 ` Joanne Koong
2026-02-21 0:37 ` Darrick J. Wong
2026-02-26 20:21 ` Joanne Koong
2026-03-03 4:57 ` Darrick J. Wong
2026-03-03 17:28 ` Joanne Koong
2026-02-20 23:59 ` Darrick J. Wong
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=20260206060922.GG7693@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=John@groves.net \
--cc=amir73il@gmail.com \
--cc=bernd@bsbernd.com \
--cc=horst@birthelmer.de \
--cc=jack@suse.cz \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=luis@igalia.com \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.