[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ILA-NFS - the flip side

    Date: 25 Aug 88  9:39 +0100
    From: ceb%eiger.uucp@relay.cs.net

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

    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

    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

       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.

We at ILA have worked hard at trying to support both the NFS server and Client
for the Lisp Machine for as many other machines as possible.  However, since
the NFS file access protocol leaves so much room for interpretation, the only
way that one can make sure it works between two implementations is by trying
it out.  Because of this and the limited resources of ILA, we depend somewhat
on our customers to do some investigations and give us feedback about
incompatibilities with other implementations.

    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.

ILA-NFS automatically figures out where the files are if you communicate the
information to it.  In version 8, you do this by allowing the lisp machine
access to the /etc/mtab files so that ILA-NFS can read them and figure out
where the mount points are.  I understand the reasons why one would not want
to do this (in most UNIX NFS server implementations you can't export a
filesystem read-only), so in version 11, the currently available version of
NFS, you can put this information in the Namespace as well.

    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.

This not quite a correct interpretation of what is going on, but in the
current release of ILA-NFS, version 11, we did speed up the client
substantially by adding caching of directory information.  I have found it now
faster to use NFS to a Sun server than NFILE to an equally loaded 3600.  With
the introduction of true version number handling for UNIX hosts in version 11
of NFS, you can even maintain multiple versions of SCT systems on UNIX
servers, just like on LISPM servers.

    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.

This bug has been fixed with the new use of DES authentication introduced with
Sun OS 4.0, but will take a while for all implementations to support it.
ILA-NFS 11 doesn't support it yet because we haven't been able to get to a
machine running Sun OS 4.0 to test it out, let alone test it out on other NFS

       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?

If you have a software service agreement, I would be glad to assist in
resolving any problems you have with the product.  Currently there is a
mailing list to report bugs, with address bug-nfs@reagan.ai.mit.edu.  Soon
when ILA-NFS is distributed by Symbolics, you will be able to report bugs
through the Symbolics Customer-Reports mailing list.