On Tue 2008-01-15 20:36:16, Chris Mason wrote: > On Tue, 15 Jan 2008 20:24:27 -0500 > "Daniel Phillips" <phillips@xxxxxxxxxx> wrote: > > > On Jan 15, 2008 7:15 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > > > Writeback cache on disk in iteself is not bad, it only gets bad > > > > if the disk is not engineered to save all its dirty cache on > > > > power loss, using the disk motor as a generator or alternatively > > > > a small battery. It would be awfully nice to know which brands > > > > fail here, if any, because writeback cache is a big performance > > > > booster. > > > > > > AFAIK no drive saves the cache. The worst case cache flush for > > > drives is several seconds with no retries and a couple of minutes > > > if something really bad happens. > > > > > > This is why the kernel has some knowledge of barriers and uses them > > > to issue flushes when needed. > > > > Indeed, you are right, which is supported by actual measurements: > > > > http://sr5tech.com/write_back_cache_experiments.htm > > > > Sorry for implying that anybody has engineered a drive that can do > > such a nice thing with writeback cache. > > > > The "disk motor as a generator" tale may not be purely folklore. When > > an IDE drive is not in writeback mode, something special needs to done > > to ensure the last write to media is not a scribble. > > > > A small UPS can make writeback mode actually reliable, provided the > > system is smart enough to take the drives out of writeback mode when > > the line power is off. > > We've had mount -o barrier=1 for ext3 for a while now, it makes > writeback caching safe. XFS has this on by default, as does reiserfs. Maybe ext3 should do barriers by default? Having ext3 in "lets corrupt data by default"... seems like bad idea. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
