29 Sep
2021
29 Sep
'21
6:57 p.m.
On Wed, Sep 29, 2021 at 09:40:23AM -0700, Greg A. Woods wrote:
At Tue, 28 Sep 2021 11:10:16 -0700, Larry McVoy
<lm(a)mcvoy.com> wrote:
Subject: Re: [TUHS] Systematic approach to command-line interfaces
I think you didn't use SunOS 4.x. mmap() was implemented correctly
there, the 4.x VM system mostly got rid of the buffer cache (the
buffer cache was used only for reading directories and inodes, there
was no regular file data there). If you read(2) a page and mmap()ed
it and then did a write(2) to the page, the mapped page is the same
physical memory as the write()ed page. Zero coherency issues.
This was not true in other systems, they copied the page from the
buffer cache and had all sorts of coherency problems. It took
about a decade for other Unix implementations to catch up and I
think that's what you are hung up on.
SunOS 4.x got it right. You can read about it, I have all the papers
cached at http://mcvoy.com/lm/papers
ZFS screwed it all up again, ZFS has it's own cache because they weren't
smart enough to know how to make compressed file systems use the page
cache (we did it in BitKeeper so I have an existance proof that it is
possible). I was deeply disapointed to hear that ZFS screwed up that
badly, the Sun I was part of would have NEVER even entertained such an
idea, they worked so hard to get a unified page cache. It's just sad.
On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote:
Mmap() as we have it today almost completely ignores the bigger picture
and the lessons that came before it.
It was an add-on hack that basically said only "Oh, Yeah, we can do that
too! Look at this." -- and nobody bothered to look for decades.
For one it has no easy direct language support (though it is possible in
C to pretend to use it directly, though the syntax often gets cumbersome).
Single-level-storage was obviously designed into Multics from the
beginning and from the ground up, and it was easily used in the main
languages supported on Multics -- but it was just an add-on hack in Unix
(that, if memory serves me correctly, was initially only poorly used in
another extremely badly designed add-on hack that didn't pay any
attention whatsoever to past lessons, i.e. dynamic linking. which to
this day is a horror show of inefficiencies and bad hacks).
I think perhaps the problem was that mmap() came too soon in a narrow
sub-set of the Unix implementations that were around at the time, when
many couldn't support it well (especially on 32-bit systems -- it really
only becomes universally useful with either segments or 64-bit and
larger address spaces). The fracturing of "unix" standards at the time
didn't help either. The "unix" nod to
single level storage by way of mmap() suffers from horribly bad design
and neglect.
So what is it about mmap you don't like?