Re: Lookup intents

Re: Lookup intents

[Trond Myklebust]

>>>>> " " == Steve French <smfltc@us.ibm.com> writes:

     > Any ideas on the best way with the new lookup/create intents
     > that Trond added to 2.5 recently to save away a network file
     > handle?  There is no file struct to put them in at the time of
     > create, so they could either be stored in a linked list off the
     > inode or a new field could be added to the intent to store fs
     > specific info for the operation (in this case the 32 bit
     > network file handle).  I noticed that the older intents patch
     > had a much bigger intents structure in the nameidata struct.

I was thinking of adding in a 'private data' field into the nameidata
(together with an associated 'destroy' method). In the end I found I
didn't need one for NFS. Adding it in is fairly trivial though...

Do you need to pass that file handle on to the struct file? If so then
the most obvious solution would be to pass the same nameidata down as
an argument to the open() method.
It's a lot of work to chase down all those open() calls littered
around the kernel, but...

Cheers,
  Trond

Re: Lookup intents

[Steve French (IBM LTC)]

A private data field in nameidata would work but would require adding a
new parm to
open (which as you note is painful).   Probably a better solution would be
for me to add
a "pending create" linked list off the struct cifsInodeInfo for that
inode.   I would have to store
network file id, pid and open flags - As long as the pid & open flags
(saved at cifs_create)
are found to match later by cifs_open I can put the netfid from the
pending create entry in my file struct
(which will make my cifs_open code a lot faster since another network open

will not have to be issued to get the network fid).

This makes a couple of assumptions though - 1) that the


Trond Myklebust wrote:

> >>>>> " " == Steve French <smfltc@us.ibm.com> writes:
>
>      > Any ideas on the best way with the new lookup/create intents
>      > that Trond added to 2.5 recently to save away a network file
>      > handle?  There is no file struct to put them in at the time of
>      > create, so they could either be stored in a linked list off the
>      > inode or a new field could be added to the intent to store fs
>      > specific info for the operation (in this case the 32 bit
>      > network file handle).  I noticed that the older intents patch
>      > had a much bigger intents structure in the nameidata struct.
>
> I was thinking of adding in a 'private data' field into the nameidata
> (together with an associated 'destroy' method). In the end I found I
> didn't need one for NFS. Adding it in is fairly trivial though...
>
> Do you need to pass that file handle on to the struct file? If so then
> the most obvious solution would be to pass the same nameidata down as
> an argument to the open() method.
> It's a lot of work to chase down all those open() calls littered
> around the kernel, but...
>
> Cheers,
>   Trond

Re: Lookup intents

[Andreas Dilger]

On Jul 11, 2003  01:15 +0200, Trond Myklebust wrote:
> >>>>> " " == Steve French <smfltc@us.ibm.com> writes:
>      > Any ideas on the best way with the new lookup/create intents
>      > that Trond added to 2.5 recently to save away a network file
>      > handle?  There is no file struct to put them in at the time of
>      > create, so they could either be stored in a linked list off the
>      > inode or a new field could be added to the intent to store fs
>      > specific info for the operation (in this case the 32 bit
>      > network file handle).  I noticed that the older intents patch
>      > had a much bigger intents structure in the nameidata struct.
> 
> I was thinking of adding in a 'private data' field into the nameidata
> (together with an associated 'destroy' method). In the end I found I
> didn't need one for NFS. Adding it in is fairly trivial though...
> 
> Do you need to pass that file handle on to the struct file? If so then
> the most obvious solution would be to pass the same nameidata down as
> an argument to the open() method.
> It's a lot of work to chase down all those open() calls littered
> around the kernel, but...

This is exactly what we do in our 2.5 patches now - putting the intent
data into the nameidata struct.  I think the only API change we made
was to vfs_create_it() to pass the nameidata struct in, and dentry_open_nd().

I'm not working on the 2.5 lustre code myself, but I believe that the 2.5
patch is basically ready to go.  I'll CC Peter to see if he has comments
on the status of the current patch, which is at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/lustre/lustre/kernel_patches/patches/Attic/vfs_intent_2.5.72_rev1.patch.keep?rev=1.1.2.1&only_with_tag=b_ad

URL is for reference only, as I don't know if it is ready for submission.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Lookup intents

[Trond Myklebust]

>>>>> " " == Andreas Dilger <adilger@clusterfs.com> writes:

     > I'm not working on the 2.5 lustre code myself, but I believe
     > that the 2.5 patch is basically ready to go.  I'll CC Peter to
     > see if he has comments on the status of the current patch,

I did of course correspond with Peter prior to submitting my intent
patches. At the time he said he felt he wasn't ready to merge the full
Lustre code, and so we agreed to submit my (more limited) patches as a
stopgap measure.

The Lustre intent patches do indeed feed intent data down as a special
field in the 'struct file'. However that field can only be used at
initialization (it is undefined after the ->open() method is done) so
it's really just a way of hacking around the need for the extra open()
parameter ;-)

Cheers,
  Trond

Lookup intents

[Steve French]

Any ideas on the best way with the new lookup/create intents that Trond
added to 2.5 recently to save away a network file handle?   There is no
file struct to put them in at the time of create, so they could either
be stored in a linked list off the inode or a new field could be added
to the intent to store fs specific info for the operation (in this case
the 32 bit network file handle).  I noticed that the older intents patch
had a much bigger intents structure in the nameidata struct.

I also will test an alternate approach, which might not work - when 
cifs_create is called indirectly from sys_create (or equivalent) return
success immediately on the create (without doing anything) and do the
actual create on open (saving an opencreate since for cifs the create
call opens the file might as well send one operation instead of four).
For the case of cifs_create called from sys_mknod actually do a create &
close (since sys_mknod does not return an open file).