On Fri, Jul 15, 2011 at 09:19:02AM -0500, Alex Elder wrote: > On Tue, 2011-07-12 at 20:27 -0500, Eric Sandeen wrote: > > On 7/12/11 7:20 PM, Dave Chinner wrote: > > > On Tue, Jul 12, 2011 at 07:14:19PM -0500, Eric Sandeen wrote: > > >>> I'm guessing that the only case I was able to hit during testing of > > >>> this code originally was the "overlap with exact start block match", > > >>> otherwise I would have seen this. I'm not sure that there really is > > >>> much we can do to improve the test coverage of this code, though. > > >>> Hell, just measuring our test coverage so we know what we aren't > > >>> testing would probably be a good start. :/ > > >> > > >> Apparently the original oops, and the subsequent replay oopses, > > >> were on a filesystem VERY busy with torrents. > > >> > > >> Might be a testcase ;) > > So, would you mind trying to create this as a test? > Can you come up with a reliable way to create a > small but *very* fragmented filesystem to do stuff > with? See test 042 - it's not hard to do.. But 042 only uses a 48MB filesystem. To generate hundreds of thousands of extents, it needs to be done on a filesystem that can hold hundreds of thousands of blocks - gigabytes in size, IOWs. What I'd like to do is basically fill the fs full of single block files, delete every alternate one (fragments free space to stress those btrees), then fill the fs again with a single preallocation on a new file to convert the freespace fragments to a fragmented bmbt index, then free the remaining single block files and fill the fs again with a single preallocation on the same file that already fills half the fs. Finally, unmount the filesystem, mount it again and remove the extents back to the free space by iteratively punching out sparse ranges of the large file until it is empty. e.g. 0-1MB, 10-11MB, .... 1000MB-1001MB, 1-2MB, 11-12MB, ..... That should be a deterministic test that does the same btree operations from run to run and provide decent coverage of most of the btree and extent tree operations - including loading a massive bmap tree from disk into memory. I'd also like to repeat the test, but this time doing a random delete of half the files so the fragmented file is not made up entirely of single block extents. That will perturb the way the btrees grow and shrink and so will execute btree operations in combinations that the above deterministic test won't. e.g. it will trip bmbt split/merges causing freespace btree split/merges in the one allocation/free operation that a deterministic test will never hit... We don't really have coverage of bmap extent trees with that number of extents in them right now, and test 250 shows that we do really need that coverage (it exercised a bug in a 2->3 level split, IIRC). I'd also be inclined to use a 512 byte filesystem block size with only 2 AGs to cause the height of both the freespace and bmap the btrees to increase much more quickly, too. If we can, I'd like the test to range up to at least million extents in a bmap btree - that covers single unfragmented files into the multi-PB range for 4k block size filesystems. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
