public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jie Liu <jeff.liu@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Mark Tinguely <tinguely@sgi.com>, xfs@oss.sgi.com
Subject: Re: xfstests: SEEK_HOLE/SEEK_DATA advanced tests
Date: Wed, 17 Oct 2012 11:38:53 +0800	[thread overview]
Message-ID: <507E284D.40800@oracle.com> (raw)
In-Reply-To: <20121017023439.GB26797@dastard>

On 10/17/12 10:34, Dave Chinner wrote:
> On Tue, Oct 16, 2012 at 03:42:41PM -0500, Mark Tinguely wrote:
>> This is the test of the advanced SEEK_HOLE and SEEK_DATA features
>> of the lseek() function call.
>>
>> Jie Liu <jeff.liu@oracle.com> wrote the C code, I converted it to
>> a test with his permission.
> Jie, can you sign-off on this patch as well as it has Oracle
> copyright statements in it?
Hi Dave,

I can sign-off this patch, but it's better to keep the copyright
statements with SGI for this test script since
it wrote by Mark, and Mark is already made the C test file as Oracle.

Thanks,
-Jeff
>> Signed-off-by: Mark Tinguely <tinguely@sgi.com
> Typo - missing closing ">"
>
>> +
>> +[ -x $here/src/seek_advance_test ] || _notrun "seek_advance_test not built"
>> +
>> +_cleanup()
>> +{
>> +	rm -f $src1 $src2
>> +}
>> +
>> +	echo "Silence is golden..."
>> +	rm -f $src1 $src2
> Rather strange indenting here and for the rest of the test...
>
>> +        write_cmd1="-c \"falloc 512k 256k\" -c \"pwrite 516k 4k\" -c \
>> +		    \"pwrite 800k 4k\""
>> +        write_cmd2="-c \"falloc 512k 256k\" -c \"pwrite 600k 16k\""
> That reminds me of line noise :/
>
>> +
>> +        eval ${XFS_IO_PROG} -F -f "${write_cmd1}" $src1 > $seq.full 2>&1 ||
>> +                _fail "create test1 file failed!"
>> +        echo "*** create test1 file done ***" >>$seq.full
>> +        eval ${XFS_IO_PROG} -F -f "${write_cmd2}" $src2 >>$seq.full 2>&1 ||
>> +                _fail "create test2 file failed!"
>> +        echo "*** create test2 file done ***" >>$seq.full
>
> The way that you're executing xfs_io to create the files is,
> well, convoluted. It doesn't need -F anymore, either. Just run:
>
> $XFS_IO_PROG -f -c "falloc 512k 256k" \
> 		-c "pwrite 516k 4k" \
> 		-c "pwrite 800k 4k" \
> 		$src1 | _filter_xfs_io
>
> And allow the golden output match to detect failures to create the
> file correctly. The filter/golden output test is designed to avoid
> all this "did it work" detection around simple operations.  Indeed,
> seek_advance_test checks the file exists (via the open parameters)
> and errors out with an error message so there is no need to check it
> ahead of time and specifically fail the test.
>
> Further, with the xfs_io output in the golden output, you don't need
> the intermediate "echo <redundant information>" lines to determine
> what failed, either....
>
>> +        echo >>$seq.full
>> +        $here/src/seek_advance_test $dir >> $seq.full || _fail "test failed"
> Pass in the file names, not the directory. That way you only encode
> the filename in one place, not have ot keep the test and .c code in
> step.
>
>> +
>> +status=0
>> +exit
>> +
>> Index: b/288.out
>> ===================================================================
>> --- /dev/null
>> +++ b/288.out
>> @@ -0,0 +1,2 @@
>> +QA output created by 288
>> +Silence is golden...
> Not when you should be using the golden output to detect failures
> instead of convouted code....
>
>> Index: b/group
>> ===================================================================
>> --- a/group
>> +++ b/group
>> @@ -406,3 +406,4 @@ deprecated
>>  285 auto rw
>>  286 other
>>  287 auto dump quota quick
>> +288 other
> Why? it's a test that is quick and should always be run. If you are
> worried about it failing on systems that don't support
> SEEK_HOLE/DATA, then add a _requires_seek_hole function....
>
>> +#include <assert.h>
>> +
>> +#ifndef SEEK_DATA
>> +#define SEEK_DATA	3
>> +#define SEEK_HOLE	4
>> +#endif
>> +
>> +char *base_file_path;
>> +
>> +int
>> +verify(
>> +	off_t offset,
>> +	off_t exp_hoff,
>> +	off_t exp_doff,
>> +	off_t hoff,
>> +	off_t doff)
> I don't really understand what the variables are supposed to mean
> or what is being verified here.
>
>> +{
>> +	fprintf(stdout, "SEEK start %lu expect %ld/%ld got %ld/%ld [%s]\n",
>> +	offset, exp_hoff, exp_doff, hoff, doff,
>> +	(hoff == exp_hoff && doff == exp_doff) ? "PASS" : "FAIL");
>> +
>> +	return(hoff != exp_hoff || doff != exp_doff);
>
> Why are you even determining pass/fail here?
>
> This is what golden output matching is for. Dump some numbers out,
> and if they match the golden output the test passed. If they don't,
> the test fails. We can't filter this output if necessary, nor
> support different block size filesystems, etc. because the
> verification is done within the C code rather than by the filters
> and test harness.
>
> Indeed, if you add SEEK_HOLE/SEEK_DATA to xfs_io to dump the next
> offset of that type given a start offset, then this can all be
> implemented in a single script using filtering golden output
> matching, and can easily be made to support different block sizes.
> This code is just going to be fragile and hard to maintain....
>
> Cheers,
>
> Dave.

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

  reply	other threads:[~2012-10-17  3:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121016204240.142425319@sgi.com>
2012-10-16 20:42 ` xfstests: SEEK_HOLE/SEEK_DATA advanced tests Mark Tinguely
2012-10-17  2:34   ` Dave Chinner
2012-10-17  3:38     ` Jie Liu [this message]
2012-10-17  7:24       ` Dave Chinner
2012-10-17  8:33         ` Jie Liu
2012-10-17 12:52     ` Mark Tinguely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=507E284D.40800@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=david@fromorbit.com \
    --cc=tinguely@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox