Re: [PATCH 0/7] overlay filesystem: request for inclusion

[Miklos Szeredi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/