[TUHS] NFS 40th anniversary event

[Bakul Shah via TUHS]

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 at 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 at tuhs.org <mailto:tuhs at 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 at mcvoy.com <mailto:lm at 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 at dartmouth.edu <mailto:douglas.mcilroy at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250813/277f65c6/attachment.htm>