From: Dave Chinner <david@fromorbit.com>
To: Sage Weil <sage@newdream.net>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH V2] xfs: timestamp updates cause excessive fdatasync log traffic
Date: Mon, 31 Aug 2015 12:21:55 +1000 [thread overview]
Message-ID: <20150831022155.GE26895@dastard> (raw)
In-Reply-To: <20150828220454.GC26895@dastard>
On Sat, Aug 29, 2015 at 08:04:54AM +1000, Dave Chinner wrote:
> On Fri, Aug 28, 2015 at 08:11:20AM -0700, Sage Weil wrote:
> > Hi Dave,
> >
> > On Fri, 28 Aug 2015, Dave Chinner wrote:
> > >
> > > From: Dave Chinner <dchinner@redhat.com>
> > >
> > > Sage Weil reported that a ceph test workload was writing to the
> > > log on every fdatasync during an overwrite workload. Event tracing
> > > showed that the only metadata modification being made was the
> > > timestamp updates during the write(2) syscall, but fdatasync(2)
> > > is supposed to ignore them. The key observation was that the
> > > transactions in the log all looked like this:
> [....]
>
> > > ---
> > > Version 2:
> > > - include the hunk from fs/xfs/xfs_trans_inode.c that I missed
> > > when committing the patch locally the first time.
> >
> > I gave this a go on my machine but I'm still seeing the same symptom.
>
> OK, that implies the inode buffer has not been submitted for IO and
> so the inode is being held in "flushing" state for an extended
> period of time.
>
> > I've gathered the trace, strace, and other useful bits at
> >
> > http://newdream.net/~sage/drop/rocksdb.2/
> >
> > This is pretty easy to reproduce with the ceph_test_keyvaluedb binary
> > (built on fedora 22), also in that dir:
> >
> > rm -rf kv_test_temp_dir/
> > ./ceph_test_keyvaluedb --gtest_filter=KeyValueDB/KVTest.BenchCommit/1
>
> I'll have a deeper look.
Ok, I was assuming this is a longer running test than it is - it
only takes about 2300ms to run on my test box. Hence the problem is
that the inode has never been flushed out, and so it's being
relogged in full on every fdatasync() operation. Another, similar
change is necessary to track the changes since the last time the
inode was flushed to the log.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-31 2:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 1:23 [PATCH] xfs: timestamp updates cause excessive fdatasync log traffic Dave Chinner
2015-08-28 4:32 ` [PATCH V2] " Dave Chinner
2015-08-28 15:11 ` Sage Weil
2015-08-28 22:04 ` Dave Chinner
2015-08-31 2:21 ` Dave Chinner [this message]
2015-08-31 8:48 ` Dave Chinner
2015-08-31 12:40 ` Sage Weil
2015-08-31 21:51 ` Dave Chinner
2015-09-08 14:45 ` Brian Foster
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=20150831022155.GE26895@dastard \
--to=david@fromorbit.com \
--cc=sage@newdream.net \
--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