ILA-NFS - the flip side

[ceb%eiger.uucp@RELAY.CS.NET]

>From iis!eiger!ceb Thu Aug 25 10:37:55 MET 1988 remote from ethz

   Date: 25 Aug 88  0:38 +0200
   From: Barry Margolin <barmar@think.com>

       Date: Wed, 24 Aug 88 12:13:07 MDT
       From: esunix!roma!csteury@cs.utah.edu (Craig Steury)

       I've heard that ILA (International Lisp Association) has implemented
       NFS for the Symbolics.  Can anyone tell me what the advantages
       of using this would be over say, just having tcp/ip?

   ILA-NFS is an excellent product.

   When using a Lispm, one of the main advantages of using NFS rather than
   TCP-FTP is that it will put version numbers on the Unix files.  Also,
   access to file properties is much more complete.

   The bigger advantage is that the Unix systems can use a Lisp Machine
   file server transparently, as if it were another Unix file server.

Well, hold on.

I agree that ILA's NFS interface for Lispms does have its advantages,
in particular, those cited above.  In addition, it seems to cure
90% of the hung network problems I enquired about earlier on this
list.

However, there are some problems that still accompany the product (We
have version 8.11.).

1. It only seems to work with the "mainstream" NFS software:
   1. It interfaces to Sun's SunOS 3.5 or SunOS 4.0 just fine.
   2. It interfaces to Ultrix, but there is certain disfunctionality
      when accessing the Lispm from an Ultrix machine - namely, 
      you can't take a directory (including Dired in Emacs).
      This is known to ILA - the manual says "We're stumped as to
      why."
   3. It does not work with Alliant's Concentrix NFS.  Accessing the
      Lispm from the Concentrix side causes the Concentrix client
      to "crash and burn".
   4. It does not work with Sequent's DYNIX, but in this case
      simply produces error messages - nothing crashes.
   5. I have no experience with other servers.

2. It's rather linear in the way it allows you to access files.   If
   you rely on the information found in the standard UNIX places 
   (/etc/exports, etc.), then you have to access files on a 
   particular server by going through that server.  Small matter
   that these same file systems may be mounted on another server
   you are using through a "sea-of-files" uniform naming scheme, or
   have cross-server symbolic links.

3. I have found that for doing a compile-system where the source and
   prior binary files reside on a Vax server, that NFS is *slower* 
   than FTP.  You see, up til recently at least, typical NFS servers
   left their remote file systems mounted, and thereby avoided
   validation each  time, whereas the ILA NFS does dynamic mounts,
   with apparently short superannuation periods.

   These appear to be software settable, so by playing around, maybe
   it gets better.  However, just "plugging it in" didn't, in our 
   case, lead to heartening results in this department.

4. Since NFS access validation between machines takes place on a
   machine-to-machine basis, there are problems with security at
   the user level.  This makes NFS unusable for situations in which
   you depend on session-level security.  This is also documented in
   the ILA-NFS installation literature.

   It may be that you can figure a way around these using the Access 
   Control Facility (or whatever its called) on the Lispm, but I
   haven't tried very hard (its no longer my job).

It is not to be excluded that these are only problems local here, and
that fixes are known to others.  But that's just another reason for
making a list like this.  Or?

ceb