[pnfs] LAYOUTRECALL testing

[Iyer, Rahul]

Hi Guys,
I noticed another couple of things in the layoutrecall code...
1. There seems to be an XDR issue in the case of RECALL_FILE
2. There is a soft lockup bug in the code. The code for layoutrecall, in
the case of RECALL_FSID calls return_layout() while holding inode_lock.
Since return_layout makes a sync RPC, this probably put the thread to
sleep holding the inode lock, hence triggering this.

We can discuss this on Monday.
Regards
Rahul
 

> -----Original Message-----
> From: William A.(Andy) Adamson [mailto:andros at citi.umich.edu] 
> Sent: Friday, September 08, 2006 8:58 AM
> To: Iyer, Rahul
> Cc: pnfs at linux-nfs.org; andros at citi.umich.edu
> Subject: Re: [pnfs] LAYOUTRECALL testing 
> 
> > Hi,
> > 
> > I'm implementing a command on our Netapp filers to recall 
> layouts to a 
> > given file. However, I'm running into an issue. When the 
> LAYOUTRECALL 
> > rpc is issued, it returns with a status of 10001, or bad 
> file handle.
> > The filehandle however seems to be good because this is the 
> same file 
> > handle the client supplies in the GETFH operation in the LAYOUTGET 
> > compound.=20
> > 
> > When I traced this on the client, I realized that in 
> > nfs_layout_find_inode, the code doesn't enter either of the 
> > list_for_each_entry loops. Here's how I was testing the code
> > 
> > 1. copy a file via pNFS (You now have the layout)
> > 
> > 2. Issue the LAYOUTRECALL RPC
> > 
> > I'm guessing the reason for this is that the file is closed 
> at the end 
> > of the cp command, and so the file state is wiped out on the server.
> 
> i haven't lived in the client side state for a while - but i 
> note that nfs_layout_find_indde is looking for an inode in 
> the open_state list and when the last open on that file is 
> closed, the open_state gets freed (nfs4_put_open_state called 
> from nfs4_close_state). this of course does not mean that the 
> inode or layout is gone.
> 
> so, this is the wrong list to search for layouts which are 
> not tied to open/close. this points out the need for a layout 
> cache hashed independently from the NFSv4 open state.
> 
> note that delegations share this same feature, thus the 
> nfs4_client-> cl_delegations hash list.
> 
> > So,
> > nfs_layout_find_inode fails to find the inode. Is my guess correct?
> 
> yep.
> 
> > 
> > Any ideas? Also, could someone tell me what 
> nfs4_state_owner is? The 
> > comment says it is used to detect replays, but I'm not sure how.
> 
> the nfs4_state_owner is the open_owner (or in 3530 language, 
> is the lock_owner for the open state).
> 
> -->Andy
> > 
> > Thanks
> > 
> > Rahul
> > 
> > 
> > 
> 
>