[pnfs] porting/merging/rebasing 2.6.18 -> 2.6.24
Benny Halevy
bhalevy at panasas.com
Mon Nov 19 11:37:49 EST 2007
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.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
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.
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
More information about the pNFS
mailing list