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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox