Michal Suchanek <hramrach@xxxxxxxxxx> writes: > On 15 June 2011 18:14, J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote: >> For example, in rename(2) dir where the target dir already existed, aufs >> renames the target dir to a temporary unique whiteouted name before the > > This is generally not possible in solutions that don't reserve any filenames. > > However, it should be possible to create whiteout of a non-existent > entry in a directory while it is locked without affecting userspace. Yes, creation of whiteout and renaming it to target or vice versa works if target is non-directory. Cases where this trick could make operations atomic: - create/mknod/symlink/link over whiteout - rename non-directory to whiteout - remove of non-directory with whiteout creation - copy up Cases where atomicity is not possible with this: - mkdir over whiteout - rename directory to whiteout - rename where source needs whiteout - rmdir with whiteout creation >> actual rename on a branch and then handles other actions (make it opaque, >> update the attributes, etc). If an error happens in these actions, aufs >> simply renames the whiteouted name back and returns an error. If all are >> succeeded, aufs registers a function to remove the whiteouted unique >> temporary name completely and asynchronously to the system global >> workqueue. > > Removing the whiteout asynchronously does not seem like a good idea. > It should be gone before the directory containing the whiteout is > unlocked. Otherwise there might be an entry created which conflicts > with this whiteout that did not exist when the operation started. Also > if you unlock the directory while the artifical whiteout exists an > asynchronous process might replace the whiteout and the rollback would > fail. > > As an alternative way to perform atomic renames I would suggest > "fallthrough symlinks". If you want to rename an entry which is > "fallthrough" (ie pointing to the entry with the same name in the > lower layer in the same directory) you can replace it with a > "fallthrough symlink" which points to the lower layer and does not > just implicitly say "here" but specifies a path relative to the > mountpoint instead. This can then be moved like any other entry. it is > in no way special anymore. This is a nice idea, but doesn't have a lot to do with atomicity. It allows rename of non-pure upper directory (they return EXDEV currently). > Moving a directory tree which is partially > in the upper layer is still time-consuming but can be performed with > reasonable semantics imho. Shouldn't be time consuming, really. The upper, mixed directory is renamed and given a "trusted.overlay.redirect" attribute to show where its lower directory resides. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
