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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.