Re: [XFS Tests Punch Hole 2/3 v3] XFS TESTS: Add Fallocate Punch Hole Test Routines

Allison Henderson
2011-05-21T04:55:49Z

On 5/20/2011 8:57 PM, Dave Chinner wrote:
> On Fri, May 20, 2011 at 05:46:19PM -0700, Allison Henderson wrote:
>> On 5/19/2011 6:22 PM, Allison Henderson wrote:
>>> Also, there was one more test that I meant to be a part of this
>>> collection, but I was not finished with it at the time I submitted the
>>> patch for feedback. Basically it checks to see if a hole can still be
>>> punched out when the disk is full. In ext4 this is allowable because
>>> reserved space is used to allow the operation to proceed where it would
>>> have otherwise failed. I'm not sure if this is also ext4 specific
>>> though. Would this be another candidate for adding to 252? Thx!
>>
>> I just didnt want this question to get washed away in the traffic.
>> I am working on an updated patch set, should I include the extra
>> test case? Thx!
>
> Yes, though probably not in the _generic_test_punch function. And
> extra case specific to 252 that does something like:
>
> umount SCRATCH_DEV
> make a small filesystem
> scratch_mount
> prealloc to ENOSPC
> punch
>
>
> Cheers,
>
> Dave.

Thx Dave, I will include include it once I get it working in the
xfstests frame work. The code for it though ended up being a little
more complex than what you have there. This one might be easier to talk
about with the code in front of us, but I will trying to sum it up quickly:

Because punching a hole does not always require extra blocks, it has to
go through a couple rounds of punching holes, and then "topping off" the
file system to 100% usage before it is forced to grow the tree in order
to deal with the fragmentation. The growing of the tree is what would
have triggered the ENOSPC on the next punch if not for the use of
reserved blocks. Before this feature was in place, this magic number
appeared to be about 333 iterations for ext4. Once we added it though,
it was able to run through an indefinite cycle of punching out every
other two blocks and topping off the fs (at least until it ran off the
edge of the file it is punching away at). The test case I have calls it
good after 500, but this may be something we may need to tweek in order
for it to be effective for other file systems too.

On a side note, I've hit a bit of a snag at the moment, because it
appears that test 252 hangs when run on ext4. It looks like the call to
get the fiemap doesnt come back for some reason, so I will need to
figure this out first, but when I get it all working, I will get the
updated set out to you asap. Thx for all your help, Dave. I really
appreciate all the thorough reviews! :)

Allison Henderson