Re: Linux pNFS status meeting 08/26

[Boaz Harrosh <bharrosh@panasas.com>]

On 08/31/2010 12:15 AM, Labiaga, Ricardo wrote:
> Last week Andy, Fred, Trond, and I were physically in the same location,
> so we took the opportunity to review the first set of patches in the
> pnfs-submit branch and further discussed the best way to proceed with
> the submission.  For ease of review, Trond reiterated that we submit our
> patches in waves of functionality and that they be submitted as a set of
> few large patches.
> 
> The proposal is to submit the functionality in the following order:
> 
> 1st Layoutget and getdeviceinfo (together)
> 2nd Layoutreturn
> 3rd Read/ Write I/O path (could be broken into two sets)
> 4th Callback Path
> 5th Layoutcommit
> 

A natural read and understanding of pnfs has this logical progression

1st Layoutget and getdeviceinfo (together)
2rd Read/ Write I/O path (could be broken into two sets)
3rd Layoutcommit
4th Layoutreturn
5th Callback Path

Could you elaborate a bit on why you choose to reorder them this way?

> For the 1st wave of functionality, the suggestion is to submit three
> large patches:
> 

I would love to see a:
0. Complete STD definitions headers

> 1. Everything that touches NFS common code 
>   (such as init and uninit pNFS, pnfs_update_layout invocations)

Separation to proc and XDR layers

> 2. Layoutget and getdeviceinfo generic code common to all layout drivers

Is that the high level pnfs.c stuff? then YES nice.

Will this be together with it's invocation at the nfs-vfs files like
inode.c write.c etc.. ?

> 3. File layout specific layoutget and getdeviceinfo
> 

You might want to reorder 2 and 3. First submit services which are at first
dead code. Then submit the code that calls them. Are you making a point
in making each patch compilable, runnable through out?

> This means we have about 19 or so of the first pnfs-submit patches that
> need to be squashed into a single patch for ease of review.  In
> addition, we found a number of minor issues during the review that need
> to be addressed.  We also need to strip out some things that are not
> strictly needed for the first wave of patches, with the intent to
> reintroduce them when the functionality is actually used by objects and
> blocks.  It was made clear that including functionality that is not
> required by the File Layout driver at this time is not appropriate.  For
> example, io_ops that are no required by the File Layout (and have a
> trivial implementation) are a no-go.  The abstraction is best introduced
> when the drivers that actually require it are submitted.
> 
> Andy and Fred will email the details of the changes along with the
> patches shortly.
> 
> Net-net, no radical changes needed, but a number of small issues that
> need to be addressed before we can start submitting.  More details
> coming shortly.
> 
> Thanks,
> 	
> - ricardo

Thanks
Boaz