From: hooanon05@yahoo.co.jp
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC Aufs2 #5 28/29] export lookup functions
Date: Sat, 11 Apr 2009 01:47:15 +0900 [thread overview]
Message-ID: <7612.1239382035@jrobl> (raw)
In-Reply-To: <20090410162849.GA28377@infradead.org>
Christoph Hellwig:
> Strong NACK to all these exports, no one has any buesiness looking at
> these.
Will you tell me why?
If you have ever discussed exporting lookup_hash(), then please tell me
its URL or something.
lookup_hash is necessary for aufs since,
(from the mail "Subject: [RFC Aufs2 #5 01/29] aufs documents")
+Lookup in a Branch
+----------------------------------------------------------------------
+Since aufs has a character of sub-VFS (see Introduction), it operates
+lookup for branches as VFS does. It may be a heavy work. Generally
+speaking struct nameidata is a bigger structure and includes many
+information. But almost all lookup operation in aufs is the simplest
+case, ie. lookup only an entry directly connected to its parent. Digging
+down the directory hierarchy is unnecessary.
+
+VFS has a function lookup_one_len() for that use, but it is not usable
+for a branch filesystem which requires struct nameidata. So aufs
+implements a simple lookup wrapper function. When a branch filesystem
+allows NULL as nameidata, it calls lookup_one_len(). Otherwise it builds
+a simplest nameidata and calls lookup_hash().
+Here aufs applies "a principle in NFSD", ie. if the filesystem supports
+NFS-export, then it has to support NULL as a nameidata parameter for
+->create(), ->lookup() and ->d_revalidate(). So the lookup wrapper in
+aufs tests if ->s_export_op in the branch is NULL or not.
J. R. Okajima
next prev parent reply other threads:[~2009-04-10 16:48 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-10 7:02 [RFC Aufs2 #5 00/29] souce files J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 01/29] aufs documents J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 02/29] aufs module global J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 03/29] aufs super_block J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 04/29] aufs branch directory/filesystem J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 05/29] aufs xino J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 06/29] aufs object lifetime management via sysfs J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 07/29] aufs mount options/flags J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 08/29] aufs workqueue J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 09/29] aufs sub-VFS J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 10/29] aufs sub-dcache J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 11/29] aufs copy-up J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 12/29] aufs whiteout J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 13/29] aufs pseudo-link J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 14/29] aufs policies to select one among multiple writable branches J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 15/29] aufs dentry and lookup J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 16/29] aufs file J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 17/29] aufs direcotry J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 18/29] aufs inode J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 19/29] aufs ioctl J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 20/29] aufs sysfs entries J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 21/29] aufs debugfs entries J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 22/29] aufs branch for loopback block device J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 23/29] aufs internal inotify J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 24/29] aufs test for fstype J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 25/29] aufs debug J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 26/29] aufs public header file J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 27/29] export splice functions J. R. Okajima
2009-04-10 7:02 ` [RFC Aufs2 #5 28/29] export lookup functions J. R. Okajima
2009-04-10 16:28 ` Christoph Hellwig
2009-04-10 16:47 ` hooanon05 [this message]
2009-04-10 16:54 ` Christoph Hellwig
2009-04-10 17:03 ` hooanon05
2009-04-10 17:05 ` Christoph Hellwig
2009-04-10 17:26 ` hooanon05
2009-04-10 17:41 ` Christoph Hellwig
2009-04-10 7:02 ` [RFC Aufs2 #5 29/29] kbuild aufs J. R. Okajima
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=7612.1239382035@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.