On Thu, Jan 20, 2011 at 12:11 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Thu, Jan 20, 2011 at 11:37:44AM +0530, Amit Sahrawat wrote:
> Hi,
>> I will try to find out the cause for this.Definitely. We're always looking for more people to add tests that
> Meanwhile, just a small request/suggestion - in the past this type of
> testcases have helped us in finding many problems in XFS.
> Can something like this be added to xfstests? This might help.
expose problems to xfstests. :) We try to keep individual test
runtime to as little as possible - under 5 minutes for the auto
group, under 15s for the quick group, but by the looks of it the
test you are running doesn't take that long to run.
>> Yes, the test case we are using is not taking much time this time to cause issue - around 3-4 minutes.
FWIW, there are already tests that cause worst case filesystem
fragmentation as part of their test setup (e.g. test 042) but the
coverage of such issues could definitely be improved. Also, the way
we generate fragmented filesystems - by writing files and then
removing a subset - could be greatly sped up by preallocation and
hole punching. There's no need to write data when we could just use
unwritten extents to do the same thing...
>> We basically fragment by doing following steps:
Full the disk with same size files (in this case it is 16k)
Then, randomly remove files from the disk.
Doing so, allows us to create files as per our requirement - complete control when we need - single extent, multiple extent files, Btree format file, single leaf file, multiple leaf file - It allows us ease to use XFS.
I hope you are getting what I am trying to say.
But, in this case - it starts causing issue at the very first stage - just copying 16k file to make disk full.
Thanks,
Amit Sahrawat
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
