[PATCH] xfstests shared/298: various fixes

[Eric Sandeen]

On 4/30/13 2:43 AM, Dave Chinner wrote:
> On Fri, Apr 26, 2013 at 03:18:52PM -0500, Eric Sandeen wrote:
>> fix shared/298:
>>
>> * don't include common/config, not needed and breaks
>>   stuff when $SCRATCH_DEV_POOL is defined:
>>     Error: $SCRATCH_DEV should be unset when $SCRATCH_DEV_POOL is set
>> * make sure xfs_io has fiemap, we'll need it
>> * add -F to the xfs_io invocation, again
> 
> What's it needed for this time?

the same as last time.  :)  using old xfs_io on a non-xfs fs.

>> * ignore ENOSPC errors from "garbage" loop; the only goal
>>   is to fill it, ENOSPC doesn't matter.
>>
>> Signed-off-by: Eric Sandeen <sandeen at redhat.com>
>> ---
>>
>> Wondering if we should just add " -F" to $XFS_IO_PROG . . . 
>>
>> diff --git a/tests/shared/298 b/tests/shared/298
>> index f1a3432..e2eddda 100755
>> --- a/tests/shared/298
>> +++ b/tests/shared/298
>> @@ -28,12 +28,12 @@ echo "QA output created by $seq"
>>  status=1	# failure is the default!
>>  trap "_cleanup; exit \$status" 0 1 2 3 15
>>  
>> -. common/config
>>  . common/rc
>>  
>>  _supported_fs ext4 xfs
>>  _supported_os Linux
>>  _require_fstrim
>> +_require_xfs_io_fiemap
>>  _require_fs_space $TEST_DIR 307200
>>  [ "$FSTYP" = "ext4" ] && _require_dumpe2fs
>>  
>> @@ -49,7 +49,7 @@ _cleanup()
>>  
>>  get_holes()
>>  {
>> -	$XFS_IO_PROG -c fiemap $1 | grep hole | $SED_PROG 's/.*\[\(.*\)\.\.\(.*\)\].*/\1 \2/'
>> +	$XFS_IO_PROG -F -c fiemap $1 | grep hole | $SED_PROG 's/.*\[\(.*\)\.\.\(.*\)\].*/\1 \2/'
>>  }
>>  
>>  get_free_sectors()
>> @@ -136,9 +136,10 @@ $MKFS_PROG -t $FSTYP $MKFS_OPTIONS $loop_dev &> /dev/null
>>  $MOUNT_PROG $loop_dev $loop_mnt
>>  
>>  echo -n "Generating garbage on loop..."
>> +# Goal is to fill it up, ignore any errors.
>>  for i in `seq 1 10`; do
>> -	mkdir $loop_mnt/$i
>> -	cp -r $here/* $loop_mnt/$i
>> +	mkdir $loop_mnt/$i &> /dev/null
>> +	cp -r $here/* $loop_mnt/$i &> /dev/null
> 
> Can you break out of the loop once cp fails with an error? There's
> no point hammering the filesystem for several loops after the first
> ENOSPC occurs....

yeah, ok.

Thanks,
-Eric

> -Dave.
>