[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
    From: barmar@Think.COM

       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~

Not GNUEmacs?
	       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
not already.
       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
       the solution.

    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.)