Messages in this thread | | | Date | Sun, 24 Sep 2006 15:41:49 -0700 | From | Andrew Morton <> | Subject | Re: [2.6.18-rc7-mm1] slow boot |
| |
On Sun, 24 Sep 2006 23:36:41 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> 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 reordering.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |