24 Sep
2017
24 Sep
'17
7:51 p.m.
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....