Re: [2.6.18-rc7-mm1] slow boot

From: Andrew Morton
Date: Sun Sep 24 2006 - 18:42:28 EST

On Sun, 24 Sep 2006 23:36:41 +0100
Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> Ar Sul, 2006-09-24 am 14:53 -0700, ysgrifennodd Andrew Morton:
> > I've *never* seen any reports of any problems being caused by disk
> > writeback caching. Yes, it's a theoretical problem but for some reason it
> > just doesn't seem to be a problem in practice. Hence I'm really reluctant
> > to go and slow everyone's machines down so much in this manner.
> It happens in some cases, the usual one is sudden loss of power. In the
> crashed box cases the disk still gets to write data back and in the
> Linux power off sanely cases we explicitly cache flush. Its the sudden
> loss of power case that is nasty.

I don't know about reiserfs, but for ext3 writeback caching delays aren't a
problem per-se. It's write *reordering* which matters.

And given that the jounal tends to be a single contiguous hunk of disk, the
probability that a journal block at LBA #N gets written before the commit
block at LBA #N+20 is probably fairly low. There's block remapping of
course, but software journal wrapping might be a more likely cause of write

And of course the time window is small - a few milliseconds per five
seconds, and not every five seconds at that.

Hand wavy, I know. But I wouldn't pay 15% throughput for it..

> We are also helped of course by the fact the cache is never more than
> can be flushed in about 7 seconds because of other-os features.

Well, as I say, the absolute value of any delay doesn't really matter,
except you'd lose an additional seven seconds worth of work. It's
write reordering which can damage the fs.

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