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
next prev parent reply other threads:[~2016-12-02 5:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 20:12 [PATCH] overlay: test ro/rw fd data inconsistecies Amir Goldstein
2016-11-29 8:53 ` 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 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.