Lispm vs Unix file servers

[REti@Riverside.SCRC.Symbolics.COM]

    Date: Thu, 9 Aug 90 12:25 EDT
    From: PTW@JASPER.SCRC.Symbolics.COM (P. T. Withington)

    [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~
	suffixes.  

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

    Sounds like a bug to me.  You should report it separately, if you have
    not already.
									     In
	   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.
Also file robustness.  LMFS has never to my knowledge given out wrong data
bits as correct (because of its checkwords in every block), but several Unices
have done that to me.  Also, recently a large file server developed a problem
on one of its disks that it would return different disk blocks upon reading
than it was asked for.  This would have turned a Unix file system into mush,
LMFS survived quite nicely, thank you.

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

    ---

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