[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C7486F4.3080702@ontolinux.com>
Date: Wed, 25 Aug 2010 04:59:01 +0200
From: Christian Stroetmann <stroetmann@...olinux.com>
To: Valerie Aurora <vaurora@...hat.com>
CC: "J. R. Okajima" <hooanon05@...oo.co.jp>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 14/39] union-mount: Union mounts documentation
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists