Re: [PATCH] 2.4.x write barriers (updated for ext3)

Chris Mason
2002-03-04T17:49:59Z

On Monday, March 04, 2002 11:35:24 AM -0600 James Bottomley <James.Bottomley@steeleye.com> wrote:

> sct@redhat.com said:
>> Generally, that may be true but it's irrelevant. Internally, the fs
>> may keep transactions as independent, but as soon as IO is scheduled,
>> those transactions become serialised. Given that pure sequential IO
>> is so much more efficient than random IO, we usually expect
>> performance to be improved, not degraded, by such serialisation.
>
> This is the part I'm struggling with. Even without error handling and certain
> other changes that would have to be made to give guaranteed integrity to the
> tag ordering, Chris' patch is a very reasonable experimental model of how an
> optimal system for implementing write barriers via ordered tags would work;
> yet when he benchmarks, he sees a performance decrease.
>

Actually most tests I've done show no change at all. So far, only
lots of O_SYNC writes stress the log enough to show a performance
difference, about 10% faster with tags on.

> I can dismiss his results as being due to firmware problems with his drives
> making them behave non-optimally for ordered tags, but I really would like to
> see evidence that someone somewhere acutally sees a performance boost with
> Chris' patch.

So would I ;-)

>
> Have there been any published comparisons of a write barrier implementation
> verses something like the McKusick soft update idea, or even just
> multi-threaded back end completion of the transactions?

Sorry, what do you mean by multi-threaded back end completion of the
transaction?

-chris