From: Dave Chinner <david@fromorbit.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.com>, Eryu Guan <eguan@redhat.com>,
xfs@oss.sgi.com, axboe@fb.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
Date: Wed, 19 Aug 2015 07:56:11 +1000 [thread overview]
Message-ID: <20150818215611.GD3902@dastard> (raw)
In-Reply-To: <20150818195439.GB15739@mtj.duckdns.org>
On Tue, Aug 18, 2015 at 12:54:39PM -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 18, 2015 at 10:47:18AM -0700, Tejun Heo wrote:
> > Hmm... the only possibility I can think of is tot_write_bandwidth
> > being zero when it shouldn't be. I've been staring at the code for a
> > while now but nothing rings a bell. Time for another debug patch, I
> > guess.
>
> So, I can now reproduce the bug (it takes a lot of trials but lowering
> the number of tested files helps quite a bit) and instrumented all the
> early exit paths w/o the fix patch. bdi_has_dirty_io() and
> wb_has_dirty_io() are never out of sync with the actual dirty / io
> lists even when the test 048 fails, so the bug at least is not caused
> by writeback skipping due to buggy bdi/wb_has_dirty_io() result.
> Whenever it skips, all the lists are actually empty (verified while
> holding list_lock).
>
> One suspicion I have is that this could be a subtle timing issue which
> is being exposed by the new short-cut path. Anything which adds delay
> seems to make the issue go away. Dave, does anything ring a bell?
No, it doesn't. The data writeback mechanisms XFS uses are all
generic. It marks inodes I_DIRTY_PAGES and lets the generic code
take care of everything else. Yes, we do delayed allocation during
writeback, and we log the inode size updates during IO completion,
so if inode sizes are not getting updated, then Occam's Razor
suggests that writeback is not happening.
I'd suggest looking at some of the XFS tracepoints during the test:
tracepoint trigger
xfs_file_buffered_write once per write syscall
xfs_file_sync once per fsync per inode
xfs_vm_writepage every ->writepage call
xfs_setfilesize every IO completion that updates inode size
And it's probably best to also include all the writeback
tracepoints, too, for context. That will tell you what inodes and
what part of them are getting written back and when....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2015-08-18 21:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150812101204.GE17933@dhcp-13-216.nay.redhat.com>
2015-08-13 0:44 ` generic/04[89] fail on XFS due to change in writeback code [4.2-rc1 regression] Dave Chinner
2015-08-13 15:34 ` Tejun Heo
2015-08-13 19:16 ` Tejun Heo
2015-08-13 22:44 ` [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes Tejun Heo
2015-08-14 11:14 ` Jan Kara
2015-08-14 15:14 ` Damien Wyart
2015-08-17 20:00 ` Tejun Heo
2015-08-18 5:33 ` Damien Wyart
2015-08-17 20:02 ` Tejun Heo
2015-08-18 9:16 ` Jan Kara
2015-08-18 17:47 ` Tejun Heo
2015-08-18 19:54 ` Tejun Heo
2015-08-18 21:56 ` Dave Chinner [this message]
2015-08-20 6:12 ` Eryu Guan
2015-08-20 14:01 ` Eryu Guan
2015-08-20 14:36 ` Eryu Guan
2015-08-20 14:37 ` Eryu Guan
2015-08-20 16:55 ` Tejun Heo
2015-08-20 23:04 ` Dave Chinner
2015-08-24 18:10 ` Tejun Heo
2015-08-24 22:27 ` Dave Chinner
2015-08-24 22:53 ` Tejun Heo
2015-08-21 10:20 ` Eryu Guan
2015-08-22 0:30 ` Dave Chinner
2015-08-22 4:46 ` Eryu Guan
2015-08-24 1:11 ` Dave Chinner
2015-08-24 3:18 ` Eryu Guan
2015-08-24 6:24 ` Dave Chinner
2015-08-24 8:34 ` Eryu Guan
2015-08-24 8:55 ` Dave Chinner
2015-08-24 9:19 ` Jan Kara
2015-08-24 14:51 ` Tejun Heo
2015-08-24 17:11 ` Tejun Heo
2015-08-24 19:08 ` Jan Kara
2015-08-24 19:32 ` Tejun Heo
2015-08-24 21:09 ` Jan Kara
2015-08-24 21:45 ` Tejun Heo
2015-08-24 22:54 ` Tejun Heo
2015-08-24 22:57 ` Dave Chinner
2015-08-25 18:11 ` [PATCH v2 block/for-linus] writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes() Tejun Heo
2015-08-25 20:37 ` Jens Axboe
2015-08-26 9:00 ` Jan Kara
2015-08-13 23:24 ` generic/04[89] fail on XFS due to change in writeback code [4.2-rc1 regression] Tejun Heo
2015-08-14 6:19 ` Eryu Guan
2015-08-17 20:27 ` Tejun Heo
2015-08-18 3:57 ` Eryu Guan
2015-08-18 5:31 ` Eryu Guan
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=20150818215611.GD3902@dastard \
--to=david@fromorbit.com \
--cc=axboe@fb.com \
--cc=axboe@kernel.dk \
--cc=eguan@redhat.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=xfs@oss.sgi.com \
/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;
as well as URLs for NNTP newsgroup(s).