[lkml]   [2011]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/7] overlay filesystem: request for inclusion

    Miklos Szeredi:
    > For example "rmdir /ovl/a/b" will do the following:
    > 1. find the underlying dentry for "a" -> upper-a
    > 2. lock upper-a
    > 3. find the underlying dentry for "b" -> upper-b
    > 4. verify that upper-b is a child of upper-a
    > 5. remove upper-b

    It is good to verify in step 4.
    Essentially (or ideally) this verification should be equivalent to all
    of what VFS does before vfs_rmdir(). I know overlayfs makes the upper
    mnt_want_write()-ed in early stage and keeps it. So it might be better
    to lookup again (as step 3 and 4) instead of comparing d_parent
    simply. If you think it is unnecessary to lookup here, then I'd suggest
    you to make it option (choosable by user).

    I see ovl_rmdir() does,
    - lookup and unlink all whiteouts
    - rmdir the target dir
    - create a whiteout for the target
    But I am afraid that any error can happen in every step on the upper
    dir. And if it happens, then ovl_rmdir() returns the error but the dir
    left in incomplete status. It may be one of these.
    - some whiteouts are unlinked but others are left
    - all whiteouts are gone but the target dir remains
    - the target dir is removed but the whiteout is not created
    Of course, it is bad and makes users really confused, since it will show
    users things which should not be. At the same time, I don't know how
    possible it can happen.

    Anyway if you have read aufs, then you would know how aufs solves these
    problems. I don't think the approaches in aufs is best or one and
    only. I just could not get another good idea.

    J. R. Okajima

     \ /
      Last update: 2011-06-15 16:35    [W:0.020 / U:3.636 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site