Aloha Everybody;
On the 24.08.2010 22:48, Valerie Aurora wrote:
On Tue, Aug 24, 2010 at 11:28:37AM +0900, J. R. Okajima wrote:
Thank you for explanation, very much.
Me too
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).
This all reminds me of the 5/dining philosophers problem and its
solutions, especially the waiter and the resource hierarchy solutions
(see [1]).
And I do think that such problems can always be solved in a real world
context, but often the solutions are very time and/or space consuming.
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
[1] http://en.wikipedia.org/wiki/Dining_philosophers_problem
Have fun
Christian
--
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
