Re: [RFC] btree test harness

[Christoph Hellwig <hch@lst.de>]

> > does it's own freelist to avoid having to call in the alloc code
> > and make it even slower.
> 
> I'll have a closer look in a while. It's just a bitmap array, right?

Yes, it's just a trivial bitmap of all blocks.

> > I'd also like some input on how interface to userspace.  Doing it during
> > mount but conditional would be one option, the other one an ioctl -
> > in both cases I'd like to be able to specify up to which maxlevel to go
> > as the tests for higher levels can take forever.
> 
> I was thinking of a couple of approaches when I started on this
> harness:
> 
> 	- similar to RCU torture tests, the btree test harness is
> 	  run on XFS intialisation if config'd in. Requires faking a
> 	  struct xfs_mount, though, and isn't configurable.
> 	- ioctl interface to run each test operation individually,
> 	  and hook that up to an xfsqa test that used a sparse
> 	  loopback mounted filesytem to exercise AG sizes up to 1TB.
> 
> I think the second approach allows us to test btrees on demand on
> arbitrary disposable filesystems. It would also allow us to easily
> extend the test harness over time - a new xfsqa test group could be
> added so that each test can be written as a standalone test so
> that we can easily isolate regressions.

Faking up the mount doesn't really wrok, we need a _lot_ of fields
in there, plus a buftarg plus a real xfs_trans and thus the whole log
subsystem, so we need a real filesystem anyway.  With the way I use a
separate btree I can just use up the whole filesystem without making
it sprase.  But yes, splitting things into individual ioctls makes sense
to make the tests a little more flexible.