* Re: Poor interactive performance with I/O loads with fsync()ing [not found] ` <4BC1E4A4.1070103@redhat.com> @ 2010-04-11 16:35 ` Ben Gamari 2010-04-11 17:20 ` Andi Kleen 0 siblings, 1 reply; 2+ messages in thread From: Ben Gamari @ 2010-04-11 16:35 UTC (permalink / raw) To: Avi Kivity, linux-btrfs Cc: Andi Kleen, Arjan van de Ven, linux-kernel, tytso, npiggin, mingo, Ruald Andreae, Jens Axboe, Olly Betts, martin f krafft On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity <avi@redhat.com> wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen<andi@firstfloor.org> wrote: > > > >> Ben Gamari<bgamari.foss@gmail.com> writes: > >> ext4/XFS/JFS/btrfs should be better in this regard > >> > >> > > I am using btrfs, so yes, I was expecting things to be better. Unfortunately, > > the improvement seems to be non-existent under high IO/fsync load. > > > > btrfs is known to perform poorly under fsync. > Has the reason for this been identified? Judging from the nature of metadata loads, it would seem that it should be substantially easier to implement fsync() efficiently. - Ben ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Poor interactive performance with I/O loads with fsync()ing 2010-04-11 16:35 ` Poor interactive performance with I/O loads with fsync()ing Ben Gamari @ 2010-04-11 17:20 ` Andi Kleen 0 siblings, 0 replies; 2+ messages in thread From: Andi Kleen @ 2010-04-11 17:20 UTC (permalink / raw) To: Ben Gamari Cc: Avi Kivity, linux-btrfs, Andi Kleen, Arjan van de Ven, linux-kernel, tytso, npiggin, mingo, Ruald Andreae, Jens Axboe, Olly Betts, martin f krafft > Has the reason for this been identified? Judging from the nature of metadata > loads, it would seem that it should be substantially easier to implement > fsync() efficiently. By design a copy on write tree fs would need to flush a whole tree hierarchy on a sync. btrfs avoids this by using a special log for fsync, but that causes more overhead if you have that log on the same disk. So IO subsystem will do more work. It's a bit like JBD data journaling. However it should not have the stalls inherent in ext3's journaling. -Andi -- ak@linux.intel.com -- Speaking for myself only. ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-04-11 17:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4b9fa440.12135e0a.7fc8.ffffe745@mx.google.com>
[not found] ` <4baeaee5.c5c2f10a.7187.2688@mx.google.com>
[not found] ` <20100327204233.0d84542a@infradead.org>
[not found] ` <4baf624c.48c3f10a.16d0.ffffccb8@mx.google.com>
[not found] ` <87y6hcyu85.fsf@basil.nowhere.org>
[not found] ` <4bbf401e.a3b9e70a.13f3.4460@mx.google.com>
[not found] ` <4BC1E4A4.1070103@redhat.com>
2010-04-11 16:35 ` Poor interactive performance with I/O loads with fsync()ing Ben Gamari
2010-04-11 17:20 ` Andi Kleen
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).