[pnfs] porting/merging/rebasing 2.6.18 -> 2.6.24
William A. (Andy) Adamson
andros at citi.umich.edu
Mon Nov 19 10:28:36 EST 2007
I thought we already made the decision - that I was going to do exactly what
I did to move from 2.6.17 to 2.6.18.3, which is to look at the old code and
move it forward (by hand) taking advantage of the new base kernel code
organization. So this approach is not new....This time around, there is a
whole bunch of difference between the two kernels.
Over the weekend, I thought about Benny's point of moving the 2.6.18.3 code
forward with as little change as possible, to get preserve the good work
that was done in that kernel. To that end, I will re factor the patch set
that I sent separating new concepts from old. I will also include
documentation explaining what was done and why. I should be able to send
this out by days end. Also, I did not include an important piece for the
object and block layouts - the "no rpc" cleanup of nfs pages.
So, I will take another stab at it, trying to address your concerns.
-->Andy
On 11/16/07, Ricardo Labiaga <ricardo.labiaga at netapp.com> wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20071119/1cfb1f56/attachment.htm
More information about the pNFS
mailing list