The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Clem Cole <clemc@ccc.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>, Paul Ruizendaal <pnr@planet.nl>
Subject: Re: [TUHS] VFS prior to 1984
Date: Wed, 24 Jun 2020 12:36:47 -0700	[thread overview]
Message-ID: <20200624193647.GB14302@mcvoy.com> (raw)
In-Reply-To: <CAC20D2OkGKj58=XPcPW+NoAXE3i+_mRSeBD-oJUY36FSdBBd5A@mail.gmail.com>

On Tue, Jun 23, 2020 at 11:12:40AM -0400, Clem Cole wrote:
> Rusty and team did the VFS layer Sun @ (Larry will have to tell
> you who actually built it, I never knew).  

Steve Kleiman is the only author on the VFS paper so I'm guessing that 
was him.

Rusty was NFS.

Joe Moran (sun!mojo if I remember correctly) did the VM implementation,
it was co-designed by Joe, Shannon, and Gingell.

Side story: part of the reason I wanted to go to Sun was because when
I was a CS student at UW-Madison, Joe was a little older than me, and
I sat and watched him do a BSD port to a 68K (I think) in a little more
than 24 hours (sketchy on the time, I think that's right, almost positive
it was more than 20 hours, it was a chunk of time).  As a guy who wanted
to be next to the metal, it was impressive.

> In the end, early NFS was
> notorious for putting 'holes' in the files because of the automatic seek in
> every operation and errors not coming until close(2) time.

You have no idea how many of those holes that 16 bit SCCS checksum has
found (BitKeeper kept it).

> EFS used an RPC and a RUDP layer that Perry and Alan Atlas built, but it
> was not nearly as flexible as what Sun built [which had a crude interface
> generator], although until years later when Mike Leibensger built PIG (the
> Paceline Interface Generator) NFS RPC was always a PITA and not much better
> in practice than what we had at Masscomp.

Oh, I don't know if I agree.  I took the RPC mechanism and vectorized it.
I probably have the code somewhere.  It was pretty neat, 10Mbit was the
common networking and I did RPC Vector calls to the rstatd on literally
every machine in the Mountain View campus.  It was thousands of machines
and it worked.  The code split the RPC back into send and receive and
the code had to start gathering up answers before it was finished 
sending the questions or the packets would be dropped.

It worked surprisingly well.  Ron Minnich and Gene Kim made an NFS client
that worked as demo-ware.  There is a paper about below, note that I'm
co-author only because I wrote the RPC vector code, I believe Gene did
the in kernel code, it was Ron and Gene's project.  

http://mcvoy.com/lm/papers/bigfoot.pdf

> In fact, the point of the EFS paper was it's all about the recovery when
> there is a failure/error.  If you read his paper, Rusty's point was who
> cares if there is an error (I've always felt vindicated that while I lost
> the war, over time everyone came to our way of thinking and now NFS
> V4 looks a whole lot like EFS did).

Yeah, they were sort of cavalier about errors in public.  The weird
thing is Sun ran their entire network on Sun machines.  Everything was
NFSv2 when I got there, the routers were Sun workstations, the servers
were Sun servers, the clients were Sun workstations.  They ate their own
dogfood and NFS just worked, it was pretty unheard of to hear about NFS
issues other than performance tuning (stupid biods etc).

> Having a DFS as a feature was an incredible advance and proved we needed
> something (and it needed to be standard in all systems).   NFS really lead
> the market with that advance, although it sort of took a few years to make
> it really good.  The fact is that others had the same idea before or at
> least contemporary with it.

NFS was solid in v2 at Sun.  I went to SGI and NFS was complete garbage.
SGI's networking principle engineer told me, when I complained about
NFS not being reliable, "That's what rcp is for".  I was flabbergasted,
the networking group generated $18M/year in NFS sales.

It wasn't just SGI, every vender other Sun had a crappy NFS implementation.
I'm surprised NFS didn't have a worse rep because while NFS worked on Suns,
it really didn't work anywhere near as well elsewhere.

> That said, and to give the NFS team* a huge amount of credit *(and great
> applause), the VFS layer was better thought out than the FSS and in fact
> made it possible to add a lot of different file systems into UNIX later.
> FSS was much more ad hoc.

The VFS layer was Steve, NFS was Rusty.

> At LCC, when we built VPROC for TNC a few years later, we used some of the
> same ideas from VFS and of course used VFS for the file system layer since
> TNC had to have full POSIX semantics.  (It's a shame VPROC never caught on
> the way VFS did).

VPROC was very cool and a requirement for any sort of distributed single
system image OS.  I agree it is a shame that it didn't catch on.

--lm

  parent reply	other threads:[~2020-06-24 19:37 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  9:09 Paul Ruizendaal
2020-06-23 14:01 ` Larry McVoy
2020-06-23 15:12   ` Clem Cole
2020-06-23 15:55     ` Rich Morin
2020-06-23 20:38     ` Rob Pike
2020-06-23 20:57       ` Larry McVoy
2020-06-24  5:14       ` arnold
2020-06-24 21:08         ` Dave Horsfall
2020-06-24 19:30       ` Clem Cole
2020-06-24 19:36     ` Larry McVoy [this message]
2020-06-25  6:52       ` Rob Gingell
2020-07-05  0:05       ` Dave Horsfall
2020-07-05  0:16         ` Larry McVoy
2020-07-06  4:42           ` Dave Horsfall
2020-07-06 16:51           ` Chris Torek
2020-07-06 23:23             ` [TUHS] ECC memory John Gilmore
2020-07-07  1:07             ` [TUHS] VFS prior to 1984 Bakul Shah
2020-07-05  1:43         ` Clem Cole
2020-07-05 14:43           ` Larry McVoy
2020-07-05 18:40             ` Arthur Krewat
2020-07-05 20:08             ` Clem Cole
2020-07-05 20:42               ` John Cowan
2020-07-05 21:04                 ` Clem Cole
2020-07-05 21:14                   ` Dan Cross
2020-06-24 16:51 ` Anthony Martin
2020-06-24 17:31   ` Anthony Martin
2020-06-24 18:31   ` Paul Ruizendaal
2020-06-25  0:56     ` Rob Gingell via TUHS
2020-06-25  4:15       ` [TUHS] Oh, things were very different Rich Morin
2020-06-25 15:45         ` Lawrence Stewart
2020-06-25 16:24           ` Warner Losh
2020-06-25 17:57           ` Arthur Krewat
2020-06-25 20:22         ` Dave Horsfall
2020-06-25 20:42           ` Michael Kjörling
2020-06-25 20:49           ` Clem Cole
2020-06-26  0:48             ` Dave Horsfall
2020-06-24 19:05   ` [TUHS] VFS prior to 1984 Paul Ruizendaal
2020-06-24 20:27 ` Derek Fawcus
2020-06-24 21:33 ` Greg A. Woods
2020-06-25  0:45   ` Adam Thornton
2020-06-25 19:40     ` Greg A. Woods
2020-06-23 22:17 Norman Wilson
2020-06-23 22:24 ` Dave Horsfall
2020-06-24  4:09   ` Warner Losh
2020-06-24  5:10     ` Dave Horsfall
2020-06-24  5:33       ` Bakul Shah
2020-06-24  9:10         ` Andrew Warkentin
2020-06-24 14:31 Noel Chiappa
2020-06-24 15:21 ` Clem Cole
2020-06-24 17:51 Noel Chiappa
2020-06-24 18:13 ` Richard Salz
2020-06-24 18:46   ` Lars Brinkhoff
2020-06-24 18:31 Norman Wilson
2020-06-25  6:22 ` arnold
2020-06-25 19:31 Noel Chiappa
2020-06-25 20:23 Noel Chiappa
2020-06-25 20:25 Noel Chiappa
2020-06-26  5:49 ` Lars Brinkhoff
2020-06-26  8:34   ` Dave Horsfall
2020-06-26 11:13     ` arnold
2020-06-29  9:11 Paul Ruizendaal
2020-06-29 14:45 ` Larry McVoy
2020-06-29 14:53   ` Paul Ruizendaal
2020-06-29 15:14     ` Larry McVoy
2020-06-29 16:34 ` Heinz Lycklama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200624193647.GB14302@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=clemc@ccc.com \
    --cc=pnr@planet.nl \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).