Where does RFS (AT&T System III) fit in all of this?

I used it for a while between a SunOS 4.1.3 box and a PC running AT&T SVR4.2 (Consensys) because the client-side NFS was buggy on the SVR4.2 side. This was in the days when I ran a UUCP node (kilowatt) in the early 90's and needed access from the PC to the "large" (5.25" FH 1GB) disk on the SunOS machine. It worked, that I can say.

Eventually, I swapped it around after getting an Adaptec SCSI controller for the PC - turned out the server-side NFS on this particular SVR4.2 was fine.

Just looking for history on RFS if any.

thanks!

On 9/24/2017 1:33 PM, Clem Cole wrote:

​To me, the really important thing SMI did by giving away NFS, was to start the FS laying argument.   What we ended up with is not perfect, its a compromise (I wish the stacking model was better), but we started to have the discussion.​   But because of NFS, we ended up getting a lot of different file system options; which previously we did not have.   It made us really think through what were 'meta' functions that were FS independant, 'virtual' functions what span all FS implementasions, and what were 'physical' (implementation) specific file system functions. 

NFS really should be credited for forcing that clean up.

Similarly, a few of us tried (and failed) to have the process layer discussion -- consider the Locus vprocs work.   It's really too bad, we don't have that layer in any of the UNIX kernels today, it really make process control, migration, etc a lot cleaner; just as adding a file system layer did.

But that's a war, I fought and lost....