[pnfs] [PATCH 0/32] block layout patches

[Benny Halevy]

On Mar. 26, 2008, 19:52 +0200, Dean Hildebrand <seattleplus at gmail.com> wrote:
> Hey Benny,
> 
> Not sure what you were intending, but let's hold off a bit on committing 
> Fred's patches to the pnfs/nfsv41 branch, I need some more time to go 
> through them. Or I guess you could create a special fred-pnfs branch......

OK.

Here's the tree structure I'll work on then:

master-2.6.24
        upstream-2.6.24
                nfs41-2.6.24
                        pnfs-2.6.24				# 7730afb pnfs: remove PNFS_ISSYNC
                                spnfs-2.6.24
                                panlayout-2.6.24		# 8d6e364 panlayout: fix typo that prevents compile
                                fred-pnfs-2.6.24		# 2decdca pnfs: pnfs_write_end
                                        fred-pnfs-block-2.6.24	# d1b9837 pnfsblock: STUB: encode layoutcommit
                                        fred-panlayout-2.6.24	# aede29f panlayout: repair break done by change in call API.
                                        fred-spnfs-2.6.24	# 60ed25a Add the spnfs.txt documentation to the kernel tree
        master
                upstream
                        nfs41					# rebase/rework of nfs41-2.6.24 onto 2.6.25-rc7
                                pnfs				# rebase/rework of pnfs-2.6.24 onto 2.6.25-rc7
                                        fred-pnfs
                                                fred-pnfs-block
                                                fred-panlayout
                                                fred-spnfs

master and up are all based on 2.6.25-rc7

Benny

> 
> Thanks,
> Dean
> 
> Benny Halevy wrote:
>> On Mar. 25, 2008, 20:14 +0200, Fredric Isaman <iisaman at citi.umich.edu> wrote:
>>   
>>> On Tue, 25 Mar 2008, Dean Hildebrand wrote:
>>>
>>>     
>>>> Fredric Isaman wrote:
>>>>       
>>>>> On Tue, 25 Mar 2008, Dean Hildebrand wrote:
>>>>>
>>>>>         
>>>>>> It seems to me that there are 3 conversations in this patchset.  Is there 
>>>>>> any way you could re-organize these patches in 3 patchsets? 
>>>>>> nfs/pnfs/pnfsblock. The reason I ask is that I like some of the nfs/pnfs 
>>>>>> changes, and would be willing to put some into the nfs41/pnfs tree, but 
>>>>>> they are hard to review when intermingled with the pnfsblock patches.  If 
>>>>>> you want, you could put the reason for the nfs/pnfs changes in the patch 
>>>>>> header (e.g., block needs this to xxxxxx)
>>>>>>
>>>>>> Dean
>>>>>>
>>>>>>           
>>>>> I tried to distinguish them via the prefix of the subject line, so that you 
>>>>> could ignore anything that starts with "pnfsblock:" if you wanted to only 
>>>>> look at pnfs changes.  However, I admit they are ordered more for my 
>>>>> convienence than a reviewers.  Would it suffice to reorder them such that 
>>>>> all nfs, then pnfs, then pnfsblock were in succession?
>>>>>
>>>>>     Fred
>>>>>         
>>>> That would work, but it still kind of seems to me that they are 3 separate 
>>>> patchsets.  (or maybe 2 patch sets since the block driver is really a 
>>>> separate entity than the nfs/pnfs/filelayout code) I would like to discuss 
>>>> changes to nfs / pnfs on their merits, not in the context of block-only 
>>>> requirements (e.g., this patch allows *any* layout driver to xxxx)
>>>>
>>>> Dean
>>>>       
>>> OK.  I'll break them into 2 patch sets.
>>>
>>>  	Fred
>>>     
>> Great. Thanks!
>> I hope to apply all the pending patches later today or tomorrow after
>> I finish rebasing the 2.6.24 pnfs branch onto 2.6.25 (quite a few
>> conflicts with changes at the rpc layer).
>> I'll then apply the 2.6.24 patches onto the 2.6.24 branch, freeze it,
>> and rebase them onto the 2.6.25 series which will go live on air :)
>>
>> Benny
>>
>>   
>>>>>> Fred Isaman wrote:
>>>>>>           
>>>>>>> These patches implement block layout (draft 5), and incorporate Benny's
>>>>>>> comments from the last round.
>>>>>>>
>>>>>>> The panlayout error case is broken by patch 5, but is restored via
>>>>>>> patch 6 and a separate panlayout patch to follow.  If there is some
>>>>>>> better way to handle this let me know.
>>>>>>>
>>>>>>>      Fred
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>     
>>