From: Maneesh Soni <maneesh@in.ibm.com>
To: "Peter J. Braam" <braam@clusterfs.com>
Cc: torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
"'Phil Schwan'" <phil@clusterfs.com>
Subject: Re: [PATCH/RFC] Lustre VFS patch
Date: Fri, 28 May 2004 18:18:08 -0500 [thread overview]
Message-ID: <20040528231808.GA13711@in.ibm.com> (raw)
In-Reply-To: <20040524114009.96CE13100E2@moraine.clusterfs.com>
Hi Peter,
I have some questions about the revalidate_special.
In case of "." we do revalidate_special() which calls real_lookup(),
which can create a negative dentry, if "." is unhashed, and return
no error. After that we don;t have any check for negative dentry
in link_path_walk. The result could be we return success
from link_path_walk() with a negative dentry. And I think it is
bad.
Maneesh
On Mon, May 24, 2004 at 07:39:50PM +0800, Peter J. Braam wrote:
> Hi Linus, Andrew & others,
>
> Many people have asked me to have this patched reviewed, and
> considered for inclusion in 2.6 after some reworking. At the kernel
> summit last summer we discussed these issues.
>
> This patch is not the Lustre file system, with client file system,
> Lustre RPC, server code etc. This patch would enable people to run
> Lustre with modules loading into unmodified kernels and this appears
> to be something vendors really would like to see. FYI, at the moment
> Lustre is a just a little bit larger than NFS, comparing clients,
> servers, and rpc code for each (60K vs 80K lines of code).
>
> This patch was written quite defensively: file systems not using
> intents should really be completely unaffected.
>
> I attach a little tar ball with patches and a series file which
> describes the order of the patches. Below is a short description of
> each of the patches. I also want to tell you a few things we have
> worked on that are not present in this patch:
>
> - deal with "pinning" directories that are CWD or mount points. They
> should not be removable/unlinkable by remote nodes, and the FS needs
> some indication of that.
>
> - in Lustre d_parent is not necessarily valid, so sys_getcwd needs to
> be careful. In Ottawa we discussed adding an optional hook.
>
> - changes to NFSD to allow it to run on top of Lustre
>
> - per file system locking operations (refinining i_sem) to allow
> parallel updates in one directory.
>
> It goes without saying that many people in CFS have made contributions
> to this patch and that the ideas were heavily influenced by discussions
> with the kernel community.
>
> Please give me your thoughts about how we can move forward with this.
>
> Regards,
>
> - Peter -
>
>
> dev_read_only-vanilla-2.6.patch
>
> This introduces an ioctl on block devices to stop doing I/O. The
> only purpose of the patch is automated recovery regression testing,
> it is very convenient to have this available.
>
> export-vanilla-2.6.patch
>
> Export symbols used by Lustre.
>
> header_guards-vanilla-2.6.patch
>
> Small bug fix to avoid double inclusion of headers
>
> lustre_version.patch
>
> A tiny header to check that the kernel patch and Lustre modules are
> compatible.
>
> vfs-dcache_locking-vanilla-2.6.patch
>
> A trivial patch to make functions available to lustre that do
> d_move, d_rehash, without taking/dropping the dcache lock.
>
> vfs-dcache_lustre_invalid-vanilla-2.6.patch
>
> This allows dentries to be d_invalidate'd if a bit is set in the
> FLAGS. This is required when dentries that are busy on the local
> node are invalidated on another client system.
>
> vfs-intent_api-vanilla-2.6.patch
>
> Introduce intents for other operations. Add a file system hook to
> release intent data. Make a few "intent versions" of functions such
> as "lookup_one_len_it" and "user_walk_it" available through headers.
> Arrange that the open intent is visible in the open methods. Add a
> few missing intent_init calls.
>
> vfs-intent_exec-vanilla-2.6.patch
>
> Add intents for open in the context of execution.
>
> vfs-intent_init-vanilla-2.6.patch
>
> Add intent_init for all operations, not just for open.
>
> vfs-intent_lustre-vanilla-2.6.patch
>
> Add a pointer to per fs intent_data structure to the struct lookup_intent.
>
> vfs-raw_ops-vanilla-2.6.patch
>
> This adds raw operations for setattr, mkdir, rmdir, mknod, unlink,
> symlink, link and rename. The raw operations look up the parent
> directories (but not leaf nodes) involved in the operation and then
> ask the file system to execute the operation. These methods allow
> us to delegate the execution of these functions to the server, and
> instantiate no dentries for leaf nodes, leaf nodes will only enter
> the dcache on subsequent lookups. This patch dramatically
> simplifies the client/server lock management, particularly for
> rename.
>
> In Ottawa Linus suggested that we could maybe do this with intents
> instead. I feel that both are ugly, both are possible but intents
> looked akward.
>
> vfs-revalidate_counter-vanilla-2.6.patch
>
> We found that dentries could be invalidated multiple times through
> activity on remote nodes, but this shoudl not lead to failure in
> Lustre. The revalidation path real_lookup was adapted to take a few
> more iterations through the revalidation before giving up. This
> revalidation takes the form of first revalidating, then looking up
> if it fails, and possibly revalidating a few more times (see above)
> until there is success.
>
> vfs-revalidate_special-vanilla-2.6.patch
>
>
> We add nameidata flags to indicate that a link sits in the middle of
> the path and a flag that inidicates we are looking at the last
> component of a path. [If someone knows if the existing flags could
> detect this, that would be welcome.] To pass intents when the last
> pathname component is a "." we insert a "special" revalidation
> function that calls revalidate dentry when such a pathname is
> traversed.
>
> vfs_intent-flags_rename-vanilla-2.6.patch
>
> As Linus requested in Ottawa last summer, rename intent.open.flags
> to intent. it_flags and intent.open.create_mode to
> intent.it_create_mode. Remove the union of "intents", which only
> contained an open_intent, and replace it with a single struct
> lookup_intent included in the nameidata.
>
> vfs-do_truncate.patch
>
> We added a parameter to do_truncate so that the FS can now if it is
> being called from open or not.
>
--
Maneesh Soni
Linux Technology Center,
IBM Software Lab, Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044999 Fax: 91-80-25268553
T/L : 9243696
next prev parent reply other threads:[~2004-05-28 23:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 11:39 [PATCH/RFC] Lustre VFS patch Peter J. Braam
2004-05-24 11:46 ` Jens Axboe
2004-05-25 1:48 ` braam
2004-05-25 6:47 ` Jens Axboe
2004-05-25 8:21 ` braam
2004-05-25 8:27 ` Jens Axboe
2004-05-25 10:52 ` Lars Marowsky-Bree
2004-05-25 11:45 ` braam
2004-05-25 13:35 ` Kevin Corry
2004-05-25 13:55 ` Jens Axboe
2004-05-24 12:00 ` hch
2004-05-24 12:01 ` hch
2004-05-24 12:03 ` hch
2004-05-24 15:33 ` Horst von Brand
2004-05-25 20:43 ` hch
2004-05-24 12:05 ` hch
2004-05-24 18:06 ` Trond Myklebust
2004-05-25 8:21 ` braam
2004-05-24 12:08 ` hch
2004-05-24 13:44 ` Arjan van de Ven
2004-05-24 13:53 ` viro
2004-05-28 16:56 ` braam
2004-05-28 17:00 ` Christoph Hellwig
2004-05-24 14:19 ` viro
2004-05-28 23:18 ` Maneesh Soni [this message]
2004-05-29 17:53 ` Anton Blanchard
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=20040528231808.GA13711@in.ibm.com \
--to=maneesh@in.ibm.com \
--cc=akpm@osdl.org \
--cc=braam@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phil@clusterfs.com \
--cc=torvalds@osdl.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.