Battery backed caches / 'hdparm -W 0'

Posted May 22, 2008 12:34 UTC (Thu) by i3839 (guest, #31386)
In reply to: Battery backed caches / 'hdparm -W 0' by tarvin
Parent article: Barriers and journaling filesystems

Disabling the write cache avoids this whole barrier problem, because writes can't be reordened
then. Performace will be much worse too, so better to enable the write cache and enable
barriers. (because writing with write cache enabled is faster the chance you'll lose data
while writing is also smaller. ;-)

'hdparm -W 0'

Posted May 22, 2008 19:10 UTC (Thu) by tarvin (guest, #4412) [Link] (1 responses)

I'm glad to hear that turning off the write cache helps. I've done that for years on hosts
which house data which are important to me, if the hosts don't have battery-backed cache.

No doubt, I'm probably loosing performance, but I've never found it unacceptable.

'hdparm -W 0'

Posted May 24, 2008 20:13 UTC (Sat) by giraffedata (guest, #1954) [Link]

To be precise: ordering of write commands, ordering of hardening to disk, and write caching (in the drive) are all separate things. With write caching turned off, the drive can still reorder the write commands and write the data to the platters in random order. But Linux will always know when the data has hit the platter and won't initiate the commit record until the journal data it covers is on the platter.

Linux can have multiple writes in progress at the disk drive (sent to the drive but the drive hasn't responded) at the same time, independent of write caching.