| |||||||||||||
puzzledpuzzledPosted Sep 2, 2004 15:52 UTC (Thu) by fergal (subscriber, #602)Parent article: More notes on reiser4 Why is it that the first example here is a problem but the other 2 arent't?
(Log in to post comments)
puzzled Posted Sep 2, 2004 16:27 UTC (Thu) by RobSeace (subscriber, #4435) [Link] Well, I don't pretend to know much about kernel internals, but I would assumethe reason your case #2 isn't a problem is because the files canonicalize to the same exact pathnames in both processes, and presumably there must be some kernel-level synchronization of such things as renaming, based on the pathnames... So, basically, either one or the other of those processes will succeed, and the second will fail, because the target director no longer exists at that point, because the first process beat it to the punch... But, as I understand it, the issue with the arbitrarily-named hard-links is that there's no way to recognize that "a/dir1" is the exact same thing as "b/dir1", and hence no way to possibly synchronize these things, and prevent them from clashing with each other... And, as such, I would think your example #3 is also a problem...
Re: puzzled Posted Sep 2, 2004 17:23 UTC (Thu) by larryr (guest, #4030) [Link] I think maybe the problem is that unix style filesystem semantics assume a tree structure, meaning one parent edge/entry for each vertex/node, but having a hard link to a directory violates that assumption. I think if it was considered typical for a directory to have multiple parent pointers, and there were consistent conventions for performing atomic locking on all the parents of a directory at once, there might be no problem. But if "the parent" of a node is assumed by the implementation to be "the node corresponding to the path component to the left of the path component referencing this node", locking "the parent" of "/x/a/dir1" could be different from locking "the parent" of "/x/b/dir1". Larry
Re: puzzled Posted Sep 3, 2004 1:57 UTC (Fri) by vonbrand (subscriber, #4458) [Link] No, the problem is precisely that if a diretory has several parents, you need to make sure nobody messes around with one of the paths while you are screwing up another one. For that you'd have to be able to find all parents and lock them before doing anything... and that will have a heavy cost if done naïvely. Al (and Linus) is asking how do they solve these problems. If the ReiserFS guys have good answers, symlinks (as second-class citizens) could be on the way out. I for one doubt they have the answers (or are able to come up with them). Time will tell.
Re: puzzled Posted Sep 3, 2004 15:36 UTC (Fri) by larryr (guest, #4030) [Link] No, the problem is precisely that if a diretory has several parents[... ]you'd have to be able to find all parents and lock them before doing anything... and that will have a heavy cost if done naïvely. I wrote: if it was considered typical for a directory to have multiple parent pointers, and there were consistent conventions for performing atomic locking on all the parents of a directory at once, there might be no problem. Larry
|
|||||||||||||