[pnfs] Issues implementing LAYOUTRETURN

[Dean Hildebrand]

The code is definitely set up to support layout caching at the layout 
driver layer.  Moving away from this will be a big change to the 
pnfs<->layout driver interface.  From what I remember, we don't just 
support whole file layouts, but our support of layout extents is quasi 
at best (or incomplete).

Without a layout driver which will help us do layout extents properly, 
as it is really hard to guess the needs of something we don't have, 
maybe we should just continue with our assumption of whole file 
layouts.  The unmentioned option 0.  We can really worry about layout 
extents and a interface re-organization once the block driver and/or 
object driver starts setting design requirements.  Anything we do now 
will just be a guess (e.g., setup_layoutcommit)  I'm not against a 
setup_layoutreturn though if people think it has practical use with our 
current layout drivers.

Dean

Benny Halevy wrote:
> Initially, the thinking was to implement a layout cache at the layout 
> driver layer
> but I think there are advantages to having a unified, generic layout 
> cache,
> in particular to scheduling the layout recall process in which possibly
> several layout segments will have to be returned while the returns
> need to be serialized with in-flight layout operations.
> Keep in mind that object based layouts need to be treated a differently
> than files and blocks as explained in draft-ietf-nfsv4-pnfs-obj-01.txt
> since each layout segment is immutable and can't be split or merge
> with neighboring segments (extents).
>
> In summary, any design decision we make should take into account the 
> layout
> recall process...
>
> Benny
>
> Iyer, Rahul wrote:
>
>> 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
>> _______________________________________________
>> pNFS mailing list
>> pNFS at linux-nfs.org
>> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>>  
>>
>
>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs

-- 
Dean Hildebrand
Ph.D. Candidate
University of Michigan