[pnfs] porting/merging/rebasing 2.6.18 -> 2.6.24
William A. (Andy) Adamson
andros at citi.umich.edu
Mon Nov 19 13:12:50 EST 2007
On 11/19/07, Benny Halevy <bhalevy at panasas.com> wrote:
>
> On Nov. 19, 2007, 17:28 +0200, "William A. (Andy) Adamson" <
> andros at citi.umich.edu> wrote:
> > 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.3code
> > 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
>
> Thanks!
> I have a few comments on the previous patchset you sent BTW...
> I'll send them right away so you can incorporate them on the new one.
Great! We will get this right..... :)
-->Andy
Benny
>
> > 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
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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/20a958ac/attachment.htm
More information about the pNFS
mailing list