Question about Cyrus, ext3, and Linux kernel 2.4.18 bug

[David Lang]

the reason data=journal can be faster is that the data is considered
synced when it hits the journal, since the journal write is a sequential
write (both for the data and the metadata) the filesystem can finish the
fsync faster then if it has to seek, write data, seek, write metadata
(assuming the best case where it doesn't take more seeks then that due to
fragmentation)

overall it will depend on how close you are to the limits of your drives,
since the data then needs to be written where it really needs to be the
other time will need to be spent, but it can be spent later when the
srive isn't as busy (if there is not such a time before the journal fills
up then you will hit the slowdown when it fills, but even then I think
theres some potential improvement from write combining)

David Lang


 On Thu, 17 Apr 2003, Henrique
de Moraes Holschuh wrote:

> Date: Thu, 17 Apr 2003 14:30:53 -0300
> From: Henrique de Moraes Holschuh <hmh at debian.org>
> To: Christopher Smith <x at xman.org>
> Cc: Michael Fair <michael at daclubhouse.net>, info-cyrus at lists.andrew.cmu.edu
> Subject: Re: Question about Cyrus, ext3, and Linux kernel 2.4.18 bug
>
> On Wed, 16 Apr 2003, Christopher Smith wrote:
> > On Wed, 2003-04-16 at 17:33, Michael Fair wrote:
> > > I guess this also just goes to prove your earlier point that
> > > data journals mostly just protect badly written applications...
> >
> > They also tend to improve performance of applications which need to make
> > guarantees about data anyway. For example, Cyrus seems to perform better
> > (defying intuition) on ext3 with data journaling turned on.
>
> Yeah, that it does. It not only performs better, it also defies intuition :P
>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
>