[lkml]   [2008]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 00/13] vfs: add helpers to check r/o bind mounts
    In message <>, Al Viro writes:
    > On Thu, Apr 24, 2008 at 01:25:58PM -0400, Erez Zadok wrote:
    > > Al, any near-term plans for sb-level "want write" locking as we discussed
    > > briefly at LSF? Being able to do so for copyup in unionfs will hopefully
    > > allow me to prevent concurrent topology changes.
    > That's pretty close to the top.
    > > the two directories that need locking. This rename-locking protocol appears
    > > to be a special case of the sb-level "want write" idea, right?
    > Not really - that one doesn't provide any exclusion between writers and
    > that's what we want from rename/rename.

    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?

    > Take a look at Documentation/filesystems/directory-locking for details
    > of locking scheme...

    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.


     \ /
      Last update: 2008-04-24 21:59    [W:0.021 / U:19.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site