public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

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