From: ·······@eurogaran.com
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <dd319553-864b-4f8d-ba91-49a663b84653@l42g2000hsc.googlegroups.com>
There was a LMFS (Lisp Machine File System) to save files on disk. It
was the same (don't know to which point) with the MIT lisp machines,
so one can in theory look for the MIT implementation code.
There was also -as Rainer says- a remote file protocol, but the
Symbolics Virtual lispM, which run as a unix program in a unix machine
(allegedly the last form of lispM), had dropped use of both in favor
of NFS. It even dropped the file browser, one thing that was really to
be missed (seemingly because it was too tied to LMFS).

Andreas Davour wrote:
> I was researching some old lispM features and found out about this
> Symbolics file system. In the RFC there are mentions of unix
> implementations. Are there any code for this available, or is it buried
> in a mess of smothering lawyers?
>
> /andreas
>
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

From: Tim Bradshaw
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <21bfb801-57c4-40f0-a8df-15a72d4e8eeb@l64g2000hse.googlegroups.com>
On Sep 29, 5:23 pm, Andreas Davour <·······@updateLIKE.uu.HELLse>
wrote:

> Did the VLM drop support for the LMFS? Too bad. NFS sucks so it couldn't
> be worse than that.

I forget when, but I remember benchmarking (I think) a 3670 which had
slower performance to its local disk than a 3/120 did accessing
storage over NFS. (Both disks were Fuji eagles, the NFS access was via
a 3/180 or /280 and thickwire).

Yup, NFS sucks all right.
From: Tim Bradshaw
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <dc46860f-61e3-4554-af74-172c08bbe566@k30g2000hse.googlegroups.com>
On Sep 29, 6:06 pm, Andreas Davour <·······@updateLIKE.uu.HELLse>
wrote:

>
> Talking about I/O performance in detail is a big can of worms, since it
> means subtle interaction between hardware and software. You say a 3670
> was slower than a 3/120 and that might be correct. To what extent that
> was because NFS was good/bad is another matter.

Sun 3/120 (sorry).  I didn't say a 3670 was slower than a 3/120 for FS
access: I said it was slower accessing a directly-attached disk than a
3/120 was at accessing the same model of disk over a network.
From: George Neuner
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <bs62e4h1v1kuj7k2hlos1eibg6dsg10974@4ax.com>
On Mon, 29 Sep 2008 19:06:45 +0200, Andreas Davour
<·······@updateLIKE.uu.HELLse> wrote:

>Tim Bradshaw <··········@tfeb.org> writes:
>
>> On Sep 29, 5:23�pm, Andreas Davour <·······@updateLIKE.uu.HELLse>
>> wrote:
>>
>>> Did the VLM drop support for the LMFS? Too bad. NFS sucks so it couldn't
>>> be worse than that.
>>
>> I forget when, but I remember benchmarking (I think) a 3670 which had
>> slower performance to its local disk than a 3/120 did accessing
>> storage over NFS. (Both disks were Fuji eagles, the NFS access was via
>> a 3/180 or /280 and thickwire).
>>
>> Yup, NFS sucks all right.
>
>I have no idea what a 3/120 is. 

A Sun 3 workstation.  It was a relatively low powered 68020 system,
woefully short of RAM but with a fast network interface.  I can attest
that NFS from a 3/120 to a fast server was frequently faster than
local file access.

I don't recall the 3/120 being offered generally though ... I thought
Sun only sold that particular version to colleges.


>Talking about I/O performance in detail is a big can of worms, since it
>means subtle interaction between hardware and software.

Yup.  Waste of time unless you can isolate the component you're
talking about.

George
From: Tim Bradshaw
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <731802bc-ef77-4398-a7c2-0ec866b36579@25g2000hsx.googlegroups.com>
On Sep 29, 8:26 pm, George Neuner <········@comcast.net> wrote:

>
> A Sun 3 workstation.  It was a relatively low powered 68020 system,
> woefully short of RAM but with a fast network interface.  I can attest
> that NFS from a 3/120 to a fast server was frequently faster than
> local file access.
>
> I don't recall the 3/120 being offered generally though ... I thought
> Sun only sold that particular version to colleges.

This was in academia.  But I may also be confused about numbers - it
was a long time ago.  The storage box was a 3/180 (which later became
a 3/280 by some kind of brain swap, and may have been by then) and the
client would have been one of the deskside VME machines - my memory
says 3/120 but perhaps it was really a 3/160 (or even a 3/260).

>
> Yup.  Waste of time unless you can isolate the component you're
> talking about.

I agree in general that I/O performance is complex and not well
summarised by "x is faster than y" generalisations.  Some times it can
be however, and this is one of those cases: LMFS performance, even to
fast disks (by the standard of the day) really sucked compared to what
Suns could do (and do for far less money...).

(Rainer's comment about NFS being faster than LMFS on Symbolics
machines is also likely correct - I don't recall ever trying it (until
much later, anyway).  Certainly it used to be the case that NFS
performance was often much faster than local disk performance for
desktop Suns of that era.)
From: ······@corporate-world.lisp.de
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <64dfcc27-84c1-477c-9f18-9bfeb409a82b@t54g2000hsg.googlegroups.com>
On Sep 30, 12:29 am, Tim Bradshaw <··········@tfeb.org> wrote:
> On Sep 29, 8:26 pm, George Neuner <········@comcast.net> wrote:
>
>
>
> > A Sun 3 workstation.  It was a relatively low powered 68020 system,
> > woefully short of RAM but with a fast network interface.  I can attest
> > that NFS from a 3/120 to a fast server was frequently faster than
> > local file access.
>
> > I don't recall the 3/120 being offered generally though ... I thought
> > Sun only sold that particular version to colleges.
>
> This was in academia.  But I may also be confused about numbers - it
> was a long time ago.  The storage box was a 3/180 (which later became
> a 3/280 by some kind of brain swap, and may have been by then) and the
> client would have been one of the deskside VME machines - my memory
> says 3/120 but perhaps it was really a 3/160 (or even a 3/260).
>
>
>
> > Yup.  Waste of time unless you can isolate the component you're
> > talking about.
>
> I agree in general that I/O performance is complex and not well
> summarised by "x is faster than y" generalisations.  Some times it can
> be however, and this is one of those cases: LMFS performance, even to
> fast disks (by the standard of the day) really sucked compared to what
> Suns could do (and do for far less money...).
>
> (Rainer's comment about NFS being faster than LMFS on Symbolics
> machines is also likely correct - I don't recall ever trying it (until
> much later, anyway).  Certainly it used to be the case that NFS
> performance was often much faster than local disk performance for
> desktop Suns of that era.)

Well, you can think of the SUN as a networked I/O coprocessor.
It may be no surprise that offloading work to another machine
makes the whole system faster (often).
I wonder if the Lisp machine ever had any good hardware
interface to disks, providing for example a I/O subsystem capable
of direct memory access to main memory (which is not the usual
memory, since it was ECCed, type tagged and 36 (later 40) bit wide)
- or do have all I/O operations had to go through the main cpu?

The same is true nowadays for the user interface. The UI
is faster over the network than on the local Lisp Machine
(which still has the old frame buffer, where my X11 server has
a much faster one now).
From: Tim Bradshaw
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <1a186564-7232-41a5-a3d2-1d25293f2708@y21g2000hsf.googlegroups.com>
On Sep 30, 8:51 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:

> Well, you can think of the SUN as a networked I/O coprocessor.

Yes. (Except, of course they ran Lisp faster as well, albeit with a
laughably bad development environment).

Anyway, my point was specifically limited to disputing the "NFS sucks
so it couldn't be worse than that" statement someone made, which I
think was just obviously a stupid thing to say. It had it's problems
of course.

--tim
From: Tim Bradshaw
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <a9eda376-52d6-48ab-84a2-cbc000602cc5@a1g2000hsb.googlegroups.com>
On Sep 30, 10:09 am, Tim Bradshaw <··········@tfeb.org> wrote:
> it's problems

I will now saw my own head off.
From: Rainer Joswig
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <joswig-B6871D.20361529092008@news-europe.giganews.com>
In article <···············@Psilocybe.Update.UU.SE>,
 Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:

> Tim Bradshaw <··········@tfeb.org> writes:
> 
> > On Sep 29, 5:23�pm, Andreas Davour <·······@updateLIKE.uu.HELLse>
> > wrote:
> >
> >> Did the VLM drop support for the LMFS? Too bad. NFS sucks so it couldn't
> >> be worse than that.
> >
> > I forget when, but I remember benchmarking (I think) a 3670 which had
> > slower performance to its local disk than a 3/120 did accessing
> > storage over NFS. (Both disks were Fuji eagles, the NFS access was via
> > a 3/180 or /280 and thickwire).
> >
> > Yup, NFS sucks all right.

Note that the Symbolics operating system does not use NFILE
to access its local file system. It accesses the LMFS directly.

What was already often faster than local LMFS access is
NFS access to a remote Unix file system. Symbolics machines
were known to have slow disk access. Though I have no idea
why that was the case: slow bus to the disk? inefficient
access to blocks on the disk by the OS? slow LMFS
implementation?. I'd guess it is a mix of those.

> I have no idea what a 3/120 is. 

It would be an old SUN model, though Wikipedia does not mention it.
I'm not sure it existed. The 3/110 was popular, though.

> 
> Talking about I/O performance in detail is a big can of worms, since it
> means subtle interaction between hardware and software. You say a 3670
> was slower than a 3/120 and that might be correct. To what extent that
> was because NFS was good/bad is another matter.
> 
> I have seem NFS break unexpectedly in terrible ways and that sucked. The
> rest of my comment was not an invitation to a serious comparison. Who
> the heck would pit them against each other today anyway?

NFS is short for 'Nightmare File System'.

See chapter 14 of the Unix Haters Handbook:
 
  http://www.simson.net/ref/ugh.pdf



> 
> /Andreas

-- 
http://lispm.dyndns.org/
From: Rainer Joswig
Subject: Re: RFC 1037 NFILE implementations around?
Date: 
Message-ID: <joswig-14690B.18335329092008@news-europe.giganews.com>
In article 
<····································@l42g2000hsc.googlegroups.com>,
 ·······@eurogaran.com wrote:

> There was a LMFS (Lisp Machine File System) to save files on disk. It
> was the same (don't know to which point) with the MIT lisp machines,
> so one can in theory look for the MIT implementation code.
> There was also -as Rainer says- a remote file protocol, but the
> Symbolics Virtual lispM, which run as a unix program in a unix machine
> (allegedly the last form of lispM), had dropped use of both in favor
> of NFS. It even dropped the file browser, one thing that was really to
> be missed (seemingly because it was too tied to LMFS).

There is a version of the VLM which can use a LMFS and has also
the 'local file system control operations' in the file
browser. The VLM also can access a NFILE server on the
network or provide NFILE services, AFAIK.

> 
> Andreas Davour wrote:
> > I was researching some old lispM features and found out about this
> > Symbolics file system. In the RFC there are mentions of unix
> > implementations. Are there any code for this available, or is it buried
> > in a mess of smothering lawyers?
> >
> > /andreas
> >
> > --
> > A: Because it fouls the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing on usenet and in e-mail?

-- 
http://lispm.dyndns.org/