Ah yes, I thought that might be useful.  Similarly if you wanted to do
setattr with an intent you'd need a pointer to iattr's to do so.

- Peter -

On Tue, Oct 15, 2002 at 11:58:00AM -0400, William A.(Andy) Adamson wrote:

hi peter

i've looked over your patch WRT NFSv4 open semantics. for regular files, the 
NFSv4 open combines lookup, open, and create. this means that we need both the 
mode and the open flags to satisfy the OPEN operation, which we would 
implement in the nfsv4 version of lookup2. as i follow the code path in your 
patch:

filp_open -> open_namei_it which receives both the mode and the open flags. 
but then the open flags are lost in the call to path_lookup_it, which 
translates the open flags into lookup_flags. so, if i'm reading the code 
correctly, NFSv4 would require another field in the intent struct to hold the 
open flags.

-->Andy

quoted

Hi Al,

Attached is a 2.4 patch for lookup intents, which we use with Lustre.
This patch adds a lookup2, revalidate2 and intent_release method.
None of those are required if the kernel changes the parameters
globally, but I wanted to keep things simple.

The purpose of the patch is to give the lookup call sufficient
information about the "intent" of the lookup.  Intents can be tags
like "a create/open is coming".  With the intent patch, distributed
O_EXCL problems, from which NFS suffers too, are easily addressed.
For Lustre, which runs on 1,000+ node clusters, reducing file system
transactions to a single RPC from ->lookup is the core benefit.  For
InterMezzo the intent opens the opportunity to refresh the cache
before the ->create/mkdir etc methods lock anything, which is very
beneficial.  This is much along the lines of what we discussed over
the last year and a bit.

We would like to submit something like this for 2.5, for use with
Lustre and InterMezzo. 

The 2.5 patch is similar, but in 2.5 the struct intent is conveniently
embedded in the struct nameidata making things quite a bit simpler.
Intent_release is done as part of releasing the nameidata and still
requires a new dentry method.  We will send you this patch in a few
days time.

However, I suspect that after you review this you might come up with
an equivalent but better way of doing this.  Particularly interesting
to us is how the d_it field we added to the dentry can be protected
between the return from lookup and the use of that field in
->create/mkdir etc.  We do that with a semaphore (which we placed
under d_fsdata); alternatives are passing the nameidata or intent to
every inode operation that requires the intent.

Best wishes,

- Peter -

- Peter -