Re: reiser4 plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Neil Brown wrote:

On Tuesday July 5, [email protected] 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>
have you read Giampaolo's BeFS design book? he talks (ch 11) about this big argument they had at Be about how their API would let programs store references to files. the macintosh people wanted to have the program store an inode number, and the posix guys wanted it to store a path. in my mind, the only reason posix is right on this is because it allows hard links AND symlinks as a way of giving a choice in the matter, since hard links increment the reference count and softlinks don't. it seems much *more* important to be able to have this choice for file attributes than for the traditional posix namespace.

as an example, if a program were to store some things it needs access to in its executable's attributes, it should have the option of keeping a hard reference to something, so that it can't be deleted out from underneath. this enables sane sharing of resources without ownership tracking problems (see windows DLL hell for details). the attribute space should be indistinguishable from the rest of the namespace, and should be able to link (soft or hard) anywhere in the FS. anything less is too much work for too little reward.

NATE

NeilBrown



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux