Comment 60 for bug 317781

>One thing is not clear to me theo, I just expect it to. Is it true that memory
>cache, being faster, might also prevent a lot of problems? I got 4Gb on my
>box, might that be an explanation that I'm less likely to encounter problems?

@nyarnon,

No, having more or less memory won't make a difference; the issue here isn't a matter of being faster or slower, it's about how quickly data gets pushed out to disk. Normally the VM subsystem only starts writing data to disk only after 30 seconds have gone by for performance reasons --- in case the file gets modified a second time, no point writing it once, and then a second time 30 seconds later. How often tihs gets done is controlled by /proc/sys/vm/dirty_expire_centisecs, and how often you scan is controlled by /proc/sys/vm/dirty_writeback_centisecs. The default for these two values are 3000 (30 seconds) and 500 (5 seconds), respectively. These values can be adjusted by laptop_mode (to be higher), and in fact I've been playing with having these values much higher (60 minutes and 1 minute), mainly because I wanted to try to reduce writes to an SSD.

What happened is that ext3 in ordered data mode forced *all* blocks that were dirty to be pushed out during the next journal commit (which takes place by default every 5 seconds, more if you have laptop mode turned on). So something else you can do is to simply adjust these values down, in particular the dirty_expire_centisecs, to be something like 300. I wouldn't do this on a system where I was going to be running ext4 benchmarks, but it will automatically sync things out more aggressively.