* 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).