public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Chengguang Xu <cgxu519@icloud.com>, Eryu Guan <eguan@redhat.com>,
	fstests <fstests@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] generic/470: add syncfs test
Date: Tue, 12 Dec 2017 11:18:06 +1100	[thread overview]
Message-ID: <20171212001806.GS4094@dastard> (raw)
In-Reply-To: <CAOQ4uxgjJzbFq92jfkRguU-JQftb57SfTqt-f5NPaLip2LVjNg@mail.gmail.com>

On Mon, Dec 11, 2017 at 02:44:50PM +0200, Amir Goldstein wrote:
> On Mon, Dec 11, 2017 at 2:33 PM, Chengguang Xu <cgxu519@icloud.com> wrote:
> >>
> >> 在 2017年12月11日,下午6:46,Amir Goldstein <amir73il@gmail.com> 写道:
> >>
> >> On Mon, Dec 11, 2017 at 12:03 PM, Chengguang Xu <cgxu519@icloud.com> wrote:
> >>>>
> >>>> 在 2017年12月7日,下午4:17,Amir Goldstein <amir73il@gmail.com> 写道:
> >> [...]
> >>>
> >>> I did more detail tests for three different data modes of ext4 and found
> >>> the overlayfs syncfs bug is reproducible on data=ordered and data=writeback,
> >>> but on data=journal mode, data is flushed and correct.
> >>
> >> That is expected, because overlayfs does call upper's sync_fs() method and
> >> for journal=data that will flush all dirty pages as well.
> >>
> >>> I only wrote only a few words
> >>> to a single file and the bug is always reproducible on my test environment.
> >>>
> >>> For writeback interferences, AFAIK, from dirty ratio and period.
> >>> If we drop all dirty caches & sync before the test, I think we can
> >>> avoid interference from it.
> >>>
> >>
> >> Why? does either drop_caches or sync() reset the flusher thread
> >> periodic flush dirty pages?
> >
> > Sorry,We have to finish test in 30 seconds after we write test file,
> > otherwise may be affected by background flusher.
> >
> >
> >>
> >>> So if we don’t have anything else to interference test result,
> >>> I just want to modify to write a small single file as test target.
> >>>
> >>> Am I missing anything?
> >>
> >> I think the chance of flusher thread interfering the test and
> >> flushing the dirty page you wrote before _scratch_shutdown exists,
> >> but is small enough so we can neglect it and keep the test as simple
> >> as possible.
> >
> > As I know, in normal case flusher thread check dirty inode expiring every 5 seconds(default) and flush dirty
> > inode when expires 30 seconds(default). If we can finish test in 30s after running test, it would be OK.
> > What do you think?
> >
> 
> 5 seconds is ext4 default journal commit interval. this is when dirty
> metadata will be flushed.
> 30 is generic flusher thread interval.
> What if test started 29 seconds after last flush?

Then the inode is only 1 second "old" when the flush occurs and so
it gets ignored. it'll get flushed only once it's been dirty for
longer than a flusher thread interval.

IIRC there's quite a few tests where we make the assumption we've
got at least 30s before the dirty cached data will be written by the
kernel. e.g. for shutting down the filesystem before data hits the
disk to test metadata vs data recovery state.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2017-12-12  0:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07  2:22 [PATCH v2 1/3] common/rc: add scratch shutdown support for overlayfs Chengguang Xu
2017-12-07  2:22 ` [PATCH v2 2/3] common/rc: add a check case in _require_xfs_io_command() to support syncfs Chengguang Xu
2017-12-07  2:22 ` [PATCH v2 3/3] generic/470: add syncfs test Chengguang Xu
2017-12-07  3:04   ` Amir Goldstein
2017-12-07  3:31     ` Chengguang Xu
2017-12-07  3:43       ` Amir Goldstein
2017-12-07  5:44   ` Eryu Guan
2017-12-07  6:20     ` Chengguang Xu
2017-12-07  7:13       ` Eryu Guan
2017-12-07  7:42         ` Chengguang Xu
2017-12-07  8:17           ` Amir Goldstein
2017-12-11 10:03             ` Chengguang Xu
2017-12-11 10:46               ` Amir Goldstein
2017-12-11 12:33                 ` Chengguang Xu
2017-12-11 12:44                   ` Amir Goldstein
2017-12-11 13:20                     ` Chengguang Xu
2017-12-11 14:31                       ` Chengguang Xu
2017-12-11 14:47                         ` Amir Goldstein
2017-12-12  0:18                     ` Dave Chinner [this message]
2017-12-07  2:54 ` [PATCH v2 1/3] common/rc: add scratch shutdown support for overlayfs Amir Goldstein
2017-12-07  5:31 ` Eryu Guan
2017-12-08  0:05 ` Dave Chinner

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=20171212001806.GS4094@dastard \
    --to=david@fromorbit.com \
    --cc=amir73il@gmail.com \
    --cc=cgxu519@icloud.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-unionfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox