The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: RFS (was Re: Re: forgotten versions)
@ 2022-06-20 12:28 Paul Ruizendaal via TUHS
  2022-06-20 21:53 ` Derek Fawcus
  0 siblings, 1 reply; 9+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-06-20 12:28 UTC (permalink / raw)
  To: tuhs


> I don't know the exact history of RFS a la System V, but I
> don't think it was Peter Weinberger's stuff, and it certainly
> wasn't his code.

Peter’s code is available in the V8 and V9 trees on TUHS.

The Sys V repositories on Github appear to include RFS code in all of R3.0, R3.1 and R3.2.

At first glance, it seems quite different from the V8/V9 code.

> Peter, being a self-described fan of cheap hacks, also wasn't
> inclined to spend much time thinking about general abstractions;
> in effect he just turned various existing kernel subroutines
> (when applied to a network file system) into RPCs.  The
> structure of the file system switch was rather UNIX-specific,
> reflecting that.

Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring).

With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent.

Paul

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-20 12:28 [TUHS] Re: RFS (was Re: Re: forgotten versions) Paul Ruizendaal via TUHS
@ 2022-06-20 21:53 ` Derek Fawcus
  0 siblings, 0 replies; 9+ messages in thread
From: Derek Fawcus @ 2022-06-20 21:53 UTC (permalink / raw)
  To: tuhs

On Mon, Jun 20, 2022 at 02:28:06PM +0200, Paul Ruizendaal via TUHS wrote:
> 
> > Peter, being a self-described fan of cheap hacks, also wasn't
> > inclined to spend much time thinking about general abstractions;
> > in effect he just turned various existing kernel subroutines
> > (when applied to a network file system) into RPCs.  The
> > structure of the file system switch was rather UNIX-specific,
> > reflecting that.
> 
> Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring).
> 
> With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent.

Interesting, given the earlier mention of SMB.  As I recall, the MS-DOS Redirector interface is sort of at a similar level, but probably a lot more messy in terms of how the internal 'interfaces' are exposed.

That was in DOS 3.0, which according to Wikipedia was released in April '85, with 8th edition being around Feb '85, I guess they may have been done in parallel?

DF

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-20  5:03         ` Arno Griffioen via TUHS
@ 2022-06-20  6:53           ` Theodore Ts'o
  0 siblings, 0 replies; 9+ messages in thread
From: Theodore Ts'o @ 2022-06-20  6:53 UTC (permalink / raw)
  To: Arno Griffioen; +Cc: tuhs

I'll note there was another RFS that was posted to net.sources and
net.unix-wizards by Todd Brunhoff in January 1986.  This was
completely different from the AT&T System V's; Todd's RFS was done as
part of his Master's Degree at the University of Denver, and it was
heavily dependant on BSD 4.2/4.3's sockets interface.

For more information, see:

   https://groups.google.com/g/net.unix-wizards/c/QwRVsZS9jEM/m/V4ZI64CKopsJ?pli=1

We used this version of RFS at MIT Project Athena for a while before
switching to AFS, and it's mentioned in Professor Saltzer's Athena
Technical Plan, in the section entitled, "The Athena File Storage
Model":

    https://web.mit.edu/saltzer/www/publications/athenaplan/c.6.pdf

Project Athena integrated MIT Kerberos (Version 4) into both NFS and
RFS, and of course AFS used Kerberos for its authentication tokens.

     	    	       	    	     	     - Ted

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 23:19       ` Brad Spencer
@ 2022-06-20  5:03         ` Arno Griffioen via TUHS
  2022-06-20  6:53           ` Theodore Ts'o
  0 siblings, 1 reply; 9+ messages in thread
From: Arno Griffioen via TUHS @ 2022-06-20  5:03 UTC (permalink / raw)
  To: tuhs

On Sun, Jun 19, 2022 at 07:19:31PM -0400, Brad Spencer wrote:
> order of the machines was different.  I seem to recall that with RFS if
> /dev was remoted you actually accessed the remote devices and not just
> the device nodes from the system that /dev was mounted to.  At the AT&T
> site I was at we used NFS exclusively too.

Yup..

I used RFS on variuous SVR3 and SVR4 platforms back in the days, usually
for this purpose. Eg. to provide a simple way of giving 'workstation'
users access to modem-banks attached to central servers.

It worked fine as long as the platforms were pretty similar (eg. all
i386 based), but could indeed get 'interesting' once you added bits
in the mix that were based on other CPUs.

For me RFS came along 'before its time' as by design it could not handle 
things like creating diskless or dataless workstations easily, exactly 
because of the more fine-grained, file oriented, setup and that's where 
NFS did it's thing. 

The features RFS brought did, unfortunately, not seem as useful at the time 
for general applications as things like broadly sharing boot and/or home/staff
environments was 'the thing' needed for a long time and NFS did that
very (too ;) ) easily.

However.. I do see it more like the UNIX 'grandad' for things we now
have like SMB and cloud sync/share 'filesystem' tools which operate
much more on a style of access and granularity like RFS did.

I always wondered if the Mircrosoft engineers that worked on the initial
SMB implementations looked at RFS for ideas.

							Bye, Arno.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-20  0:44 Norman Wilson
  2022-06-20  1:02 ` George Michaelson
@ 2022-06-20  4:50 ` arnold
  1 sibling, 0 replies; 9+ messages in thread
From: arnold @ 2022-06-20  4:50 UTC (permalink / raw)
  To: tuhs, norman

RFS was not Peter's code. It was stateful, which had advantages
and disadvantages.  And, as someone else mentioned, if two systems
were binary compatible, remote device access worked, including ioctls.

IIRC Steve Rago ported Peter's code to System V Release 4,
and publilshed a paper about it, but I don't think the code ever
escaped AT&T.

System V Release 4 sorta overdid the special file system thing;
as I recall /dev/fd was done as a file system!

FWIW,

Arnold

norman@oclsc.org (Norman Wilson) wrote:

> I don't know the exact history of RFS a la System V, but I
> don't think it was Peter Weinberger's stuff, and it certainly
> wasn't his code.  Nor his name: he called his first version
> neta and his second netb (he knew it would be changing and
> allowed for it in the name from the start).
>
> I don't remember us ever calling it RFS, or even remote
> file systems, inside 1127; we called it network file systems
> (never NFS because the Sun stuff existed by then).
>
> For those who don't know it, Peter's goal was quite different
> from that of NFS.  The idea behind NFS seems always to have
> been to mount a remote file system as if it were local, with
> a base assumption early on that everything was within the
> same administrative domain so it was OK to make assumptions
> about userids matching up, and running code as super-user.
> Peter described his intent as `I want to be able to use your
> disks, and that's a lot simpler if I don't have to get you
> to add code to your kernel, or even to run a program as
> super-user.'  Hence the entirely-user-mode server program,
> which could use super-user privileges to afford access as
> any user if it had them, but also worked fine when run as
> an ordinary user with only that user's file permissions.
> We did in fact normally run it as super-user so each of
> our 15 or so VAXes could see the file system tree on each
> other, but we also occasionally did it otherwise.
>
> That was one reason device files worked as they did, accessing
> the device on the server end rather than acting like a local
> special file on the client: we didn't care about running
> diskless clients, but we did occasionally care about accessing
> a remote system's tape drive.
>
> Peter, being a self-described fan of cheap hacks, also wasn't
> inclined to spend much time thinking about general abstractions;
> in effect he just turned various existing kernel subroutines
> (when applied to a network file system) into RPCs.  The
> structure of the file system switch was rather UNIX-specific,
> reflecting that.
>
> That also means Peter's code was a bit ad-hoc and wonky in
> places.  He cleaned it up considerably between neta and netb,
> and I did further cleanup later.  I even had a go at a library
> to isolate the network protocol from the server proper, converted
> the netb server to use it, and made a few demo servers of my own
> like one to read and write raw FILES-11 file systems--useful for
> working with the console file system on the VAX 8800 series,
> which was exported to the host as a block device--and a daemon
> to allow a tar archive to be mounted as a read-only file system.
>
> In modern systems, you can do the same sort of things with FUSE,
> and set up the same I-want-to-use-your-disks (or I want to get
> at my own files from afar without privileges) scheme with sshfs.
> I would be very surprised to learn that either of those borrowed
> from their ancient cousins in Research UNIX; so far as I know
> they're independent inventions.  Either way I'm glad they exist.
>
> Norman Wilson
> Toronto ON

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-20  0:44 Norman Wilson
@ 2022-06-20  1:02 ` George Michaelson
  2022-06-20  4:50 ` arnold
  1 sibling, 0 replies; 9+ messages in thread
From: George Michaelson @ 2022-06-20  1:02 UTC (permalink / raw)
  To: tuhs

I probably tend too much to the sociological more than technical in
this, but I do know we were very prejudiced against RFS. Very. We just
didn't like it.

Probably? This was some kind of bizarre chauvinism about NFS and Suns,
and access to the systems. But, my memory is that RFS as available to
us was not very easy to deploy, and may have been by default a "hard"
mount just at the point we were finding the benefit of having a "soft"
mount, in experience. Sure, a soft mount is significantly less
reliable, but with unreliable campus networks and systems, half a
usable system is better than none at all, and RFS tended to 'all or
nothing'

This was during the window where Sun was breaking the UDP checksum,
and also Ethernet backoff. So, its UDP checksum gaming meant it was
"faster" because it did less work, and its Ethernet backoff gaming
meant it was always first-to-fire in a contention event on the cable.
Two cheats! I don't think RFS did either, so there was also specious
benchmarking coming into effect,

-G

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
@ 2022-06-20  0:44 Norman Wilson
  2022-06-20  1:02 ` George Michaelson
  2022-06-20  4:50 ` arnold
  0 siblings, 2 replies; 9+ messages in thread
From: Norman Wilson @ 2022-06-20  0:44 UTC (permalink / raw)
  To: tuhs

I don't know the exact history of RFS a la System V, but I
don't think it was Peter Weinberger's stuff, and it certainly
wasn't his code.  Nor his name: he called his first version
neta and his second netb (he knew it would be changing and
allowed for it in the name from the start).

I don't remember us ever calling it RFS, or even remote
file systems, inside 1127; we called it network file systems
(never NFS because the Sun stuff existed by then).

For those who don't know it, Peter's goal was quite different
from that of NFS.  The idea behind NFS seems always to have
been to mount a remote file system as if it were local, with
a base assumption early on that everything was within the
same administrative domain so it was OK to make assumptions
about userids matching up, and running code as super-user.
Peter described his intent as `I want to be able to use your
disks, and that's a lot simpler if I don't have to get you
to add code to your kernel, or even to run a program as
super-user.'  Hence the entirely-user-mode server program,
which could use super-user privileges to afford access as
any user if it had them, but also worked fine when run as
an ordinary user with only that user's file permissions.
We did in fact normally run it as super-user so each of
our 15 or so VAXes could see the file system tree on each
other, but we also occasionally did it otherwise.

That was one reason device files worked as they did, accessing
the device on the server end rather than acting like a local
special file on the client: we didn't care about running
diskless clients, but we did occasionally care about accessing
a remote system's tape drive.

Peter, being a self-described fan of cheap hacks, also wasn't
inclined to spend much time thinking about general abstractions;
in effect he just turned various existing kernel subroutines
(when applied to a network file system) into RPCs.  The
structure of the file system switch was rather UNIX-specific,
reflecting that.

That also means Peter's code was a bit ad-hoc and wonky in
places.  He cleaned it up considerably between neta and netb,
and I did further cleanup later.  I even had a go at a library
to isolate the network protocol from the server proper, converted
the netb server to use it, and made a few demo servers of my own
like one to read and write raw FILES-11 file systems--useful for
working with the console file system on the VAX 8800 series,
which was exported to the host as a block device--and a daemon
to allow a tar archive to be mounted as a read-only file system.

In modern systems, you can do the same sort of things with FUSE,
and set up the same I-want-to-use-your-disks (or I want to get
at my own files from afar without privileges) scheme with sshfs.
I would be very surprised to learn that either of those borrowed
from their ancient cousins in Research UNIX; so far as I know
they're independent inventions.  Either way I'm glad they exist.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 23:07     ` [TUHS] " Larry McVoy
@ 2022-06-19 23:19       ` Brad Spencer
  2022-06-20  5:03         ` Arno Griffioen via TUHS
  0 siblings, 1 reply; 9+ messages in thread
From: Brad Spencer @ 2022-06-19 23:19 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

Larry McVoy <lm@mcvoy.com> writes:

> On Sun, Jun 19, 2022 at 09:46:31PM +0100, Derek Fawcus wrote:
>> On Fri, Jun 17, 2022 at 10:00:19PM -0700, Kevin Bowling wrote:
>> > On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy douglas.mcilroy@dartmouth.edu> wrote:
>> > >
>> > > V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
>> > > mapped UIDS, thus allowing files to be shared among computers in
>> > > different jurisdictions with different UID lists. Unfortunately, RFS
>> > > went the way of Reiser paging.
>> > 
>> > I believe RFS shipped in SVR3, at least as a package for the 3b2.
>> 
>> Apparently. I've a book (ISBN 0-672-48440-4) with a short chapter on it within, authored by Douglas Harris.
>> 
>> It happens to state:
>> 
>>   AT&T's approach towards UNIX System V, Release 3.0 and beyond is to provide a /Remote File System/ (RFS) that is an extension of the ordinary file system arrangement. [???]
>
> SunOS 4.x shipped RFS, Howard Chartok (my office mate at the time) did
> the port I believe.  Thankless work since Sun ran their entire campus
> on NFS; RFS never got any attention.  It's too bad because it did solve
> some problems that NFS just punted on.  NFS is Clem's law in action,
> it was good enough, not great, but still won.




I remember SunOS 4.x having RFS..  I never used it but I vaguely recall
(probably misremembering) that there was a warning in the man page about
it that it might not interoperate with /dev devices correct if the byte
order of the machines was different.  I seem to recall that with RFS if
/dev was remoted you actually accessed the remote devices and not just
the device nodes from the system that /dev was mounted to.  At the AT&T
site I was at we used NFS exclusively too.



-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
@ 2022-06-19 23:07     ` Larry McVoy
  2022-06-19 23:19       ` Brad Spencer
  0 siblings, 1 reply; 9+ messages in thread
From: Larry McVoy @ 2022-06-19 23:07 UTC (permalink / raw)
  To: Derek Fawcus; +Cc: TUHS main list

On Sun, Jun 19, 2022 at 09:46:31PM +0100, Derek Fawcus wrote:
> On Fri, Jun 17, 2022 at 10:00:19PM -0700, Kevin Bowling wrote:
> > On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy douglas.mcilroy@dartmouth.edu> wrote:
> > >
> > > V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
> > > mapped UIDS, thus allowing files to be shared among computers in
> > > different jurisdictions with different UID lists. Unfortunately, RFS
> > > went the way of Reiser paging.
> > 
> > I believe RFS shipped in SVR3, at least as a package for the 3b2.
> 
> Apparently. I've a book (ISBN 0-672-48440-4) with a short chapter on it within, authored by Douglas Harris.
> 
> It happens to state:
> 
>   AT&T's approach towards UNIX System V, Release 3.0 and beyond is to provide a /Remote File System/ (RFS) that is an extension of the ordinary file system arrangement. [???]

SunOS 4.x shipped RFS, Howard Chartok (my office mate at the time) did
the port I believe.  Thankless work since Sun ran their entire campus
on NFS; RFS never got any attention.  It's too bad because it did solve
some problems that NFS just punted on.  NFS is Clem's law in action,
it was good enough, not great, but still won.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-06-20 21:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-20 12:28 [TUHS] Re: RFS (was Re: Re: forgotten versions) Paul Ruizendaal via TUHS
2022-06-20 21:53 ` Derek Fawcus
  -- strict thread matches above, loose matches on Subject: below --
2022-06-20  0:44 Norman Wilson
2022-06-20  1:02 ` George Michaelson
2022-06-20  4:50 ` arnold
2022-06-18  0:35 [TUHS] Re: forgotten versions Douglas McIlroy
2022-06-18  5:00 ` Kevin Bowling
2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
2022-06-19 23:07     ` [TUHS] " Larry McVoy
2022-06-19 23:19       ` Brad Spencer
2022-06-20  5:03         ` Arno Griffioen via TUHS
2022-06-20  6:53           ` Theodore Ts'o

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).