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@xxxxxxxxxx> > > > > 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
