[TUHS] NFS 40th anniversary event

[TUHS] NFS 40th anniversary event

[Tom Lyon]

[-- Attachment #1: Type: text/plain, Size: 94 bytes --]

Part of https://www.msstconference.org/

Love it or hate it, should be something for everyone

[-- Attachment #2: Type: text/html, Size: 185 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Larry McVoy]

On Tue, Aug 12, 2025 at 05:59:24PM -0700, Tom Lyon wrote:
> Part of https://www.msstconference.org/
> 
> Love it or hate it, should be something for everyone

I think Sun people love it, because the Sun implementation just worked, the
rest of the world mostly hates it.  I learned this when I left Sun and got
to use other NFS implementations, they sucked.

We supported BitKeeper on NFS which meant we had to do lock files on
NFS on all platforms.  Believe me when I say I know that other NFS
implementations were a mess.  Read all the drama here:

https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/sccs_lockfile.c

I really didn't get the NFS hate until I left Sun.  Sun ran their entire 
company on NFS (and the automounter).  The whole experience was super
pleasant and it just worked.  Other companies didn't work as hard on their
implementation, I got the feeling it was "well, we have to support this
but don't really want to".  And it showed.

I believe later versions of Linux approached SunOS level of NFS.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: NFS 40th anniversary event

[Dave Horsfall]

On Tue, 12 Aug 2025, Larry McVoy wrote:

> I think Sun people love it, because the Sun implementation just worked, 
> the rest of the world mostly hates it.  I learned this when I left Sun 
> and got to use other NFS implementations, they sucked.

I can vouch for Sun's NFS working well, and others' not so much (zeroed 
blocks returned etc)...

> We supported BitKeeper on NFS which meant we had to do lock files on NFS 
> on all platforms.  Believe me when I say I know that other NFS 
> implementations were a mess.  Read all the drama here:

I'm impressed by the workarounds for obscure kernel bugs :-)

-- Dave

[TUHS] Greetings!

[Phillip Harbison]

Thank you to whoever added me to this list!

I have been a UNIX & C disciple since 1982. I spent much of the 1980s 
writing UNIX, BSD, and OSF/1 device drivers. I ran "madhat", the first 
public access USENET site in Huntsville. Madhat was a homebuilt 68000 
running Unisoft's port of System V Release 0. I also set up "uahcs1", 
the first UNIX and USENET host at The University of Alabama in 
Huntsville (UAH). Uahcs1 was a Unisys U7000, originally known as the 
Power 6/32 minicomputer developed by Computer Consoles Inc., running 
their port of 4.3 BSD.

During my career I have worked with UNIX v7, UNIX System V, AIX, BSD, 
HPUX, IRIX, Linux, MkLinux, OSF/1, Solaris, SunOS, Ultrix, and Xenix, as 
well as variants such as Mach, Minix, and Xinu. All of my currently 
active systems run various versions of macOS. In the past my home office 
was a Microsoft-Free Zone (tm) but alas too many clients insisted on the 
use of "Word" so I was forced to compromise and partially surrender to 
the Dark Side (but only in a Windoze VM).

One of my current hobby projects is building a RISC processor using 1980 
technology, specifically the Am2900 family of bit-slice components. I 
call it Project Madhat.  My goal is to perform as well as a VAX-11/780 
at least for integer code. I hope it will eventually run 4.4 BSD. If 
interested you can read about it here.

http://www.xavax.com/madhat/

My professional work is fragmented. For years I've been developing a 
Massively-Parallel Processor based on the NXP (formerly Freescale or 
Motorola) T4240 which has 12 PowerPC e6500 cores and built-in Serial 
RapidIO. The execution units will run a lean microkernel but the overall 
system will be managed by some flavor of UNIX. I don't currently have 
any information about the MPP online without an NDA, but I would be 
happy to answer general questions about it.

I was recently motivated by the Russo-Ukraine war to start a company 
called Trident Droneworks. It is developing systems for the Ukrainian 
military. If interested you can read about that here.

http://tridentdroneworks.com/

Thanks again for adding me. I look forward to discussing UNIX lore.

-- 
Phillip L Harbison

[TUHS] Re: NFS 40th anniversary event

[Douglas McIlroy]

I was always sorry that Peter Weinberger's RFS never made it outside
Bell Labs. It allowed networking between separately administered
systems by mapping UIDs.

Doug

On Tue, Aug 12, 2025 at 11:05 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Tue, 12 Aug 2025, Larry McVoy wrote:
>
> > I think Sun people love it, because the Sun implementation just worked,
> > the rest of the world mostly hates it.  I learned this when I left Sun
> > and got to use other NFS implementations, they sucked.
>
> I can vouch for Sun's NFS working well, and others' not so much (zeroed
> blocks returned etc)...
>
> > We supported BitKeeper on NFS which meant we had to do lock files on NFS
> > on all platforms.  Believe me when I say I know that other NFS
> > implementations were a mess.  Read all the drama here:
>
> I'm impressed by the workarounds for obscure kernel bugs :-)
>
> -- Dave

[TUHS] Re: NFS 40th anniversary event

[Dan Cross]

On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
<douglas.mcilroy@dartmouth.edu> wrote:
> I was always sorry that Peter Weinberger's RFS never made it outside
> Bell Labs. It allowed networking between separately administered
> systems by mapping UIDs.

I believe it did?  If I recall correctly, it was available with System
V, though perhaps I am misremembering.

I have no doubt that RFS was technically superior to NFS, but Sun had
non-technical market advantages. Assuming that I am remembering
correctly, I suspect it was unsuccessful commercially for two reasons:

1. Sun gave NFS (and the associated RPC layer) away for free, under a
particularly liberal license, which lead to lots of interoperability
(Larry's and Dave's comments notwithstanding). I suspect by the time
RFS was available, it was much more expensive and less interoperable
across heterogeneous systems.
2. Sun was quite adamant that NFS be stateless, and also not tied to
Unix filesystem semantics, whereas (as I understood it) RFS was both
stateful and deeply imbued with Unix semantics.

Related to (2), while the File System Switch that was developed to
support RFS was very elegant, I think that Sun's "vnode" architecture
was seen as more flexible, permitting Unix to incorporate support for
all sorts of foreign filesystem types (useful when CD-ROMs and things
like floppy disks using the MS-DOS FAT format started becoming
common). I suppose RFS could have been adapted to use vnodes, but by
then it probably wasn't considered worth the effort due to lack of
adoption.

It may be worth mentioning that some NFS implementations are
configurable for UID remapping in the server.

I recall Sun environments with NFS and NIS (the mechanism for
distributing /etc/passwd, groups, and other administrative data around
a network). It was a really pleasant environment, and extremely
productive. Properly configured, you could log into essentially any
machine on the network and have access to your home directory, common
data, locally installed programs (that of course lived on NFS), and so
on. It was quite common to tell a colleague to just have a look in
your home directory for something you were working on, facilitating
collaboration, and so on. Diskless and "dataless" machines were
common; the latter being machines that mounted _most_ things from a
central NFS server, but had the operating system itself (really, /,
/usr and /tmp) locally installed on a disk.

It required a lot of effort to maintain, since Unix machines were
still fundamentally meant to be standalone, and it wasn't as elegant
as Plan 9 ultimately was, but it was very nice for the time.

        - Dan C.

> On Tue, Aug 12, 2025 at 11:05 PM Dave Horsfall <dave@horsfall.org> wrote:
> >
> > On Tue, 12 Aug 2025, Larry McVoy wrote:
> >
> > > I think Sun people love it, because the Sun implementation just worked,
> > > the rest of the world mostly hates it.  I learned this when I left Sun
> > > and got to use other NFS implementations, they sucked.
> >
> > I can vouch for Sun's NFS working well, and others' not so much (zeroed
> > blocks returned etc)...
> >
> > > We supported BitKeeper on NFS which meant we had to do lock files on NFS
> > > on all platforms.  Believe me when I say I know that other NFS
> > > implementations were a mess.  Read all the drama here:
> >
> > I'm impressed by the workarounds for obscure kernel bugs :-)
> >
> > -- Dave

[TUHS] Re: NFS 40th anniversary event

[arnold]

Dan Cross <crossd@gmail.com> wrote:

> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
> <douglas.mcilroy@dartmouth.edu> wrote:
> > I was always sorry that Peter Weinberger's RFS never made it outside
> > Bell Labs. It allowed networking between separately administered
> > systems by mapping UIDs.
>
> I believe it did?  If I recall correctly, it was available with System
> V, though perhaps I am misremembering.

It was a different RFS, developed by USG.  It had full Unix semantics,
including ioctls and fcntl, for machines of the same architecture. It
was stateful, which meant if the server went away, you could hang your
shell at the very least. It first came out in SVR3.

Earlier versions of SunOS 5 supported it; it was dropped in later
versions.

It didn't get widespread support both because NFS had a big head
start, and because by the time it came out, the SVR3 licensing terms
had gotten onerous for most vendors.

No disagreement with the rest of you note. :-)

Arnold

[TUHS] Re: NFS 40th anniversary event

[Douglas McIlroy]

"never made it outside Bell Labs" was a poor choice of words for
"never gained acceptance outside of Bell Labs".
I agree with Dan and Arnold, but I lament the fact that NFS : RFS ::
intranet : internet  RFS had the grander vision. To be fair, I must
admit that I have no idea how efficient or robust the released version
was. Certainly the original worked very well.

Doug

On Wed, Aug 13, 2025 at 11:00 AM <arnold@skeeve.com> wrote:
>
> Dan Cross <crossd@gmail.com> wrote:
>
> > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
> > <douglas.mcilroy@dartmouth.edu> wrote:
> > > I was always sorry that Peter Weinberger's RFS never made it outside
> > > Bell Labs. It allowed networking between separately administered
> > > systems by mapping UIDs.
> >
> > I believe it did?  If I recall correctly, it was available with System
> > V, though perhaps I am misremembering.
>
> It was a different RFS, developed by USG.  It had full Unix semantics,
> including ioctls and fcntl, for machines of the same architecture. It
> was stateful, which meant if the server went away, you could hang your
> shell at the very least. It first came out in SVR3.
>
> Earlier versions of SunOS 5 supported it; it was dropped in later
> versions.
>
> It didn't get widespread support both because NFS had a big head
> start, and because by the time it came out, the SVR3 licensing terms
> had gotten onerous for most vendors.
>
> No disagreement with the rest of you note. :-)
>
> Arnold

[TUHS] Re: NFS 40th anniversary event

[arnold]

System V RFS was a different animal that Research RFS. IIRC
Stephen Rago or someone like that did a USENIX paper about putting
the Research RFS into SVR4.

SVR4 RFS required kernel changes for client and server, IIRC,
whereas I believe that Research RFS only needed kernel changes
for the client and used a user-level server.

To borrow a phrase, "memory grows dim", so take the above with a
grain of salt.

Arnold

Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:

> "never made it outside Bell Labs" was a poor choice of words for
> "never gained acceptance outside of Bell Labs".
> I agree with Dan and Arnold, but I lament the fact that NFS : RFS ::
> intranet : internet  RFS had the grander vision. To be fair, I must
> admit that I have no idea how efficient or robust the released version
> was. Certainly the original worked very well.
>
> Doug
>
> On Wed, Aug 13, 2025 at 11:00 AM <arnold@skeeve.com> wrote:
> >
> > Dan Cross <crossd@gmail.com> wrote:
> >
> > > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
> > > <douglas.mcilroy@dartmouth.edu> wrote:
> > > > I was always sorry that Peter Weinberger's RFS never made it outside
> > > > Bell Labs. It allowed networking between separately administered
> > > > systems by mapping UIDs.
> > >
> > > I believe it did?  If I recall correctly, it was available with System
> > > V, though perhaps I am misremembering.
> >
> > It was a different RFS, developed by USG.  It had full Unix semantics,
> > including ioctls and fcntl, for machines of the same architecture. It
> > was stateful, which meant if the server went away, you could hang your
> > shell at the very least. It first came out in SVR3.
> >
> > Earlier versions of SunOS 5 supported it; it was dropped in later
> > versions.
> >
> > It didn't get widespread support both because NFS had a big head
> > start, and because by the time it came out, the SVR3 licensing terms
> > had gotten onerous for most vendors.
> >
> > No disagreement with the rest of you note. :-)
> >
> > Arnold

[TUHS] Re: NFS 40th anniversary event

[Martin Schröder]

Am Mi., 13. Aug. 2025 um 17:00 Uhr schrieb <arnold@skeeve.com>:
> It was a different RFS, developed by USG.  It had full Unix semantics,
> including ioctls and fcntl, for machines of the same architecture. It
> was stateful, which meant if the server went away, you could hang your
> shell at the very least. It first came out in SVR3.

Was that https://en.wikipedia.org/wiki/Remote_File_Sharing ?

If so, that article wants some love from an expert.
And what became of it?

Best
    Martin

[TUHS] Re: NFS 40th anniversary event

[arnold]

Martin Schröder <martin@oneiros.de> wrote:

> Am Mi., 13. Aug. 2025 um 17:00 Uhr schrieb <arnold@skeeve.com>:
> > It was a different RFS, developed by USG.  It had full Unix semantics,
> > including ioctls and fcntl, for machines of the same architecture. It
> > was stateful, which meant if the server went away, you could hang your
> > shell at the very least. It first came out in SVR3.
>
> Was that https://en.wikipedia.org/wiki/Remote_File_Sharing ?

Yes.

> If so, that article wants some love from an expert.

I"m not enough of an expert to tackle it. I used RFS in a classroom
setting for a few years, but that's it, and that was ~ 30 years ago.

> And what became of it?

It never caught on. Source for it can be found in SVR3 and SVR4,
if you have those.

Arnold

[TUHS] Re: NFS 40th anniversary event

[Larry McVoy]

On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
> <douglas.mcilroy@dartmouth.edu> wrote:
> > I was always sorry that Peter Weinberger's RFS never made it outside
> > Bell Labs. It allowed networking between separately administered
> > systems by mapping UIDs.
> 
> I believe it did?  If I recall correctly, it was available with System
> V, though perhaps I am misremembering.

Sunos had it, my office mate ported it.  I was unimpressed, it worked well
between the same archs but was riddled with byte order problems and
ioctl calls that were not portable.

[TUHS] Re: NFS 40th anniversary event

[Peter Weinberger (温博格) via TUHS]

It was a research proof-of-princple. (i.e.. partly principled and
partly really hacky. My list of its issues was pretty long.)

(If A mounted B's file system somewhere, and B mounted A's, then the
directory tree was infinite. That's mathematics, not a bug.)

On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
> > <douglas.mcilroy@dartmouth.edu> wrote:
> > > I was always sorry that Peter Weinberger's RFS never made it outside
> > > Bell Labs. It allowed networking between separately administered
> > > systems by mapping UIDs.
> >
> > I believe it did?  If I recall correctly, it was available with System
> > V, though perhaps I am misremembering.
>
> Sunos had it, my office mate ported it.  I was unimpressed, it worked well
> between the same archs but was riddled with byte order problems and
> ioctl calls that were not portable.

[TUHS] Re: NFS 40th anniversary event

[Tom Lyon]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here:
https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon

Not that NFS *was* bad - but it *is* bad (for non-casual use).
Like the C language, it was great for its time.  Not so much anymore.



On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS <
tuhs@tuhs.org> wrote:

> It was a research proof-of-princple. (i.e.. partly principled and
> partly really hacky. My list of its issues was pretty long.)
>
> (If A mounted B's file system somewhere, and B mounted A's, then the
> directory tree was infinite. That's mathematics, not a bug.)
>
> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
> > > <douglas.mcilroy@dartmouth.edu> wrote:
> > > > I was always sorry that Peter Weinberger's RFS never made it outside
> > > > Bell Labs. It allowed networking between separately administered
> > > > systems by mapping UIDs.
> > >
> > > I believe it did?  If I recall correctly, it was available with System
> > > V, though perhaps I am misremembering.
> >
> > Sunos had it, my office mate ported it.  I was unimpressed, it worked
> well
> > between the same archs but was riddled with byte order problems and
> > ioctl calls that were not portable.
>

[-- Attachment #2: Type: text/html, Size: 2127 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Larry McVoy]

They both served a purpose.  I'm still a fan of both, C especially,
but I'll admit that C needs careful programmers.  When my older son was
getting into programming, he asked about C (he started with python and
hates it, has moved to Julia for most mathy stuff).  I told him that C is
like a sports car on a narrow, twisty, mountain road with no guard rails.
If you drive a car like that in those conditions, and look at your phone,
you're gonna have a very bad day.  On the other hand, if you are a good
driver and are paying attention, that can be a boat load of fun.

I'm watching your talk and I'm struct by how much of this problem space
we solved in BitKeeper.  Someone had a .signature that said "You're lost
in a tree of repositories, all almost the same".  We certainly solved the
shared mutable data problem.  Our stuff didn't scale to billions of files
though we took a stab at that with nested repositories that worked pretty
well.

I got to the point where you are more or less arguing for the same thing.
I'd be careful about scaling.  If you want consistency, you have to keep
a list of files you are managing.  That list gets big.

As for POSIX, I've very much read the early spec, the whole thing, many
times.  My first job at Sun was implementing POSIX conformance in SunOS.
Maybe I'm naive, but I didn't find it particularly hard, it was a lot of
grunt work, a lot of checking each file system to make them all the same.
I'm sure there is some subtle thing I've missed but Sun was happy with
my work so I don't think I was that far off.

On Wed, Aug 13, 2025 at 09:43:08AM -0700, Tom Lyon wrote:
> BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here:
> https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon
> 
> Not that NFS *was* bad - but it *is* bad (for non-casual use).
> Like the C language, it was great for its time.  Not so much anymore.
> 
> 
> 
> On Wed, Aug 13, 2025 at 9:24???AM Peter Weinberger (?????????) via TUHS <
> tuhs@tuhs.org> wrote:
> 
> > It was a research proof-of-princple. (i.e.. partly principled and
> > partly really hacky. My list of its issues was pretty long.)
> >
> > (If A mounted B's file system somewhere, and B mounted A's, then the
> > directory tree was infinite. That's mathematics, not a bug.)
> >
> > On Wed, Aug 13, 2025 at 11:56???AM Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> > > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
> > > > <douglas.mcilroy@dartmouth.edu> wrote:
> > > > > I was always sorry that Peter Weinberger's RFS never made it outside
> > > > > Bell Labs. It allowed networking between separately administered
> > > > > systems by mapping UIDs.
> > > >
> > > > I believe it did?  If I recall correctly, it was available with System
> > > > V, though perhaps I am misremembering.
> > >
> > > Sunos had it, my office mate ported it.  I was unimpressed, it worked
> > well
> > > between the same archs but was riddled with byte order problems and
> > > ioctl calls that were not portable.
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: NFS 40th anniversary event

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

 From my own experience, no real depth of knowledge here... I use NFS 
for my home shares. Painless with automount and nfsv4. I can't speak to 
widespread use in enterprise, but as a "casual" nfs user, it gets the 
job done nicely. I share a folder called ark from one of my servers and 
mount it on all of my machines. The ark lives on a mirrored zpool that 
is frequently snapshotted to another mirrored zpool on another server 
(I'm less of a zfs casual user, but that's an aside). I haven't lost a 
bit this way in the couple of years since I stood up the nfs share and I 
offloaded about 1TB of stuff I like to have on hand to the server. I 
tried Samba, ick, seems like windowism to me and I tried some NAS stuff, 
but nfs was fastest and simplest. I haven't really found anything better 
that works as painlessly as nfs, though I do look into alternatives 
every so often.

What else to try?

Thanks,

Will



On 8/13/25 11:43 AM, Tom Lyon wrote:
> BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk 
> here: https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon 
> <https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon>
>
> Not that NFS *was* bad - but it *is* bad (for non-casual use).
> Like the C language, it was great for its time.  Not so much anymore.
>
>
>
> On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS 
> <tuhs@tuhs.org> wrote:
>
>     It was a research proof-of-princple. (i.e.. partly principled and
>     partly really hacky. My list of its issues was pretty long.)
>
>     (If A mounted B's file system somewhere, and B mounted A's, then the
>     directory tree was infinite. That's mathematics, not a bug.)
>
>     On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy <lm@mcvoy.com> wrote:
>     >
>     > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
>     > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
>     > > <douglas.mcilroy@dartmouth.edu> wrote:
>     > > > I was always sorry that Peter Weinberger's RFS never made it
>     outside
>     > > > Bell Labs. It allowed networking between separately administered
>     > > > systems by mapping UIDs.
>     > >
>     > > I believe it did?  If I recall correctly, it was available
>     with System
>     > > V, though perhaps I am misremembering.
>     >
>     > Sunos had it, my office mate ported it.  I was unimpressed, it
>     worked well
>     > between the same archs but was riddled with byte order problems and
>     > ioctl calls that were not portable.
>

[-- Attachment #2: Type: text/html, Size: 4249 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Bakul Shah via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

I viewed this last October. Seemed like a bunch of sensible ideas. Did you find any collaborators? [Not offering, just curious!]

I see these "storage" categories: chunks, files, namespaces, metadata, databases & streams [1]. If you define a network protocol to handle critical operations on them all, implementations would likely follow. Engineers do better with well defined boundaries compared to "somewhere beyond there"!

[1] probably could be simplified.

> On Aug 13, 2025, at 9:43 AM, Tom Lyon <pugs78@gmail.com> wrote:
> 
> BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon
> 
> Not that NFS *was* bad - but it *is* bad (for non-casual use).
> Like the C language, it was great for its time.  Not so much anymore.
> 
> 
> 
> On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote:
>> It was a research proof-of-princple. (i.e.. partly principled and
>> partly really hacky. My list of its issues was pretty long.)
>> 
>> (If A mounted B's file system somewhere, and B mounted A's, then the
>> directory tree was infinite. That's mathematics, not a bug.)
>> 
>> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy <lm@mcvoy.com <mailto:lm@mcvoy.com>> wrote:
>> >
>> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
>> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
>> > > <douglas.mcilroy@dartmouth.edu <mailto:douglas.mcilroy@dartmouth.edu>> wrote:
>> > > > I was always sorry that Peter Weinberger's RFS never made it outside
>> > > > Bell Labs. It allowed networking between separately administered
>> > > > systems by mapping UIDs.
>> > >
>> > > I believe it did?  If I recall correctly, it was available with System
>> > > V, though perhaps I am misremembering.
>> >
>> > Sunos had it, my office mate ported it.  I was unimpressed, it worked well
>> > between the same archs but was riddled with byte order problems and
>> > ioctl calls that were not portable.


[-- Attachment #2: Type: text/html, Size: 3223 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Tom Lyon]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

No collaborators.  Not that I'm trying at all, the talk kinda got the urge
out of my system.
I therorize that many people could benefit - but no hard data.

On Wed, Aug 13, 2025 at 6:41 PM Bakul Shah <bakul@iitbombay.org> wrote:

> I viewed this last October. Seemed like a bunch of sensible ideas. Did you
> find any collaborators? [Not offering, just curious!]
>
> I see these "storage" categories: chunks, files, namespaces, metadata,
> databases & streams [1]. If you define a network protocol to handle
> critical operations on them all, implementations would likely follow.
> Engineers do better with well defined boundaries compared to "somewhere
> beyond there"!
>
> [1] probably could be simplified.
>
> On Aug 13, 2025, at 9:43 AM, Tom Lyon <pugs78@gmail.com> wrote:
>
> BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here:
> https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon
>
> Not that NFS *was* bad - but it *is* bad (for non-casual use).
> Like the C language, it was great for its time.  Not so much anymore.
>
>
>
> On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS <
> tuhs@tuhs.org> wrote:
>
>> It was a research proof-of-princple. (i.e.. partly principled and
>> partly really hacky. My list of its issues was pretty long.)
>>
>> (If A mounted B's file system somewhere, and B mounted A's, then the
>> directory tree was infinite. That's mathematics, not a bug.)
>>
>> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy <lm@mcvoy.com> wrote:
>> >
>> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
>> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy
>> > > <douglas.mcilroy@dartmouth.edu> wrote:
>> > > > I was always sorry that Peter Weinberger's RFS never made it outside
>> > > > Bell Labs. It allowed networking between separately administered
>> > > > systems by mapping UIDs.
>> > >
>> > > I believe it did?  If I recall correctly, it was available with System
>> > > V, though perhaps I am misremembering.
>> >
>> > Sunos had it, my office mate ported it.  I was unimpressed, it worked
>> well
>> > between the same archs but was riddled with byte order problems and
>> > ioctl calls that were not portable.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3506 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Jonathan Gray]

On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
> <douglas.mcilroy@dartmouth.edu> wrote:
> > I was always sorry that Peter Weinberger's RFS never made it outside
> > Bell Labs. It allowed networking between separately administered
> > systems by mapping UIDs.
> 
> I believe it did?  If I recall correctly, it was available with System
> V, though perhaps I am misremembering.
> 
> I have no doubt that RFS was technically superior to NFS, but Sun had
> non-technical market advantages. Assuming that I am remembering
> correctly, I suspect it was unsuccessful commercially for two reasons:
> 
> 1. Sun gave NFS (and the associated RPC layer) away for free, under a
> particularly liberal license, which lead to lots of interoperability
> (Larry's and Dave's comments notwithstanding). I suspect by the time
> RFS was available, it was much more expensive and less interoperable
> across heterogeneous systems.

The NFS reference code was licensed under NDA with some cost involved
according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno.

Rick Macklem post to comp.protocols.nfs Aug 6, 1999
https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ

The userland RPC part was under different terms.

"Sun will publish the source code for the user-level libraries that
implement RPC and XDR."

Bill Shannon post to net.unix-wizards Jan 13, 1985
https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J

Sun RPC sources were later posted to mod.sources and included
on USENIX tapes.

[TUHS] Re: NFS 40th anniversary event

[Charles H. Sauer (he/him)]

On 8/13/2025 7:31 PM, Jonathan Gray wrote:
> On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
>> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
>> <douglas.mcilroy@dartmouth.edu> wrote:
>>> I was always sorry that Peter Weinberger's RFS never made it outside
>>> Bell Labs. It allowed networking between separately administered
>>> systems by mapping UIDs.
>>
>> I believe it did?  If I recall correctly, it was available with System
>> V, though perhaps I am misremembering.
>>
>> I have no doubt that RFS was technically superior to NFS, but Sun had
>> non-technical market advantages. Assuming that I am remembering
>> correctly, I suspect it was unsuccessful commercially for two reasons:
>>
>> 1. Sun gave NFS (and the associated RPC layer) away for free, under a
>> particularly liberal license, which lead to lots of interoperability
>> (Larry's and Dave's comments notwithstanding). I suspect by the time
>> RFS was available, it was much more expensive and less interoperable
>> across heterogeneous systems.
> 
> The NFS reference code was licensed under NDA with some cost involved
> according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno.
> 
> Rick Macklem post to comp.protocols.nfs Aug 6, 1999
> https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ
> 
> The userland RPC part was under different terms.
> 
> "Sun will publish the source code for the user-level libraries that
> implement RPC and XDR."
> 
> Bill Shannon post to net.unix-wizards Jan 13, 1985
> https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J
> 
> Sun RPC sources were later posted to mod.sources and included
> on USENIX tapes.

That's consistent with my memory. In particular, if I recall correctly, 
when I was still at IBM and we wanted to include NFS in AIX 3, it was 
challenging ($$$) to negotiate a satisfactory license for NFS, but we 
eventually obtained a license to include NFS in all IBM products (not 
just AIX).
-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/mas.to: CharlesHSauer

[TUHS] Re: NFS 40th anniversary event

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

On 8/13/2025 7:31 PM, Jonathan Gray wrote:
> > Sun RPC sources were later posted to mod.sources and included
> > on USENIX tapes.
>

Volume 7 of mod.sources published Sun RPC code,
https://www.tuhs.org/Usenet/mod.sources/1986-August/000016.html

    /r$, moderator thereof

[-- Attachment #2: Type: text/html, Size: 654 bytes --]

[TUHS] Re: NFS 40th anniversary event

[Tom Lyon]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

Indeed, IBM had quite broad support for NFS.
There's a whole chapter in this Redbook (1993) about OS/2 NFS clients
working with AIX, MVS, VM, and OS/2 servers.
https://ia801201.us.archive.org/11/items/gg243531/gg243531_TCPIP_2_0_for_OS2_Installation_and_Interoperability.pdf

On Wed, Aug 13, 2025 at 5:54 PM Charles H. Sauer (he/him) <
sauer@technologists.com> wrote:

> On 8/13/2025 7:31 PM, Jonathan Gray wrote:
> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote:
> >> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy
> >> <douglas.mcilroy@dartmouth.edu> wrote:
> >>> I was always sorry that Peter Weinberger's RFS never made it outside
> >>> Bell Labs. It allowed networking between separately administered
> >>> systems by mapping UIDs.
> >>
> >> I believe it did?  If I recall correctly, it was available with System
> >> V, though perhaps I am misremembering.
> >>
> >> I have no doubt that RFS was technically superior to NFS, but Sun had
> >> non-technical market advantages. Assuming that I am remembering
> >> correctly, I suspect it was unsuccessful commercially for two reasons:
> >>
> >> 1. Sun gave NFS (and the associated RPC layer) away for free, under a
> >> particularly liberal license, which lead to lots of interoperability
> >> (Larry's and Dave's comments notwithstanding). I suspect by the time
> >> RFS was available, it was much more expensive and less interoperable
> >> across heterogeneous systems.
> >
> > The NFS reference code was licensed under NDA with some cost involved
> > according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno.
> >
> > Rick Macklem post to comp.protocols.nfs Aug 6, 1999
> >
> https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ
> >
> > The userland RPC part was under different terms.
> >
> > "Sun will publish the source code for the user-level libraries that
> > implement RPC and XDR."
> >
> > Bill Shannon post to net.unix-wizards Jan 13, 1985
> >
> https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J
> >
> > Sun RPC sources were later posted to mod.sources and included
> > on USENIX tapes.
>
> That's consistent with my memory. In particular, if I recall correctly,
> when I was still at IBM and we wanted to include NFS in AIX 3, it was
> challenging ($$$) to negotiate a satisfactory license for NFS, but we
> eventually obtained a license to include NFS in all IBM products (not
> just AIX).
> --
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/LinkedIn/mas.to
> <https://technologists.com/sauer/Facebook/Google/LinkedIn/mas.to>:
> CharlesHSauer
>
>

[-- Attachment #2: Type: text/html, Size: 3924 bytes --]

[TUHS] RFS

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Douglas McIlroy writes:
> I was always sorry that Peter Weinberger's RFS never made it outside
> Bell Labs. It allowed networking between separately administered
> systems by mapping UIDs.

My experience with (SVR3) RFS can be summed up in two words:

	stateful, and brittle

We ran RFS on a "cluster" of four 3B2s, and while it worked, to
varying degrees, the statefulness of the protocol inevitably led
to the whole thing locking up, requiring a reboot of all four
machines to recover.  This was especially problematic when we
accessed the one 9-track drive over RFS when attempting backups.

I eventually gave up on it, and hauled out the Lachman NFS source
tape and got NFS running on all the machines.  Life was much happier
afterwards.

I do not miss RFS.

--lyndon

[TUHS] RFS

[Steve Simon]

my memory is the major differences between the research RFS and USG’s RFS was the support of ioctls (as mentioned) and, Research RFS supported exporting file trees with an abstract name rather than the path on the source machine - a small but very useful change.

research RFS could (i feel) be seen as the direct ancestor of plan9’s 9p protocol.

-Steve