[lkml]   [2001]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Disk hardware caching, performance, and journalling
Steve Bergman wrote:
> Note that block writes are over 3 times faster with caching on.

With a large linear write, linux typically feeds requests into the
disk like this:

write 248 sectors
write 248 sectors
write 248 sectors
write 8 sectors
write 248 sectors

Now, 248+8 sectors is 128 kbytes. A track is, say, 300 kbytes.

With writebehind the disk can write that entire track in pretty
much a single spin. But if we're waiting on the result of each
request we'll lose revolutions. In synchronous mode it's going
to take three or four spins to write a track.

> So what are the implications here for journalling? Do I have to turn
> off caching and suffer a huge performance hit?

In theory, yes. In my opinion, no. For ext3, at least. Caching
isn't bad per-se. It's reordering which can break the journalling
constraints. But given that the journal is, we hope, a strictly
ascending and (we really hope) contiguous chunk of blocks, it's
quite unlikely that the disk will decide to write them in an
unexpected order. This is especially true if the journal was
created when the disk was relatively unfragmented.

And if the disk _does_ write them in the wrong order, it has
to be specifically the journal commit block which was written
prior to some data blocks. And you need to lose power (not
just crash) prior to the data blocks hitting disk. It's a
very small time window containing an improbable occurrence.

Now that's all just vigorous handwaving, and may be wrong,
and yes, we really need a way of propagating barriers down
to the request queue. But I've not seen a whisker of a report
which indicates that write reordering has caused on-recovery

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.108 / U:4.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site