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

[Dean Hildebrand]

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?

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