[pnfs] porting/merging/rebasing 2.6.18 -> 2.6.24

[Ricardo Labiaga]

Hi Dean,

On Fri, 2007-11-16 at 17:08 -0800, Dean Hildebrand wrote:
> Hmmmm, the patch gets me worried.  It seems to indicate that there is 
> already *some* pnfs client code in the 2.6.14 pnfs kernel.  Have we 
> already ported some pnfs client code forward?  If so, what was it?  I 
> know server pnfs code went forward, but do we know what 2.6.18 pnfs 
> client code went into 2.6.24?

That's correct.  You're seeing the code from when I started porting the
2.6.18 pNFS client code wholesale to 2.6.24 before Andy volunteered to
take over.  The first step was to integrate the pNFS file layout driver
(pnfs.c, nfs4filelayout.c, and nfs4filelayout.c).  This needed to
introduce a number of stubs to the function calls in fs/nfs/nfs4proc.c.
The actual implementation of the calls was started a step at a time,
based on the 2.6.18 implementation.  Fsinfo was updated to support the
layout discovery, and implemented getdevicelist (draft 10?) before Andy
took over.

I like Andy's approach better.  He's able to think it through while
implementing the functionality instead of propagating the bugs.  This is
what we did for the client sessions implementation as well.
 
- ricardo


> 
> Anyways, we are obviously need to make a tough decision.   Let me try a 
> summary of the previous emails:
> -----------
> Method 1) One way is to port "features" forward from 2.6.18 to 2.6.24, 
> e.g., the read path, the write path, etc, using the 2.6.18 code as a 
> *guide*.
> Advantages:
> i) Opportunity to implement features correctly and avoid porting forward 
> *bad* code
> ii) The code has changed so much that porting forward a large pnfs patch 
> would be difficult if not impossible, so this method may be easier.
> 
> Disadvantages:
> i) Possibly miss bits of code in the port, causing us to redo lots of 
> bug fixing
> ii) We still need to compare final port of 2.6.24 with a 2.6.18 pnfs 
> patch to ensure we didn't miss anything.
> 
> Personally, I think this works well if
> a) We know what features we have in 2.6.18.  I actually don't think we 
> really know this information.  I know there is a lot of code there that 
> handles each of the layout drivers requirements.
> b) We know what code in 2.6.18 maps to each feature.  When we moved to 
> cvs, the patches for each feature were lost and so this mapping is tough...
> -----------
> Method 2) The other way it seems is to port the entire 2.6.18 pnfs 
> kernel forward to 2.6.24.  *Somehow* get a pnfs patch, which hopefully 
> doesn't include any sessions code, and apply it to 2.6.24.
> Advantages:
> 1) Ensure every bit of code makes it into the latest kernel, so we can 
> avoid re-implementing and/or re-debugging pNFS.
> 2) Once all code has been ported forward, we can worry about improving 
> the code. 
> 
> Disadvantages:
> 1) The patch script may apply functions or modify functions that it 
> shouldn't in 2.6.24 due to the vast difference between the kernel versions.
> 2) Port forward existing bugs and/or code hacks. 
> 
> I think 2.6.24 already has a very basic but working version of a 
> client/server implementation of sessions.  So for this to work we need 
> to get a 2.6.18 pNFS patch WITHOUT sessions (which we also need for 
> Method 1) and then figure out what each individual change is for and how 
> it should be implemented in 2.6.24.  Not an easy task!
> -----------
> 
> Method 3: Post-track kernel versions from 2.6.18 to 2.6.24
> I wonder if Bruce's suggestion of re-basing 2.6.18-pnfs one kernel 
> version forward at a time is the best way to go.  It would allow us to 
> slowly adapt to the kernel changes while ensuring that we don't *lose* 
> any pnfs code along the way.  Obviously we can use Andy's patches in the 
> process.  If *tracking* the kernel is supposedly the best way to solve 
> this mess, then this method of post-tracking seems like possibly the 
> best answer.  In the end, moving forward one kernel version at a time is 
> the work we were supposed to do in the first place and it may turn out 
> to be less work than Method 1 or 2 above.
> 
> I think all 3 will work and all 3 will be painful.  Anyways, something 
> we can talk about at the pNFS conf call in 2 weeks.
> 
> Dean
> 
> 
> andros at umich.edu wrote:
> > From: Andy Adamson <andros at umich.edu>
> >
> > Remove unimplemented pnfs operations from pnfs_v41_clientops so that
> > the nfslayoutdriver works. Will add opeations as implemented.
> >
> > Signed off by: Andy Adamson<andros at umich.edu>
> > ---
> >  fs/nfs/nfs4proc.c |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > index 87df222..c355c2d 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -5202,7 +5202,7 @@ const struct nfs_rpc_ops pnfs_v41_clientops = {
> >  	.file_inode_ops	= &nfs4_file_inode_operations,
> >  	.getroot	= nfs4_proc_get_root,
> >  	.getattr	= nfs4_proc_getattr,
> > -	.setattr	= pnfs4_proc_setattr,
> > +	.setattr	= nfs4_proc_setattr,
> >  	.lookupfh	= nfs4_proc_lookupfh,
> >  	.lookup		= nfs4_proc_lookup,
> >  	.access		= nfs4_proc_access,
> > @@ -5224,10 +5224,10 @@ const struct nfs_rpc_ops pnfs_v41_clientops = {
> >  	.set_capabilities = nfs4_server_capabilities,
> >  	.decode_dirent	= nfs4_decode_dirent,
> >  	.read_setup	= nfs4_proc_read_setup,
> > -	.read_done	= pnfs4_read_done,
> > +	.read_done	= nfs4_read_done,
> >  	.write_setup	= nfs4_proc_write_setup,
> > -	.write_done	= pnfs4_write_done,
> > -	.commit_setup	= pnfs4_proc_commit_setup,
> > +	.write_done	= nfs4_write_done,
> > +	.commit_setup	= nfs4_proc_commit_setup,
> >  	.commit_done	= nfs4_commit_done,
> >  	.file_open      = nfs_open,
> >  	.file_release   = nfs_release,
> >   
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs