[pnfs] Issues implementing LAYOUTRETURN

[Iyer, Rahul]

Hi!
Currently, even though the LAYOUTRETURN RPC is implemented, it is not
called anywhere. I was planning to add code to make these calls to the
code. However, I'm faced with a problem. 

The arguments for the LAYOUTRETURN call are as defined below:
struct nfs4_pnfs_layoutreturn_arg {
        __u64   clientid;
        __u64   offset;
        __u64   length;
        __u32   iomode;
        __u32   reclaim;
        __u32   type;
        struct inode* inode;
};

Unfortunately, from all the places LAYOUTRETURN needs to be called, all
we have is the inode. So, all we can get is the struct pnfs_layout_type.
Since the offset, length and iomode are parts of the opaque layout,
there's no way for a client can fill in these arguments. There is a
function pnfs_return_layout() which calls LAYOUTRETURN. It hardcodes the
iomode to write and the offset and length respectively to 0 and
0xffffffff (this is probably more correctly expressed as ~0, since
length is __u64, not __u32), but this will obviously not work with
extents. 

In order to solve this issue, there could be two possible schemes:
1. Add a call similar to setup_layoutcommit to the layoutdriver ops.
2. Move the offset, length and iomode fields from the opaque layout into
to the generic layout (struct pnfs_layout_type). 

While both will work, approach 1 will still pose a problem later on.
Currently, the code seems to assume whole file layouts. However, if we
do move to an extent based layout scheme in future, then we would be
faced with a dilemma on how to maintain the layout cache. The current
nfs_inode->current_layout will have to be replaced with a list of
layouts available for the inode (file) and this will mostly be indexed
by the (offset, length and iomode) fields, which are currently not
available. The alternative, of course, would be to have the layout
driver handle cache management, in which case approach 1 will do fine. 

I was wondering what people thought on this issue.
Thanks
Rahul