From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20622 invoked from network); 23 Jun 2020 20:40:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 23 Jun 2020 20:40:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E5388945A1; Wed, 24 Jun 2020 06:40:05 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8A6069459A; Wed, 24 Jun 2020 06:39:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DpxgKCLd"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D7ED09459A; Wed, 24 Jun 2020 06:39:06 +1000 (AEST) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 1E58E94599 for ; Wed, 24 Jun 2020 06:39:06 +1000 (AEST) Received: by mail-ua1-f51.google.com with SMTP id x14so7247465uao.7 for ; Tue, 23 Jun 2020 13:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4SVfntSjdG5+f+Zf4Z+BFqInqVsTrcVgMvnw3/oHs68=; b=DpxgKCLdIXAC4MzbtdZnRVeL5m2Y/tx5zsvAd0VW1n6FC6+6iK2y7jEU4TUZvLKXzS 2KLveZGQzGvt2FBvF0o303g8JLfgdvun2OdlxhJlIDa5Tkb9fIV9qr7NVY63A3/canwT D28mXOBF7h8ywWclkvdtQ7mprlLRdwghNWY8SyNQSUBWLIt8gGZDo+qj2D68HPme0PD7 Yz74TjM0LiQhtbntBRFeFcYGvXNEJHuCDUxtwI9N3bEaDlbQ94eNvabutD4uuNAH7L7Z b7XgOwxcj2UWToO9W6YxjbOgTdUSsha82y/bhBZvNI6WeO9MYkzh2f9a2FCYrKBd4FqP iAFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SVfntSjdG5+f+Zf4Z+BFqInqVsTrcVgMvnw3/oHs68=; b=OB0wmja+VVCjhVNaKaHVsyVgabEklrXL1NksLvEy094oAhZKXB0KcRrvc9YdAPf69D dYjKDOh02Bmt/i8a0/1O1v6eRsiPUFwH6BvaAAJ5/x64F+tTFJQLk1eyFOU69OTRMO9n +1lYjgGSvfRHW7lg16Y2yfF/DLWN3G76mnAYWPxMbQGfyeCsCOzfVzoQCM2MeOzSc77B d4kYSODq8Pb/qa+8kc2sJT+x3YWyQVNB9zr4KDfU9WCxLL1AI+CBP5ABh+hNgapAqdLW 9tBqRYoZMSuJ8dt1VnMd63hCOBIrCKhzR1VCCNl8cxUGMM7+F14gm1Gq6Z7xIEbGxCzl 2PLg== X-Gm-Message-State: AOAM531mWBPN6YVjrXLA/M8uMDLXQ/V2Cc/g2lttHgDTraEKeJt3Hf3s i6Xl6uJCWSQVv/FqER112eZ5nTsGZcWlCcdNkiqy+6gu X-Google-Smtp-Source: ABdhPJycPuurncCzOE1CWYgeeDEg0Jfl4ZU0OCcsOQdt0U0e3Ds93/bCH8L3WNfkNgaFbDkMBOlFzvhuTw7AiHYIzd4= X-Received: by 2002:ab0:3145:: with SMTP id e5mr16159537uam.73.1592944745195; Tue, 23 Jun 2020 13:39:05 -0700 (PDT) MIME-Version: 1.0 References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> In-Reply-To: From: Rob Pike Date: Wed, 24 Jun 2020 06:38:53 +1000 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="000000000000af2d9205a8c659d6" Subject: Re: [TUHS] VFS prior to 1984 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Paul Ruizendaal Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000af2d9205a8c659d6 Content-Type: text/plain; charset="UTF-8" For my taste, the various Unix file system switches that I've seen are too firmly tied to the idea of blocks and disks and all that, making them less flexible than they should have been. That's why the Plan 9 version is about names and byte streams, to make it as general as possible. That's one of the reasons the possibilities of the file system approach to data has not reached its potential in Unix. -rob On Wed, Jun 24, 2020 at 1:14 AM Clem Cole wrote: > I agree with Larry with his observations. The only thing I would add is > that Popek and Walker had a file system in the UCLA Locus distributed > system for the 11/70 that was published in SIGOPS in late 1970s. In fact, > Gerry came up with the idea after a sabbatical @ PARC. But it was not > formalized like NFS as a separate (layered) FS, it was just part of the > basic Locus FS. > > Peter Weinberger created the file system switch (FSS) for V8 and in the > UNIX world, it was first. Dave Arnovitz used it for RFS in System V, > while Perry Flynn and I used it for EFS, both of us after talking > to Peter. Rusty and team did the VFS layer Sun @ (Larry will have to tell > you who actually built it, I never knew). Rusty and I both published > papers in the '85 Summer USENIX (NFS and EFS were contemporaries -- the > difference is that Sun gave away NFS and Masscomp was not smart enough to > do that). > > I talked to Steve Kleinman extensively about VFS at one point, and I'm > pretty sure he and the rest of the Sun guys had talked to the PARC folks > who after Gerry went back to UCLA started working on a DFS. The idea of > the state-less (idempotent) file system RPC that NFS used based on stuff > PARC did. But I'm not sure PARC had anything like the FSS or the VFS > layer. Peter, Dave, and I used a stateful scheme because we chose to have > full UNIX FS semantics, which NFS did not. 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. > > 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. > > 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). > > 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. > > 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. > > 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). > > Clem > > > On Tue, Jun 23, 2020 at 10:02 AM Larry McVoy wrote: > >> I like to claim credit for creating the ChangeSet concept, the grouping >> of a set of deltas across a number of files. But I wasn't the first. >> Back when dejanews was a thing and you could search usenet posts in a >> date range, if you searched before I started talking about ChangeSets, >> you could find 6, count 'em, 6 hits. There was a really obscure system >> called Aide De Camp, that had a similar concept. >> >> But if you searched after I started talking about them you would see >> millions of hits. >> >> So I didn't invent the concept but I sure as heck made the world >> understand the concept. >> >> I suspect Sun could be in a similar position. The VFS concept is >> pretty sweet so there might have been someone before Sun. I'll >> long odds that if there was, it didn't gain traction until Sun >> did it. >> >> If there is nothing that predates it, then the inspiration was >> almost certainly the device driver interface. One interface, >> many devices. VFS is the same. >> >> On Tue, Jun 23, 2020 at 11:09:57AM +0200, Paul Ruizendaal wrote: >> > When googling for File System Switch or Virtual File System most >> sources mention Sun NFS and SysVr3 as the earliest implementations. Some >> sources mention 8th Edition. >> > >> > I did a (short) search on FSS/VFS in earlier, non-Unix OS???s (Tenex, >> Multics, CTSS, etc.), but none of those seem to have had a comparable >> concept. >> > >> > Does anybody recall prior art (prior to 1984) in this area? >> > >> > Paul >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > --000000000000af2d9205a8c659d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For my taste, the various Unix file system switches that I= 've seen are too firmly tied to the idea of blocks and disks and all th= at, making them less flexible than they should have been. That's why th= e Plan 9 version is about names and byte streams, to make it as general as = possible.

That's one of the reasons the possibilitie= s of the file system approach to data has not reached its potential in Unix= .

-rob


On Wed, Jun 24, 2020 at= 1:14 AM Clem Cole <clemc@ccc.com&g= t; wrote:
I agree with Larry with his observations.=C2=A0 =C2=A0The onl= y thing I would add is that Popek and Walker had a file system in the UCLA = Locus distributed system for the 11/70 that was published in SIGOPS in late= 1970s.=C2=A0 In fact, Gerry came up with the idea=C2=A0after a sabbatical= =C2=A0@ PARC.=C2=A0 =C2=A0But it was not formalized like NFS as a separate = (layered) FS, it was just part of the basic Locus FS.

= Peter Weinberger created the file system switch (FSS) for V8 and in the UNI= X world, it was first.=C2=A0 =C2=A0 Dave Arnovitz used it for RFS in System= V, while Perry Flynn and I used it for EFS,=C2=A0both of us after talking = to=C2=A0Peter.=C2=A0 =C2=A0Rusty and team did the VFS layer Sun @ (Larry wi= ll have to tell you who actually=C2=A0built it, I never knew).=C2=A0 Rusty = and I both published papers in the '85 Summer USENIX (NFS and EFS were = contemporaries -- the difference is that Sun gave away NFS and Masscomp was= not smart enough to do that).

I talked to Steve Klein= man extensively about VFS at one point, and I'm pretty sure he and the = rest of the Sun guys had talked to the PARC folks who after Gerry went back= to UCLA started working on a DFS.=C2=A0 =C2=A0The idea of the state-less= =C2=A0(idempotent) file system RPC that NFS used based on stuff PARC did.= =C2=A0 =C2=A0But I'm not sure PARC had anything like the FSS or the VFS= layer.=C2=A0 Peter, Dave, and I used a stateful scheme because we chose to= have full UNIX FS semantics,=C2=A0which NFS did not.=C2=A0 In the end, ear= ly NFS was notorious for putting 'holes' in the files because of th= e automatic seek in every operation and errors not coming until close(2) ti= me.

EFS used an RPC and a RUDP layer that Perry and Al= an 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 Leib= ensger built PIG (the Paceline Interface Generator) NFS RPC was always a PI= TA and not much better in practice than what we had at Masscomp.
In fact, the point of the EFS paper was it's all about the r= ecovery when there is a failure/error.=C2=A0 If you read his paper, Rusty&#= 39;s point was who cares if there is an error (I've always felt vindica= ted that while I lost the war, over time everyone came to our way of thinki= ng and now NFS V4=C2=A0looks a whole lot like EFS did).

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Having a DFS as a feature was an incredible=C2=A0advance and proved we ne= eded something (and it needed to be standard in all systems).=C2=A0 =C2=A0N= FS really lead the=C2=A0market with that advance, although it sort of took = a few years to make it really good.=C2=A0 The fact is that others had the s= ame idea before or at least contemporary with it.

That= said, and to give the NFS team a huge amoun= t of credit (and great applause),=C2=A0the VFS layer was better thought= out than the FSS and in fact made it possible to add a lot of different fi= le systems into UNIX later.=C2=A0 FSS was much more ad hoc.=C2=A0=C2=A0

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=C2=A0VFS for the f= ile system layer since TNC had to have full POSIX semantics.=C2=A0 (It'= s a shame VPROC never caught on the way VFS did).

Clem=


On Tue, Jun 23, 2020 at 10:02 AM Larry McVoy <lm@mcvoy.com> wrote:
<= /div>
I like to claim cred= it for creating the ChangeSet concept, the grouping
of a set of deltas across a number of files.=C2=A0 But I wasn't the fir= st.
Back when dejanews was a thing and you could search usenet posts in a
date range, if you searched before I started talking about ChangeSets,
you could find 6, count 'em, 6 hits.=C2=A0 There was a really obscure s= ystem
called Aide De Camp, that had a similar concept.

But if you searched after I started talking about them you would see
millions of hits.

So I didn't invent the concept but I sure as heck made the world
understand the concept.

I suspect Sun could be in a similar position.=C2=A0 The VFS concept is
pretty sweet so there might have been someone before Sun.=C2=A0 I'll long odds that if there was, it didn't gain traction until Sun
did it.

If there is nothing that predates it, then the inspiration was
almost certainly the device driver interface.=C2=A0 One interface,
many devices.=C2=A0 VFS is the same.

On Tue, Jun 23, 2020 at 11:09:57AM +0200, Paul Ruizendaal wrote:
> When googling for File System Switch or Virtual File System most sourc= es mention Sun NFS and SysVr3 as the earliest implementations. Some sources= mention 8th Edition.
>
> I did a (short) search=C2=A0 on FSS/VFS in earlier, non-Unix OS???s (T= enex, Multics, CTSS, etc.), but none of those seem to have had a comparable= concept.
>
> Does anybody recall prior art (prior to 1984) in this area?
>
> Paul

--
---
Larry McVoy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l= m at mcvo= y.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.mcvoy.com= /lm
--000000000000af2d9205a8c659d6--