[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ILA-NFS - the flip side
>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 <firstname.lastname@example.org>
Date: Wed, 24 Aug 88 12:13:07 MDT
From: email@example.com (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
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.
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?