[PATCH 2/4] xfstests: fsx fallocate support is b0rked

[Dave Chinner]

On Mon, Jun 27, 2011 at 04:16:20PM -0500, Eric Sandeen wrote:
> On 6/27/11 12:48 AM, Dave Chinner wrote:
> > From: Dave Chinner <dchinner at redhat.com>
> > 
> > The recent fallocate/fpunch additions to fsx have not actually be
> > executing fallocate/fpunch operations. The logic to select what
> > operation to run is broken in such a way that fsx has been executing
> > mapped writes and truncates instead of fallocate and fpunch
> > operations.
> > 
> > Remove all the (b0rken) smarty-pants selection logic from the test()
> 
> I hope I only extended that smarty-pants logic and didn't invent it.
> I suppose maybe I broke it first though, damn.

It was convoluted before the fallocate code was added. I can see why
it was easy to break....

> > function. Replace it with a clearly defined set of operations for
> > each mode and use understandable fallback logic when various
> > operation types have been disabled. Then use a simple switch
> > statement to execute each of the different operations, removing the
> > tortured nesting of if/else statements that only serve to obfuscate
> > the code.
> > 
> > NAs a result, fsx uses fallocate/fpunch appropriately during
> > operations, and uses/disableѕ the operations as defined on the
> > command line correctly.
> 
> Hm we're back in the fsx maintenance business I guess.

As soon as we start modifying it...

> Would it be worth doing defines or an enum for the ops/cases, to make it
> a little more readable?

I think better will be to redefine the OP_* numbers to match this
generation technique so we don't have two different sets of op
numbers.

I'll do this and post a new version.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com