Re: Hurd and Unix/Linux and Plan9 features

[Ivan Shmakov]

>>>>> "o" ==   <olafBuddenhagen@gmx.net> writes:

 S> * Also will it support hard links for directories?

 IS> This problem was discussed on the list some time ago.  My opinion
 IS> that it /shouldn't/ be done.  If one thinks of a directory as a
 IS> mapping of file names to actual file objects, and of hard links as
 IS> the alternate names to a file (directory) object, then it becomes
 IS> hard to decide, which file (directory) the `..' name is mapped to?

 o> Well, as you seem to have followed the ngHurd discussions, you
 o> should be aware that this has shown to be only one of the reasons
 o> why having ".."  links in the filesystem is a bad idea. ngHurd
 o> almost certainly won't have these, and in fact it might be changed
 o> in the existing implementation as well. So, this is not really a
 o> reason to avoid hardlinks to directories.

 o> In another discussion at a different place, someone pointed out that
 o> hardlinked directories are problematic, because this way loops are
 o> possible, and the filesystem would no longer be a directed graph. No
 o> idea whether this is a serious problem in practice.

        At a first glance, handling of such loops might be implemented
        in applications, so the kernel could provide hardlinks to
        directories with no harm.  However, the ``directed graph'' model
        is not just about making no loops: it demands the way to, given
        some directory, obtain its parent.

        Then, if a ``directory'' is thought about as a mapping of names
        to files (I mean not only regular files, but directories, pipes,
        etc.), then hardlinks to a directory is to be meant as a
        different names to the very same directory, so, e. g.:

$ mkdir a
$ ln a b
$ cat a/file
cat: a/file: No such file or directory
$ touch a/file
$ cat a/file
$ cat b/file
$ 

        Suppose a different scenario:

a/ $ mkdir b
a/ $ mkdir c
a/ $ ln b c/d
a/ $ cd c/d/
a/c/d/ $ cd ..

        Which path the last command would lead to, a/c/ (as a/c/d/../)
        or a/ (as a/b/../)?

        Should `..' entry be stored ``on disk'', the answer will
        probably be the same every time the entry is used, bringing,
        however, some confusion in how path names behave (in simple
        cases, `..' in path works essentially like an ``eraser'',
        removing a path component to the left.)

        If it's to be derived from the current working directory (in
        case of `cd'), the `..' sub-directories of `a/b/' and `a/c/d/'
        would, indeed, be different directories.  So the ``mappings''
        are, actually, different.  (This is how ``firmlinks''
        implemented in Hurd, IIUC.)

        Although I see no reason to deny such behaviour (either
        ``firmlinks'' or even ``no parent altogether''), my opinion is
        that it's sufficiently different to ``traditional'' FS.  Would
        there be any uses for it?  Wouldn't it make more sense to
        support, e. g., some kind of a relational data model with a
        separate interface?

 S> 2. Will it support the Linux LVM concept?

 IS> Looks like with HurdNG's ``space banks'', things would be even
 IS> better than with the Linux LVM.

 o> I think the space bank concept is rather orthogonal to partitions
 o> and LVM. Space banks are about allocating memory from the available
 o> stores, not about how stores are laid out on HD.

        Well, I have little knowledge of ``space banks''.  I know Linux
        LVM somewhat better.  In simple words, LVM allows one to:

        * create physical volumes out of disk partitions;

        * create volume groups out of one or more physical volumes;

        * allocate and deallocate memory of volume groups into logical
          volumes.

        From my point of view, volume group is essentially a such
        ``store'', from which I could allocate memory for whichever
        purposes I feel appropriate (swap space, news spool,
        filesystems, etc.)