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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4DD745B6.4030302@linux.vnet.ibm.com>
Date:	Fri, 20 May 2011 21:55:18 -0700
From:	Allison Henderson <achender@...ux.vnet.ibm.com>
To:	Dave Chinner <david@...morbit.com>
CC:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Eric Sandeen <sandeen@...hat.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	xfs-oss <xfs@....sgi.com>
Subject: Re: [XFS Tests Punch Hole 2/3 v3] XFS TESTS: Add Fallocate Punch
 Hole Test Routines

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
--
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