[pnfs] LAYOUTRECALL testing

[William A.(Andy) Adamson]

> 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
> 
> 
>