[Top] [All Lists]

Re: [RFC] btree test harness

To: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: [RFC] btree test harness
From: Christoph Hellwig <hch@xxxxxx>
Date: Sat, 16 Aug 2008 00:02:03 +0200
In-reply-to: <20080814005755.GF6119@disturbed>
References: <20080813223022.GA15025@xxxxxx> <20080814005755.GF6119@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
> > 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.

<Prev in Thread] Current Thread [Next in Thread>