User: Password:
|
|
Subscribe / Log in / New account

puzzled

puzzled

Posted Sep 2, 2004 15:52 UTC (Thu) by fergal (guest, #602)
Parent article: More notes on reiser4

Why is it that the first example here is a problem but the other 2 arent't?

  • mv a/dir1 a/dir2/newdir	 	mv b/dir2 b/dir1/newdir
    
  • mv a/dir1 a/dir2/newdir	 	mv a/dir2 a/dir1/newdir
    
  • cd a                            cd b
    mv dir1 dir2/newdir	 	mv dir2 dir1/newdir
    


(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 assume
the 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 (guest, #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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds