On Mon, Sep 18, 2023 at 10:26:24AM -0700, Linus Torvalds wrote: > On Mon, 18 Sept 2023 at 04:14, Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxxxxx
