[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Lispm vs Unix file servers
[NOTE: As was pointed out in an earlier message, I am really just
kibbitzing here; not responding officially.]
Date: Thu, 9 Aug 90 00:03:06 EDT
Date: Wed, 8 Aug 90 18:05 EDT
From: PTW@JASPER.SCRC.Symbolics.COM (P. T. Withington)
My point was that if you're using NFS you're probably trying to
interoperate with Unix, not just use it as a place to hold bits.
In a .sct hierarchy, that assumption is probably wrong. No Unix programs I
know of can deal with directories where all the files have ~version~
Note that the original complaint was about such a directory,
since he's trying to use it to hold files in a system.
So maybe either your suggestion of a parallel file for attributes or my
suggestion of more funny characters in the file name is an approach;
although not what I would call the best solution (see below).
By the way, if Symbolics NFS is supposed to be compatible with GNU Emacs's
versioning convention, how come it doesn't create "foo~" files? It goes
straight from "foo" to "foo.~version~". This is a pretty annoying
Sounds like a bug to me. You should report it separately, if you have
that case, you are pretty much stuck with Unix's limitations. If you
don't need the Unix interoperability, then creating a LMFS partition is
Unix systems are generally better file servers than Lispms are. Fsck is
infinitely faster than the LMFS salvager, and Unix is able to use alternate
tracks automatically. Performance on Unix systems with many disks can be
better because most Unix systems support multiple disk controllers, which
can be operated concurrently.
And you don't have to teach your sysop how to backup a LMFS, etc.
The *only* advantage of Lispm file servers is the additional file
attributes and the user-extensible property list.
There might be others, like maybe file versioning? Unix is great too,
but it ain't perfect, either.
As KMP pointed out in a separate message, a better approach would be to
campaign to add the needed functionality to Unix directly rather than
kludge it on the side. That's not really our place, except as Unix
We have considered abandoning LMFS in favor of NFS, but missing features
such as those we are discussing make it difficult. (Clearly an
advantage would be that we could devote more resources to improving NFS
perfomance of our machines if we did not have a proprietary file system
to maintain also.)