Re: [TUHS] Systematic approach to command-line interfaces

[Larry McVoy <lm@mcvoy.com>]

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@mcvoy.com> wrote:
> Subject: Re: [TUHS] Systematic approach to command-line interfaces
> >
> > On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote:
> > > 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?
> 
> 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.

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.