Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Dave Chinner <david@fromorbit.com>]

On Mon, Sep 18, 2023 at 10:26:24AM -0700, Linus Torvalds wrote:
> On Mon, 18 Sept 2023 at 04:14, Jan Kara <jack@suse.cz> wrote:
> >
> > I agree. On the other hand each filesystem we carry imposes some
> > maintenance burden (due to tree wide changes that are happening) and the
> > question I have for some of them is: Do these filesystems actually bring
> > any value?
> 
> I wouldn't be shocked if we could probably remove half of the
> filesystems I listed, and nobody would even notice.

That's the best argument for removing all these old filesystems from
the kernel that anyone has made so far.

As it is, I'm really failing to see how it can be argued
successfully that we can remove ia64 support because it has no users
and is a maintenance burden on kernel developers, but that same
argument doesn't appear to hold any weight when applied to a
filesystem.

What makes filesystems so special we can't end-of-life them like
other kernel code?

[....]

> And that's kind of the other side of the picture: usage matters.
> Something like affs or minixfs might still have a couple of users, but
> those uses would basically be people who likely use Linux to interact
> with some legacy machine they maintain..  So the usage they see would
> mainly be very simple operations.

Having a "couple of occasional users" really does not justify the
ongoing overhead of maintaining those filesystems in working order
as everything else around them in the kernel changes. Removing the
code from the kernel does not deny users access to their data; they
just have to use a different method to access it (e.g. an old
kernel/distro in a vm).

> And that matters for two reasons:
> 
>  (a) we probably don't have to worry about bugs - security or
> otherwise - as much. These are not generally "general-purpose"
> filesystems. They are used for data transfer etc.

By the same argument they could use an old kernel in a VM and not
worry about the security implications of all the unfixed bugs that
might be in that old kernel/distro.

>  (b) if they ever turn painful, we might be able to limit the pain further.

The context that started this whole discussion is that maintenance
of old filesystems is becoming painful after years of largely
being able to ignore them.

.....

> Anyway, based on the *current* situation, I don't actually see the
> buffer cache even _remotely_ painful enough that we'd do even that
> thing. It's not a small undertaking to get rid of the whole
> b_this_page stuff and the complexity that comes from the page being
> reachable through the VM layer (ie writepages etc). So it would be a
> *lot* more work to rip that code out than it is to just support it.

As I keep saying, the issues are not purely constrained to the
buffer cache. It's all the VFS interfaces and structures. It's all
the ops methods that need to be changed. It's all the block layer
interfaces filesystem use. It's all the page and folio interfaces,
and how the filesystems (ab)use them. And so on - it all adds up.

If we're not going to be allowed to remove old filesystems, then how
do we go about avoiding the effort required to keep those old
filesystems up to date with the infrastructure modifications we need
to make for the benefit of millions of users that use modern
filesystems and modern hardware?

Do we just fork all the code and how two versions of things like
bufferheads until all the maintained filesystems have been migrated
away from them? Or something else? 

These are the same type of questions Christoph posed in his OP, yet
this discussion is still not at the point where people have
recognised that these are the problems we need to discuss and
solve....

Dave.
-- 
Dave Chinner
david@fromorbit.com