On Mon, 18 Sept 2023 at 13:51, Theodore Ts'o <tytso@xxxxxxx> wrote:
>
> Fortunately, I most of the "simple" file systems appear to support
> mmap, via generic_file_mmap:
Yes, but that is in fact exactly the path that causes the most
complexity for the buffer cache: it needs that "readpage" function
that in turn then uses mpage_readpage() and friends to create the
buffers all in the same page.
And then - in order for normal read/write to not have any buffer
aliases, and be coherent - they too need to deal with that "group of
buffers in the same page" situation too.
It's not a *big* amount of complexity, but it's absolutely the most
complicated part of the buffer cache by far, in how it makes buffer
heads not independent of each other, and how it makes some of the
buffer cache depend on the page lock etc.
So the mmap side is what ties buffers heads together with the pages
(now folios), and it's not pretty. we have a number of loops like
struct buffer_head *bh = head;
do {
.. work on bh ..
bh = bh->b_this_page;
} while (bh != head);
together with rules for marking buffers and pages dirty / uptodate /
whatever hand-in-hand.
Anyway, all of this is very old, and all of it is quite stable. We had
mmap support thanks to these games even before the page cache existed.
So it's not _pretty_, but it works, and if we can't just say "we don't
need to support mmap", we're almost certainly stuck with it (at least
if we want mappings that stay coherent with IO).
Linus
