Jonathan Briggs wrote:
On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[email protected]> said:
[snip]
It still has the performance and locking problem of having to update
every child file when moving a directory tree to a new parent. On the
other hand, maybe the benefit is worth the cost.
Every node should store the inode number(s) for its parent(s). Not the
path name. So you don't need to do any updates, since when you move a
tree, inode numbers don't change.
You do need the updates if you change what inode is the parent.
/a/b/c, /a/b/d, /a/b/e, /b
mv /a/b /b
Now you have to change the stored grand-parent inodes for /a/b/c, /a/b/d
and /a/b/e so that they reference /b/b instead of /a/b.
no, c, d, and e all would reference /a/b's *inode*, not *pathname*.
Then /a/b would reference /a. So with the above mv, you just change the
reference in /a/b (now /b/b) to point to /b as parent.
Only way you would have to touch c, d, and e is if you did:
mkdir /b/b
mv /a/b/* /b/b/
but, since you're also essentially unlinking them from /a/b and linking
them into /b, it's not that much more of a performance hit to update one
pointer in the file.
-
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]
| |
 |