From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Chengguang Xu <cgxu@mykernel.net>, Eryu Guan <eguan@redhat.com>,
fstests <fstests@vger.kernel.org>
Subject: Re: [PATCH] common: Add infrastructure for syncfs syscall tests
Date: Sat, 2 Dec 2017 08:43:20 +1100 [thread overview]
Message-ID: <20171201214320.GU4094@dastard> (raw)
In-Reply-To: <CAOQ4uxgOyPy9w96_HaUtM1thHcajn1LuHkiFSOtMZw0f-=HR8g@mail.gmail.com>
On Fri, Dec 01, 2017 at 09:21:15AM +0200, Amir Goldstein wrote:
> On Fri, Dec 1, 2017 at 8:38 AM, Chengguang Xu <cgxu@mykernel.net> wrote:
> >
> >> 在 2017年12月1日,下午12:13,Eryu Guan <eguan@redhat.com> 写道:
> >>
> >> On Fri, Dec 01, 2017 at 12:04:44PM +0800, Chengguang Xu wrote:
> >>> Hi Eryu,
> >>>
> >>> Actually, in my another test case generic/470 will need to check whether fs supports syncfs or not.
> >>> I make shared infrastructure for checking that, and because it is common component
> >>> I post as an individual patch instead of including in the case of generic/470.
> >>
> >> I think "_require_xfs_io_command syncfs" should be fine, there's no need
> >> & not encouraged to add new binary & usage like this. If you want to run
> >> syncfs(2) to make sure the kernel actually supports it, you can add a
> >> new 'syncfs' switch case in _require_xfs_io_command.
> >>
> >
> > Failure of _require_xfs_io_command check leads to notrun, if we have several
> > sync patterns(combination of fsync/fdatasync/syncfs/sync) in an actual test case,
> > the case will lose downward compatibility for old kernel.
> > In this situation, we have to split test case though they look similar.
> >
>
> You have 2 options:
> Easy - split 2 tests - 1 requires syncfs and tests syncfs, 1 does not
> require and does not test syncfs
> Work - re-factor _require_xfs_io_command to _check_xfs_io_command
> that returns the error
> message but does not _notrun. use that hepler in your test to
> conditionally test syncfs.
>
> Anyway, I see people are not so fond of the delalloc "canary test".
> Perhaps a still simple and quick test would be to do small buffered
> write; sync; small direct io read?
No, because the direct IO read can flush dirty buffers across the
range the IO is being done on. IOWs, you don't know if the sync
actually flushed it, the direct IO read flushed it, or the direct IO
read fell back to buffered IO and simply read the in memory copy.
Let's step back a moment: What bug/regression are you actually
trying to expose/reproduce here? Why is it not already covered by at
least one of the other generic sync/fsync tests we already have?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-12-01 21:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 3:55 [PATCH] common: Add infrastructure for syncfs syscall tests Chengguang Xu
2017-12-01 4:04 ` Chengguang Xu
2017-12-01 4:13 ` Eryu Guan
2017-12-01 6:38 ` Chengguang Xu
2017-12-01 7:21 ` Amir Goldstein
2017-12-01 21:43 ` Dave Chinner [this message]
2017-12-02 10:43 ` Amir Goldstein
2017-12-02 11:37 ` Amir Goldstein
2017-12-02 21:40 ` Dave Chinner
2017-12-03 6:45 ` Amir Goldstein
2017-12-04 6:05 ` Chengguang Xu
2017-12-04 8:44 ` 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=20171201214320.GU4094@dastard \
--to=david@fromorbit.com \
--cc=amir73il@gmail.com \
--cc=cgxu@mykernel.net \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.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.