On Sat, Apr 30, 2011 at 3:16 AM, Allison Henderson <achender@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> wrote: >>>> >>>> On 4/26/2011 9:48 PM, Yongqiang Yang wrote: >>>>> >>>>> On Wed, Apr 27, 2011 at 3:08 AM, Allison Henderson >>>>> <achender@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>. >>>>>>> >>>>>>> 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@xxxxxxxxxxxxxxx >>>>>>> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
