Re: reiser4 plugins

[Neil Brown <neilb@cse.unsw.edu.au>]

On Tuesday July 5, reiser@namesys.com wrote:
> I got it slightly wrong.
> 
> One can have hardlinks to a directory without cycles provided that one
> does not have hardlinks from the children of that directory to any file
> not a child of that directory.  (Mountpoints currently implement that
> restriction.)
> 
> Question: can one implement that lesser restriction above with elegant
> code?  Is the greater restriction below easier to code?  (If no to the
> first and yes to the second is correct, then I can accept the greater
> restriction described below.)

<technical-content>
I think the "lesser restriction above" can be implemented elegantly,
but it would require major dcache surgery.

Currently all the dentries of names in a directory are linked to the
dentry of the directory.  As you would have to let a directory have
multiple dentries, it would be best to change that linkage so that the
dentries of names in a directory were linked to the "inode" of that
directory (of which there is still only one).
Thus instead of just having a dentry tree with inodes attached at each
point, you would have a dentry/inode tree with inodes a more integral
part of the tree. (i.e. the path from the root down would be dentry ->
inode -> dentry ->inode -> dentry etc).
This would have major implications for the current code.

The "greater restriction below" should be easy to code providing you
were willing to have two sorts of directories: those which could be
linked (ie. they sometimes look like files) and those which cannot
(they never look like files).  Then for each dentry, you remember the
closest parent which is a can-be-linked directory an make sure a
hard-link will never want to change the can-be-linked directory for
the target.

If you want to be more general, and have only one sort of directory
that just behaves differently in different situations, then it would
be much harder.
You have to make sure both 
 a/ that you never hard link a file that is under a hard-linked
    directory to somewhere outside of that hard-linked directory and
 b/ that you never hard link a directory that contains a file which is
    hard-linked to somewhere outside that directory.

The first is probably quite manageable.  The second is essentially the
cycle-detection problem.

</technical-content>

<humour>
SUN used to advertise:
  "The network is the computer"
However I think we have all come to realise that the network is the
network, and the computer is the computer.

Now Hans wants to tells that
   "The directory is the file"

but I don't find it any more convincing than SUN's message...

</humour>

<opinion>
If you really want to change traditional Unix semantics, I would
suggest you get rid of hard-links.  They really are more trouble than
they are worth, and discarding them makes this whole issue moot.
</opinion>

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/