[pnfs] Issues implementing LAYOUTRETURN

[William A.(Andy) Adamson]

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

i am implmenting a block layout driver against an EMC simulator. i expect to 
have GETDEVICELIST, GETDEVICEINFO and LAYOUTGET done by months end. so, we 
will soon have a driver which deals in extents, and can consider a unified 
generic layout cache.

i think it's ok to proceed with the whole file assumption as it is the simple 
case, and add complexity as we gain experience.
 
-->Andy

> 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
> 
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs