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

[Dave Chinner <david@fromorbit.com>]

On Fri, Jul 08, 2011 at 01:58:51PM -0500, Alex Elder wrote:
> On Fri, 2011-07-08 at 10:53 +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@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()
> > 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.
> > 
> > As a result, fsx uses fallocate/fpunch appropriately during
> > operations and uses/disableѕ the operations as defined on the
> > command line correctly.
> > 
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> 
> I started trying to understand the logic of the original in order
> to make sure your new version preserved the logic.  But then I
> concluded it was just plain broken, and understood exactly the
> point of this change...
> 
> So I just looked at your new code.  I have a few minor things
> but it otherwise looks good to me.  The way "closeopen" is
> (still) computed is a bit funked up (and possibly just wrong),
> but I'm not going to complain--you've done a lot of good here.
> 
> Reviewed-by: Alex Elder <aelder@sgi.com>
> 
> > ---
> >  ltp/fsx.c |  192 +++++++++++++++++++++++++++++++++++++++----------------------
> >  1 files changed, 123 insertions(+), 69 deletions(-)
> > 
> > diff --git a/ltp/fsx.c b/ltp/fsx.c
> > index a37e223..41d7c20 100644
> > --- a/ltp/fsx.c
> > +++ b/ltp/fsx.c
> > @@ -58,18 +58,47 @@ int			logptr = 0;	/* current position in log */
> >  int			logcount = 0;	/* total ops */
> >  
> >  /*
> > - *	Define operations
> > + * The operation matrix is complex due to conditional execution of different
> > + * features. Hence when we come to deciding what operation to run, we need to
> > + * be careful in how we select the different operations. The active operations
> > + * are mapped to numbers as follows:
> > + *
> > + *		lite	!lite
> > + * READ:	0	0
> > + * WRITE:	1	1
> > + * MAPREAD:	2	2
> > + * MAPWRITE:	3	3
> > + * TRUNCATE:	-	4
> > + * FALLOCATE:	-	5
> > + * PUNCH HOLE:	-	6
> > + *
> > + * When mapped read/writes are disabled, they are simply converted to normal
> > + * reads and writes. When fallocate/fpunch calls are disabled, they are
> > + * converted to OP_SKIPPED. Hence OP_SKIPPED needs to have a number higher than
> 
> The "hence" is not obvious.  The reason it needs to have a
> higher number is that the operation is selected at random
> among the number of operations available (either in "lite"
> or in "full" mode).

I'll reword it so it is obvious ;)

> 
> > + * the operation selction matrix, as does the OP_CLOSEOPEN which is an
> 
>                     selection
> 
> > + * operation modifier rather than an operation in itself.
> > + *
> > + * Because of the "lite" version, we also need to have different "maximum
> > + * operation" defines to allow the ops to be selected correctly based on the
> > + * mode being run.
> >   */
> >  
> > -#define	OP_READ		1
> > -#define OP_WRITE	2
> > -#define OP_TRUNCATE	3
> > -#define OP_CLOSEOPEN	4
> > -#define OP_MAPREAD	5
> > -#define OP_MAPWRITE	6
> > -#define OP_SKIPPED	7
> > -#define OP_FALLOCATE	8
> > -#define OP_PUNCH_HOLE	9
> > +/* common operations */
> > +#define	OP_READ		0
> > +#define OP_WRITE	1
> > +#define OP_MAPREAD	2
> > +#define OP_MAPWRITE	3
> > +#define OP_MAX_LITE	4
> 
> To me, "max" suggests that it is an included value
> in the range.  So I'd rather see this be "OP_NUM_LITE"
> or (my preference) "OP_LITE_COUNT".  Similarly for
> OP_MAX_FULL below.

Ok, makes sense.

> 
> > +
> > +/* !lite operations */
> > +#define OP_TRUNCATE	4
> > +#define OP_FALLOCATE	5
> > +#define OP_PUNCH_HOLE	6
> > +#define OP_MAX_FULL	7
> > +
> > +/* operation modifiers */
> > +#define OP_CLOSEOPEN	100
> > +#define OP_SKIPPED	101
> >  
> >  #undef PAGE_SIZE
> >  #define PAGE_SIZE       getpagesize()
> > @@ -955,6 +984,15 @@ docloseopen(void)
> >  	}
> >  }
> >  
> > +#define TRIM_OFF_LEN(off, len, size)	\
> > +do {					\
> > +	if (file_size)			\
> > +		offset %= size;		\
> > +	else				\
> > +		offset = 0;		\
> > +	if (offset + len > size)	\
> > +		len = size - offset;	\
> > +} while (0)
> 
> This macro is a very good idea.  However it differs
> from the original behavior when used for OP_WRITE,
> OP_MAPWRITE, OP_FALLOCATE, and OP_PUNCH_HOLE in
> that if file_size is zero, offset will be set to
> zero.  It seems like that behavior difference is
> significant, but I don't think it has a practical
> effect on the results of the test.  I've left the
> code in question below for reference.

True, it is a slight change in behaviour for OP_WRITE and
OP_FALLOCATE. I'll modify the macro to do the same thing.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs