From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Valerie Aurora <vaurora@redhat.com>
Cc: "J. R. Okajima" <hooanon05@yahoo.co.jp>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 14/39] union-mount: Union mounts documentation
Date: Wed, 25 Aug 2010 04:59:01 +0200 [thread overview]
Message-ID: <4C7486F4.3080702@ontolinux.com> (raw)
In-Reply-To: <20100824204839.GB28718@shell>
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
next prev parent reply other threads:[~2010-08-25 2:58 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-08 15:52 [PATCH 00/39] Union mounts - return d_ino from lower fs Valerie Aurora
2010-08-08 15:52 ` [PATCH 01/39] VFS: Comment follow_mount() and friends Valerie Aurora
2010-08-08 15:52 ` [PATCH 02/39] VFS: Make lookup_hash() return a struct path Valerie Aurora
2010-08-08 15:52 ` [PATCH 03/39] VFS: Add read-only users count to superblock Valerie Aurora
2010-08-08 15:52 ` [PATCH 04/39] autofs4: Save autofs trigger's vfsmount in super block info Valerie Aurora
2010-08-08 15:52 ` [PATCH 05/39] whiteout/NFSD: Don't return information about whiteouts to userspace Valerie Aurora
2010-08-08 15:52 ` [PATCH 06/39] whiteout: Add vfs_whiteout() and whiteout inode operation Valerie Aurora
2010-08-08 15:52 ` [PATCH 07/39] whiteout: Set opaque flag if new directory was previously a whiteout Valerie Aurora
2010-08-08 15:52 ` [PATCH 08/39] whiteout: Allow removal of a directory with whiteouts Valerie Aurora
2010-08-08 15:52 ` [PATCH 09/39] whiteout: tmpfs whiteout support Valerie Aurora
2010-08-08 15:52 ` [PATCH 10/39] whiteout: Split of ext2_append_link() from ext2_add_link() Valerie Aurora
2010-08-08 15:52 ` [PATCH 11/39] whiteout: ext2 whiteout support Valerie Aurora
2010-08-08 15:52 ` [PATCH 12/39] whiteout: jffs2 " Valerie Aurora
2010-08-08 15:52 ` [PATCH 13/39] fallthru: Basic fallthru definitions Valerie Aurora
2010-08-08 15:52 ` [PATCH 14/39] union-mount: Union mounts documentation Valerie Aurora
2010-08-09 22:56 ` Neil Brown
2010-08-11 1:51 ` J. R. Okajima
2010-08-17 20:44 ` Valerie Aurora
2010-08-17 22:53 ` Neil Brown
2010-08-18 0:15 ` Luca Barbieri
2010-08-18 19:04 ` Valerie Aurora
2010-08-18 1:23 ` J. R. Okajima
2010-08-18 18:55 ` Valerie Aurora
2010-08-19 1:34 ` J. R. Okajima
2010-08-24 0:05 ` Valerie Aurora
2010-08-24 2:28 ` J. R. Okajima
2010-08-24 20:48 ` Valerie Aurora
2010-08-25 2:59 ` Christian Stroetmann [this message]
2010-08-25 5:03 ` J. R. Okajima
2010-08-08 15:52 ` [PATCH 15/39] union-mount: Introduce MNT_UNION and MS_UNION flags Valerie Aurora
2010-08-08 15:52 ` [PATCH 16/39] union-mount: Introduce union_dir structure and basic operations Valerie Aurora
2010-08-08 15:52 ` [PATCH 17/39] union-mount: Free union dirs on removal from dcache Valerie Aurora
2010-08-08 15:52 ` [PATCH 18/39] union-mount: Support for union mounting file systems Valerie Aurora
2010-08-08 15:52 ` [PATCH 19/39] union-mount: Implement union lookup Valerie Aurora
2010-08-13 13:49 ` Miklos Szeredi
2010-08-17 21:44 ` Valerie Aurora
2010-08-18 8:11 ` Miklos Szeredi
2010-08-08 15:52 ` [PATCH 20/39] union-mount: Call do_whiteout() on unlink and rmdir in unions Valerie Aurora
2010-08-08 15:52 ` [PATCH 21/39] union-mount: Copy up directory entries on first readdir() Valerie Aurora
2010-08-08 15:52 ` [PATCH 22/39] union-mount: Add generic_readdir_fallthru() helper Valerie Aurora
2010-08-08 15:52 ` [PATCH 23/39] fallthru: ext2 fallthru support Valerie Aurora
2010-08-13 13:52 ` Miklos Szeredi
2010-08-17 21:08 ` Valerie Aurora
2010-08-17 22:28 ` Valerie Aurora
2010-08-08 15:52 ` [PATCH 24/39] fallthru: jffs2 " Valerie Aurora
2010-08-08 15:52 ` [PATCH 25/39] fallthru: tmpfs " Valerie Aurora
2010-08-08 15:52 ` [PATCH 26/39] VFS: Split inode_permission() and create path_permission() Valerie Aurora
2010-08-08 15:52 ` [PATCH 27/39] VFS: Create user_path_nd() to lookup both parent and target Valerie Aurora
2010-08-08 15:52 ` [PATCH 28/39] union-mount: In-kernel file copyup routines Valerie Aurora
2010-08-08 15:52 ` [PATCH 29/39] union-mount: Implement union-aware access()/faccessat() Valerie Aurora
2010-08-08 15:52 ` [PATCH 30/39] union-mount: Implement union-aware link() Valerie Aurora
2010-08-08 15:52 ` [PATCH 31/39] union-mount: Implement union-aware rename() Valerie Aurora
2010-08-08 15:52 ` [PATCH 32/39] union-mount: Implement union-aware writable open() Valerie Aurora
2010-08-08 15:52 ` [PATCH 33/39] union-mount: Implement union-aware chown() Valerie Aurora
2010-08-08 15:52 ` [PATCH 34/39] union-mount: Implement union-aware truncate() Valerie Aurora
2010-08-08 15:52 ` [PATCH 35/39] union-mount: Implement union-aware chmod()/fchmodat() Valerie Aurora
2010-08-08 15:52 ` [PATCH 36/39] union-mount: Implement union-aware lchown() Valerie Aurora
2010-08-08 15:52 ` [PATCH 37/39] union-mount: Implement union-aware utimensat() Valerie Aurora
2010-08-08 15:52 ` [PATCH 38/39] union-mount: Implement union-aware setxattr() Valerie Aurora
2010-08-08 15:52 ` [PATCH 39/39] union-mount: Implement union-aware lsetxattr() Valerie Aurora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C7486F4.3080702@ontolinux.com \
--to=stroetmann@ontolinux.com \
--cc=hch@infradead.org \
--cc=hooanon05@yahoo.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vaurora@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).