Btrfs devel - Apr 2010 - Re: Poor interactive performance with I/O loads with fsync()ing

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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