The NFS issue was fixed by Tweedie earlier in this thread.
Hans
cbbrowne@godel.brownes.org writes:
> Hans Reiser wrote:
> > My point though is that the file system semantics have been static for
> > 20 years. It is time for them to change. When they change NFS will
> > break, at least it will if the changes are substantive. For this
> > reason, to argue that NFS cannot be broken is to argue that there should
> > be no semantic innovation for file systems. That make the argument
> > invalid in my eyes. NFS must be broken.
>
> It must be broken if the semantic innovation *requires* that NFS be broken.
>
> I'm not convinced that this is *necessarily* the case; suitable careful
> thinking may be able to provide an acceptable mapping of the new concepts
> onto the old representation.
>
> With the bad analogies running rampant, how about another:
> People trying to come up with new words don't usually look for the addition
> of new letters to the alphabet; they usually try to take combinations of the
> existing 26 (obviously I'm being Anglo-centric here!) and express new words
> and concepts using the existing linguistic tools.
>
> It's quite easy to make up some new notation that is incompatible with any
> existing one; the *clever* result is to come up with a way to map the new
> ideas onto the existing notations, and, more particularly, existing
> protocols.
>
> Furthermore, in order to ensure that people understand the new idea, this
> mapping is necessary in order to firmly establish both the similarities
> and the differences.
>
> The way I see it, what is desired is to be able to express hierarchies of
> data inside documents as components that look just like directories/files,
> with those "pseudo-files" treated by the FS as if they were files.
>
> A natural way to regard this is to start with the assumption that these
> "pseudo-files" and "pseudo-directories" REALLY ARE files/directories.
>
> I'm going to declare an example for illustrative purposes, and would
> suggest that it would be *REALLY* useful to have discussion surround
> such a "concrete" example. That way discussions of flaws may be very
> *precisely* pointed, establishing what is/is not possible.
>
> Assume a "compound document," /home/cbbrowne/mydoc.doc, which should
> contain the following six components:
> - contents.docbook
> - icon.jpeg
> - stylesheet.dsssl
> - "directory" called RCS
> - RCS/contents.docbook,v
> - RCS/stylesheet.dsssl,v
>
> The natural representation of this, without any special support would
> be to have:
> /home/cbbrowne/mydoc.doc/RCS/contents.docbook,v
> /home/cbbrowne/mydoc.doc/RCS/stylesheet.dsssl,v
> /home/cbbrowne/mydoc.doc/contents.docbook
> /home/cbbrowne/mydoc.doc/icon.jpeg
> /home/cbbrowne/mydoc.doc/stylesheet.dsssl
>
> And I believe that this is, pretty much, what most of the approaches that
> have been discussed would like to have as the "physical" representation.
> By using this representation, e2fsck, reiserfsck, or whatever other
> equivalent may be used to fix problems.
>
> At the "physical" level, opening the "contents.docbook" fork would, *by
> some means,* involve a call that would map (extra parameters ignored)
> to fopen("/home/cbbrowne/mydoc.doc/contents.docbook").
>
> We all know that directory hierarchies handle this nicely as-is; if
> this was all we wanted, the task is complete; we need only tell the
> programmers and users to have "documents" be represented as directories
> full of files. Personally, I think that idea has some merit.
>
> BUT. The other thing that mandates adding *some* form of additional
> functionality is the fact that we would *also* like to have a "view" of
> this where /home/cbbrowne/mydoc.doc may be regarded as a ordinary file,
> in effect, as a "stream of data/bag of bytes," which can be compressed,
> copied somewhere, moved somewhere, with all (or many of) the sorts of
> semantics that are associated with working with a file.
>
> In effect, we need to have some sort of "permeable barrier," some
> indicator which tells applications that, if they're not aware that
> this is supposed to be a directory hierarchy, this is "just another
> file."
>
> It's definitely nontrivial, since once serialized, the results may no
> longer be recognizable as a "forkable hierarchy."
>
> For instance, should we get the same results from:
>
> cp /home/cbbrowne/mydoc.doc ~/newdoc.doc
> and
> cat /home/cbbrowne/mydoc.doc > ~/newdoc.doc
>
> How does this relate to
> mv /home/cbbrowne/mydoc.doc ~/newdoc.doc
>
> "How should these things work?" is a good question to ask, and the
> cp-versus-cat issue is fairly different from what has been discussed
> thus far.
>
> The "fighting" has involved a yes/no "duel" for different answers
> to the following question:
>
> "Can this work over NFS? Or Coda? Or Samba? Or does it instead
> *invalidate* all existing network filesystem protocols, and mandate
> creating all new protocols with new user interfaces?"
>
> I find it pretty unacceptable to assert that it is *forceably* necessary
> to replace existing protocols when it has not been *clearly* established
> that this is absolutely necessary by showing that NFS fundamentally does
> not allow suitable semantics for expressing the namespace.
>
> There may be a suitable isomorphism that allows the functionality to indeed
> be mapped onto NFS (and thereby onto various other networked FSes). Or
> there may be some fairly small common extension which is sufficient.
>
> Ted T'so's idea of adding an extra library into the "stack" was an
> interesting proposal of such an extension; I rather think that other
> extensions should be proposed before it is assumed that more sweeping
> changes need to be made.
> --
> Christopher B. Browne, cbbrowne@hex.net, chris_browne@sabre.com
> Web: http://www.ntlug.org/~cbbrowne SAP Basis Consultant, UNIX Guy
> Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/