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