[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
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.
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
implementations.
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.