xfs
[Top] [All Lists]

Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]

To: linux-xfs@xxxxxxxxxxx
Subject: Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]
From: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Tue, 16 Dec 2008 10:39:07 +0100
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Peter Grandi <pg_xf2@xxxxxxxxxxxxxxxxxx>, Linux RAID <linux-raid@xxxxxxxxxxxxxxx>, Linux XFS <xfs@xxxxxxxxxxx>
In-reply-to: <20081215223857.GF32301@disturbed>
References: <alpine.DEB.1.10.0812060928030.14215@p34.internal.lan> <18757.33373.744917.457587@tree.ty.sabi.co.uk> <20081215223857.GF32301@disturbed> (sfid-20081216_091051_242821_0787460D)
User-agent: KMail/1.9.9
Am Montag 15 Dezember 2008 schrieb Dave Chinner:
> On Sun, Dec 14, 2008 at 10:02:05PM +0000, Peter Grandi wrote:
> > [ ... ]
> >
> > > But - as far as I understood - the filesystem doesn't have to
> > > wait for barriers to complete, but could continue issuing IO
> > > requests happily. A barrier only means, any request prior to
> > > that have to land before and any after it after it.
> > >
> > > It doesn't mean that the barrier has to land immediately and
> > > the filesystem has to wait for this. At least that always was
> > > the whole point of barriers for me. If thats not the case I
> > > misunderstood the purpose of barriers to the maximum extent
> > > possible.
> >
> > Unfortunately that seems the case.
> >
> > The purpose of barriers is to guarantee that relevant data is
> > known to be on persistent storage (kind of hardware 'fsync').
> >
> > In effect write barrier means "tell me when relevant data is on
> > persistent storage", or less precisely "flush/sync writes now
> > and tell me when it is done". Properties as to ordering are just
> > a side effect.
>
> No, that is incorrect.
>
> Barriers provide strong ordering semantics.  I/Os issued before the
> barrier must be completed before the barrier I/O, and I/Os issued
> after the barrier write must not be started before the barrier write
> completes. The elevators are not allowed to re-Ðrder I/Os around
> barriers.
>
> This is all documented in Documentation/block/barrier.txt. Please
> read it because most of what you are saying appears to be based on
> incorrect assumptions about what barriers do.

Hmmm, so I am not completely off track it seems ;-).

What I still do not understand then is: How can write barriers + write 
cache be slower than no write barriers + no cache? I still would expect 
write barriers + write cache be in between no barriers + write cache and 
no barriers + no cache performance wise. And would see anything else as a 
regression basically.

This doesn't go into my brain yet and I thought I understood 
Documentation/block/barrier.txt well enough before writing my article.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

<Prev in Thread] Current Thread [Next in Thread>