Message-ID: <BANLkTikQ+-WVzntJgQS=Po-YOxWvc-JN-Q@mail.gmail.com>
Date:	Sat, 30 Apr 2011 03:42:07 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org, cmm@...ibm.com
Subject: Re: [PATCH RFC v1 0/5]Factor common code from convert and split unwritten.

On Sat, Apr 30, 2011 at 3:16 AM, Allison Henderson
<achender@...ux.vnet.ibm.com> wrote:
> On 4/28/2011 12:51 PM, Allison Henderson wrote:
>>
>> On 4/27/2011 11:05 PM, Yongqiang Yang wrote:
>>>
>>> Hi Allison,
>>>
>>> Could you send punch hole patch and fsx(if you modified it) to me? I
>>> can not reproduce the bug on my system without punch hole.
>>>
>>> Thank you,
>>> Yongqiang.
>>>
>>
>> Sure, I have a patch for fsx to enable fallocate, and another patch that
>> adds punch hole to the test suite. Right now I'm just working on
>> getting our patches through the fsx that only has fallocate enabled. I
>> thought it might be best if we work out all the bugs with that first
>> before we deal with the more complex tests.
>>
>> Also, I have a debug patch that fits on top of the punch hole patch.
>> Initially I hadn't planned to send it out, but maybe it might help you
>> so I will include it too.
>>
>> Allison Henderson
>
> Hi all,
>
> Just some updates on this issue.  We are currently still trying to track
> down all the remaining bugs, and I hadn't planed on sending out another
> version of punch hole until we caught them all, but there is another
> suggestion to re-order the patch sets such that the RFC patch set applies on
> top of the punch hole set.
>
> In the updated punch hole patch set that I have not yet sent out, the
> modifications to the split extents routine have been dropped (patch 2/6 in
> the punch hole v5 patch set), because those changes were being done in the
> underlying RFC patch set.  If we re-order the patch sets, I would have to
> retain the split extents modifications, which means that the RFC set would
> have to be modified to deal with that.
>
> I did think of one other option though.  There were two versions of the RFC
> patch set, and we only had to make a small modification to the first RFC set
> to make it work. After that, I didnt have any trouble with any of the test
> cases.  So a third option would be to push forward with an updated version
> of the first RFC set.  That would save Yongqaing from having to go back and
> deal with patch 2/6 of punch hole, and then only the remaining code that
> optimizes zeroing out extents would have to be made to apply on top of punch
> hole.  But I wasn't sure if that idea would be preferable to moving the
> entire set on top of punch hole, or if it is just better for us to continue
> pushing forward with debugging what we have now.  In the end, what ever
> combination of sets we choose to do should still be passing all the tests,
> but what would everyone prefer to do?  Thx!
Hi,

I think we should push forward with the updated version without
optimization for zeroing out extents.  After split-extent and
punch-hole patches are merged into the tree, I will try to optimize
zeroing out extents.

I will send out the patches Allison has tested well.

Allison, thank you for testing the patches.

Yongqiang.

>
> Allison Henderson
>
>
>
>
>>
>>> On Wed, Apr 27, 2011 at 2:34 PM, Allison Henderson
>>> <achender@...ux.vnet.ibm.com> wrote:
>>>>
>>>> On 4/26/2011 9:48 PM, Yongqiang Yang wrote:
>>>>>
>>>>> On Wed, Apr 27, 2011 at 3:08 AM, Allison Henderson
>>>>> <achender@...ux.vnet.ibm.com> wrote:
>>>>>>
>>>>>> On 4/23/2011 1:44 AM, Yongqiang Yang wrote:
>>>>>>>
>>>>>>> v0->v1:
>>>>>>> fix a bug in ext4_ext_convert_to_initialized() reported by
>>>>>>> Allison<achender@...ux.vnet.ibm.com>.
>>>>>>>
>>>>>>> optimize ext4_ext_convert_to_initialized().
>>>>>>>
>>>>>>> -- factor common code
>>>>>>> These patches factor common code from
>>>>>>> ext4_ext_convert_to_initialized()
>>>>>>> and
>>>>>>> ext4_split_unwritten_extents() so that extent-move-on-write in
>>>>>>> snapshot
>>>>>>> and
>>>>>>> punch hole can be built on the common code.
>>>>>>>
>>>>>>> -- optimization
>>>>>>> the 4th and the 5th patch optimize ext4_ext_convert_to_initialized()
>>>>>>> by
>>>>>>> zeroing out in memory.
>>>>>>>
>>>>>>>
>>>>>>> [PATCH RFC v1 1/5] ext4:Add a function merging extent right and left.
>>>>>>> [PATCH RFC v1 2/5] ext4:Add two functions splitting an extent.
>>>>>>> [PATCH RFC v1 3/5] ext4:Reimplement convert and split_unwritten.
>>>>>>> [PATCH RFC v1 4/5] ext4: Add a function ext4_ext_zeroout_mem().
>>>>>>> [PATCH RFC v1 5/5] ext4: optimize ext4_ext_convert_to_initialized().
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> linux-ext4" in
>>>>>>> the body of a message to majordomo@...r.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> Just an update on your patch set. Im am working on getting the punch
>>>>>> hole
>>>>>> patch to work with this new set, but I'm am having trouble getting it
>>>>>> through the stress test. It gets up to around 48265 file
>>>>>> operations, and
>>>>>> then hangs. So I am currently trying to narrow down the problem. It
>>>>>> looks
>>>>>> like it does it with or with out the extra punch hole patches, but you
>>>>>> may
>>>>>> need to enable fallocate in the fsx Makefile to recreate the
>>>>>> problem. I
>>>>>> will keep you posted if I find any more clues.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could you tell me how to get fsx? I can not find that.
>>>>
>>>> Hi there,
>>>>
>>>> I believe you can find it in both xfstests and ltp. The one I am using I
>>>> got from xfstests here:
>>>>
>>>> http://xfs.org/index.php/Getting_the_latest_source_code
>>>>
>>>> Once you have it configured and built, there is a sub folder called ltp.
>>>> Execute this command from that folder:
>>>>
>>>> ./fsx -d -b 1 -N 100000 -S 1 /mnt/ext4MntPt/holePunch/testFile
>>>>
>>>> Where "/mnt/ext4MntPt/holePunch/testFile" is a file on an ext4 file
>>>> system.
>>>> It should then try to run through 100000 random file operations, but get
>>>> stuck on number 48256.
>>>>
>>>> If you do not see any fallocate operations running, you may have to go
>>>> enable it in the ltp/Makefile. I had to change "ifeq ($(HAVE_FALLOCATE),
>>>> true)" to "ifeq ($(HAVE_FALLOCATE), yes)" to allow the extra
>>>> fallocate code
>>>> to compile in. Let me know if you have any trouble recreating the bug.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Yongqiang.
>>>>>>
>>>>>> Allison Henderson
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists