Re: [PATCH 14/39] union-mount: Union mounts documentation

[Valerie Aurora]

On Tue, Aug 24, 2010 at 11:28:37AM +0900, J. R. Okajima wrote:
> 
> Thank you for explanation, very much.

You are welcome!

> When a rename happens on a layer directly, aufs receives a
> inotify/fsnotify event. Following the event type, aufs makes the cached
> dentry/inode obsoleted and they will be lookup-ed again in the
> succeeding access. Finally aufs will know the upper parent_dir1 is not
> covering the lower parent_dir2 anymore.
> This notification is the main purpose of the strict option which is
> called "udba=notify" (User's Direct Branch Access).

No, that's not a sufficient description and leaves open questions
about all sorts of deadlocks and race conditions.  For example,
inotify events occur while holding locks only on one layer.  You
obviously need to lock the top layer to update the inheritance and
parent-child relationships.  Now you are locking the lower layer first
and the top layer second, which is the reverse of the usual order.
Also, it should not be an option.

If Al Viro says it's wrong, you need a very detailed explanation of
why it is right.  See Documentation/filesystem/directory-locking for
an example of the argument you have to make to show that moving things
around on the lower layer is safe.  In general, your first task is to
show a global lock ordering to prove lack of deadlocks (which I don't
think you should spend time on because most VFS experts think it is
impossible to do with two read-write layers).

I'm not going to explain any more how aufs is wrong; it's the
maintainer's job to convince Al Viro and other maintainers that aufs
is right.  But I hope this gave you a start and showed why union
mounts is a preferred approach for many people.

Thanks,

-VAL
--
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/