In message <20080424173013.GA5882@ZenIV.linux.org.uk>, Al Viro writes:
When you say "that one", do you mean the sb-level idea? If the sb-level
"want write" not provide exclusion among writers, then how can I prevent
lower topology changes while copyup takes place?
If your sb-level "want write" idea won't provide that exclusion at the sb
level, then how about we elevate the s_vfs_rename_mutex into a generic
s_vfs_multi_dir_change_mutex of sorts, which can be used by rename as well
as copyup?
OK. lock_rename() at most locks one "parent" and one "child" inodes. So
what happens to all the ones in b/t? Suppose I have a path /a/b/c/d/e/f and
someone wants to mv /a/b/c/d/e to /a/b/; in that case lock_rename at least
grabs the mutex on /a/b, right? Can someone go in the middle and try to
muck with the "c/d/" parts in between?
From what I gathered, lock_rename won't be enough for me to prevent topology
changes during copyup; I'd really need to lock an entire arbitrarily deep
path of inodes. That just seems so complex and prone to bugs, that it might
just be easier to have a single sb-level mutex for these complex
multi-directory operations. I'm not sure how much performance hit this'd
be, thou, and if there's a more efficient way to do so.
If you think lock_rename will be sufficient for me to deal with copyups
vs. topology changes, then I'll start using it.
Thanks,
Erez.
--
