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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 16 Sept 2023 at 18:40, NeilBrown <neilb@suse.de> wrote:
>
> I'm not sure the technical argument was particularly coherent.  I think
> there is a broad desire to deprecate and remove the buffer cache.

There really isn't.

There may be _whining_ about the buffer cache, but it's completely
misplaced, and has zero technical background.

The buffer cache is perfectly fine, and as mentioned, it is very
simple. It has absolutely no downsides for what it is.

Sure, it's old.

The whole getblk/bread/bwrite/brelse thing goes all the way back to
original unix, and in fact if you go and read the Lions' book, you'll
see that even in Unix v6, you have comments about some of it being a
relic:

    "B_RELOC is a relic" (p 68)
     http://www.lemis.com/grog/Documentation/Lions/book.pdf

and while obviously the Linux version of it is a different
re-implementation (based on reading _another_ classic book about Unix
-  Maurice Bach's "The Design of the UNIX Operating System"), the
basic notions aren't all that different. The detaisl are different,
the names have been changed later ("sb_bread()" instead of "bread()"),
and it has some extra code to try to do the "pack into a page so that
we can also mmap the result", but in the end it's the exact same
thing.

And because it's old, it's kind of limited. I wouldn't expect a modern
filesystem to use the buffer cache.

IOW, the buffer cache is simple and stupid. But it's literally
designed for simple and stupid old filesystems.

And simple and stupid old filesystems are often designed for it.

Simple and stupid is not *wrong*. In fact, it's often exactly what you want.

Being simple and stupid, it's a physically indexed cache. That's all
kinds of slow and inefficient, since you have to first look up the
physical location of a data file to even find the cached copy of the
data.

It's not fancy.

It's not clever.

But the whole "broad desire to deprecate and remove" is complete and utter BS.

The thing is, the buffer cache is completely pain free, and nobody
sane would ever remove it. That's a FACT. Do these two operations

      wc fs/buffer.c fs/mpage.c
      git grep -l 'struct.buffer_head'

and ponder.

And here's a clue-bat for anybody who can't do the "ponder" part
above: the buffer cache is _small_, it's _simple_, and it has
basically absolutely no effect on anything except for the filesystems
that use it.

And the filesystems that use it are old, and simple, but they are many
(this one is from "grep -w sb_bread", in case people care - I didn't
do any kind of fancier analysis):

      adfs, affs, befs, bfs, efs, exfat, ext2, ext4, f2fs, fat,
      freevxfs, hfs, hpfs, isofs, jfs, minix, nilfs2, ntfs, ntfs3, omfs,
      qnx4, qnx6, reiserfs, romfs, sysv, udf, ufs

And the other part of that "pondering" above, is to look at what the
impact of the buffer cache is *outside* those filesystems that use it.

And here's another clue-bat: it's effectively zero.  There's a couple
of lines in the VM. There's a couple of small helpers functions in
fs/direct-io.c. That's pretty much it.

In other words, the buffer cache is

 - simple

 - self-contained

 - supports 20+ legacy filesystems

so the whole "let's deprecate and remove it" is literally crazy
ranting and whining and completely mis-placed.

And yes, *within* the context of a filesystem or two, the whole "try
to avoid the buffer cache" can be a real thing.

Looking at the list of filesystems above, I would not be surprised if
one or two of them were to have a long-term plan to not use the buffer
cache.

But that in no way changes the actual picture.

Was this enough technical information for people?

And can we now all just admit that anybody who says "remove the buffer
cache" is so uninformed about what they are speaking of that we can
just ignore said whining?

                    Linus