From: Jeff Layton <jlayton@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: fstests <fstests@vger.kernel.org>, Eryu Guan <eguan@redhat.com>,
willy@infradead.org, andres@anarazel.de,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH] generic: test for seeing unseen fsync errors on newly open files
Date: Sat, 28 Apr 2018 08:05:20 -0400 [thread overview]
Message-ID: <1524917120.4751.0.camel@kernel.org> (raw)
In-Reply-To: <CAOQ4uxjjjKcsLwML3UkLGaU-LGz_gVxdNRxDotHgSzwPg=2tYg@mail.gmail.com>
On Sat, 2018-04-28 at 00:27 -0700, Amir Goldstein wrote:
> On Fri, Apr 27, 2018 at 9:38 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > From: Jeff Layton <jlayton@redhat.com>
> >
> > This adds a regression test for the following kernel patch:
> >
> > errseq: Always report a writeback error once
> >
> > This is motivated by some rather odd behavior done by the PostgreSQL
> > project. The main database writers will offload the fsync calls to a
> > separate process, which can open files after a writeback error has
> > already occurred.
> >
> > This used to work with older kernels that reported the error to only
> > one fd, but with the errseq_t changes we lost the ability to see
> > errors that occurred before the open. The above patch restores that
> > behavior.
> >
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> >
> > This patch currently fails on mainline kernels, but I'll be sending
> > a pull request to Linus in the near future for the above patch.
> >
> > src/Makefile | 2 +-
> > src/fsync-open-after-err.c | 167 +++++++++++++++++++++++++++++++++++++++++++++
> > tests/generic/999 | 95 ++++++++++++++++++++++++++
> > tests/generic/999.out | 3 +
> > tests/generic/group | 1 +
> > 5 files changed, 267 insertions(+), 1 deletion(-)
> > create mode 100644 src/fsync-open-after-err.c
> > create mode 100755 tests/generic/999
> > create mode 100644 tests/generic/999.out
> >
> > diff --git a/src/Makefile b/src/Makefile
> > index 0d3feae1eeb2..3dc9b0da9c3a 100644
> > --- a/src/Makefile
> > +++ b/src/Makefile
> > @@ -15,7 +15,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
> > holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
> > t_mmap_cow_race t_mmap_fallocate fsync-err t_mmap_write_ro \
> > t_ext4_dax_journal_corruption t_ext4_dax_inline_corruption \
> > - t_ofd_locks
> > + t_ofd_locks fsync-open-after-err
> >
> > LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
> > preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
> > diff --git a/src/fsync-open-after-err.c b/src/fsync-open-after-err.c
> > new file mode 100644
> > index 000000000000..3dcf936eb94a
> > --- /dev/null
> > +++ b/src/fsync-open-after-err.c
>
> Jeff,
>
> It is an anti pattern for xfstests to add a single purpose C program
> for things that could be implemented otherwise.
>
> AFAICT, This program doesn't do anything that you cannot do with
> existing bash helpers and existing programs.
>
> So either add a flag to fsync-err to enable the new test
> or use xfs_io fsync (make sure it really returns the error) and
> keep file open with bash tricks.
>
> Thanks,
> Amir.
Ok. Let's drop this patch for now and I'll see if I can code it up with
scripts somehow.
Thanks,
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2018-04-28 12:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 16:38 [PATCH] generic: test for seeing unseen fsync errors on newly open files Jeff Layton
2018-04-27 16:58 ` Andres Freund
2018-04-27 17:20 ` Jeff Layton
2018-04-28 7:27 ` Amir Goldstein
2018-04-28 12:05 ` Jeff Layton [this message]
2018-04-28 14:59 ` [PATCH v2] " Jeff Layton
2018-04-28 15:19 ` Amir Goldstein
2018-04-28 23:06 ` [PATCH v3] " Jeff Layton
2018-05-02 5:50 ` Eryu Guan
2018-05-08 12:46 ` Jeff Layton
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=1524917120.4751.0.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=andres@anarazel.de \
--cc=david@fromorbit.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=willy@infradead.org \
/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.