public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-unionfs@vger.kernel.org, fstests <fstests@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] overlay: test ro/rw fd data inconsistecies
Date: Fri, 2 Dec 2016 13:42:31 +0800	[thread overview]
Message-ID: <20161202054231.GI29149@eguan.usersys.redhat.com> (raw)
In-Reply-To: <CAOQ4uxjSZuKocjcLdn6eWmJJdRqYrXonoq0Czvk-UCH6aWfseA@mail.gmail.com>

On Thu, Dec 01, 2016 at 06:42:00PM +0200, Amir Goldstein wrote:
> On Tue, Nov 29, 2016 at 1:37 PM, Eryu Guan <eguan@redhat.com> wrote:
> > On Tue, Nov 29, 2016 at 10:53:36AM +0200, Amir Goldstein wrote:
> 
> >>
> >> Eryu and all,
> >>
> >> I wanted to ask what is the common practice for introducing tests for
> >> know issues
> >> that are *about* to be solved.
> >>
> >> What is the preferred timing for merging these sort of tests?
> >> Is it productive to have these tests merged before a fix is merged to master?
> >> Before a fix is queued for next?
> >> Before a fix is available?
> >
> > Basically new regression tests will be merged as soon as possible, as
> > long as there're no objections from reviewers or all comments are
> > addressed.
> >
> > One exception is that for tests that could crash latest maintainer's
> > tree (even there's a known fix), I'd perfer letting the fix go upstream
> > first, so that the test doesn't break anyone's tests by crashing all the
> > testing hosts. It's great if the test author could give a notification
> > on the test to say that the fix has been merged, so the test could be
> > merged too. I'll watch the patch status too, but maybe not so timely.
> >
> 
> Nothing of a sort lurking with the tests I am planning to write.
> Just tests that check for "Non-standard behavior" of overlayfs,
> some of it described in Documentation/filesystems/overlayfs.txt.
> 
> >
> >>
> >> FYI, the fix for the test in this patch (test ro/rw fd data inconsistencies)
> >> is not queued for next yet, but I am hoping it will be.
> >> Miklos?
> >
> > FYI, this test is already in my last pull request to Dave.
> >
> 
> Eryu,
> 
> I am getting this error when running my test with an older xfs_io (4.3.0).
> I generated the good output with xfs_io from Dave's for-next branch (4.8.0).
> 
> Have you any idea why in one setup I see the commands echoed
> to output and not in the other?

I'm also using latest for-next branch, so I didn't notice this issue
either. I guess xfs_io changed its behavior on when to print \n in
interactive mode, but I didn't dig into the history.

> 
> I realize that the use of redirecting commands from here document
> to xfs_io has not been used in xfstests before, but I could not find
> another way to use 'open' commands, which are needed for this test.
> 
> Amir.
> 
> overlay/016      - output mismatch (see
> /home/amir/src/xfstests-dev/results//overlay/016.out.bad)
>     --- tests/overlay/016.out   2016-12-01 12:19:02.710370574 +0200
>     +++ /home/amir/src/xfstests-dev/results//overlay/016.out.bad
>  2016-12-01 18:29:23.684327009 +0200
>     @@ -1,12 +1,22 @@
>      QA output created by 016
>     -xfs_io> xfs_io> xfs_io> wrote 16/16 bytes at offset 0
>     +xfs_io> open -r foo
>     +xfs_io> open foo
>     +xfs_io> pwrite -S 0x61 0 16
>     +wrote 16/16 bytes at offset 0
>      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>     ...

I did find a better way to call open either, but if all we care about is
the output from reading the file, then we can check that explicitly and
ignore other outputs. e.g. 

--- a/tests/overlay/016
+++ b/tests/overlay/016
@@ -61,6 +61,8 @@ mkdir -p $lowerdir
 echo "This is old news" > $lowerdir/foo
 echo "This is old news" > $lowerdir/bar
 
+echo "Silence is golden"
+
 _scratch_mount
 
 cd $SCRATCH_MNT
@@ -72,7 +74,7 @@ cd $SCRATCH_MNT
 # write to rwfd
 # read from rofd
 #
-$XFS_IO_PROG << EOF | _filter_xfs_io
+$XFS_IO_PROG << EOF | grep "old"
 open -r foo
 open foo
 pwrite -S 0x61 0 16
@@ -86,7 +88,7 @@ EOF
 # write to rwfd
 # read from mapped memory
 #
-$XFS_IO_PROG << EOF | _filter_xfs_io
+$XFS_IO_PROG << EOF | grep "old"
 open -r bar
 mmap -r 0 16
 open bar
diff --git a/tests/overlay/016.out b/tests/overlay/016.out
index 52b8cd7..aa2526b 100644
--- a/tests/overlay/016.out
+++ b/tests/overlay/016.out
@@ -1,12 +1,2 @@
 QA output created by 016
-xfs_io> xfs_io> xfs_io> wrote 16/16 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-xfs_io> [000] foo            (foreign,non-sync,non-direct,read-only)
- 001  foo            (foreign,non-sync,non-direct,read-write)
-xfs_io> 00000000:  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
-read 16/16 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-xfs_io> xfs_io> xfs_io> xfs_io> xfs_io> wrote 16/16 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-xfs_io> 00000000:  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
-xfs_io> 
\ No newline at end of file
+Silence is golden

This should work for both old and new version of xfs_io.

Thanks,
Eryu

  reply	other threads:[~2016-12-02  5:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1480018332-16567-1-git-send-email-amir73il@gmail.com>
2016-11-29  8:53 ` [PATCH] overlay: test ro/rw fd data inconsistecies Amir Goldstein
2016-11-29  9:04   ` Miklos Szeredi
2016-11-29 11:37   ` Eryu Guan
2016-12-01 16:42     ` Amir Goldstein
2016-12-02  5:42       ` Eryu Guan [this message]
2016-12-02  6:49       ` Dave Chinner
2016-12-02  8:13         ` Amir Goldstein
2016-12-04 23:10           ` Dave Chinner
2016-12-05  7:01             ` Amir Goldstein

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=20161202054231.GI29149@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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