Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.
Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Three comments
Three comments
Posted Jul 14, 2006 11:58 UTC (Fri) by nix (subscriber, #2304)In reply to: Three comments by ncm
Parent article: Crash-only software: More than meets the eye
Isn't the drive-write-late-and-garbage problem exactly what write barriers are meant to solve, and the major reason why the journalled filesystems and md layer make use of write barriers? (Do any drives actually lie about write barriers, too, and say they're passed when the stuff they bar is not yet on the medium?)
(Log in to post comments)
Write barriers
Posted Jul 14, 2006 19:15 UTC (Fri) by giraffedata (subscriber, #1954) [Link]
No, the problem that write barriers solve is where the device says "OK, I've got the data" and Linux considers the data to be permanent based on that. Before write barriers, that's what happens.That's not ridiculous, by the way. "Permanent" is a matter of degree, and being written on the platter is just one degree in the middle of the scale. Once the device has the data, it is safe from a Linux kernel crash, and that's a lot.
Write barriers are, BTW, a Linux kernel block layer phenomenon; the device doesn't know the concept. Linux has various ways to know that the device has put the data on the platter and uses them to implement write barriers. But if the device lies, the write barriers won't work.
Since the device lies to circumvent a system that explicitly asked for the data to go on the platter, I rather doubt that it would refrain from lying when Linux write barriers are involved.
BTW, I can't confirm or deny that devices lie like this, and to the extent claimed. If someone can back up this claim, I'd love to see it.
Three comments
Posted Jul 14, 2006 19:30 UTC (Fri) by ncm (subscriber, #165) [Link]
I don't know to what degree modern drives really obey write barriers. If history is any guide, they obey write barriers when the data rate is low, but toss them when the buffers fill up, or any time they seem to recognize a benchmark being run. In any case, they won't protect against sectors being half-written.
Three comments
Posted Jul 18, 2006 6:21 UTC (Tue) by nix (subscriber, #2304) [Link]
That's just horrible enough that it might be true, but the idealist in me hopes that it isn't, because it would render the entire concept of write barriers pointless :(
Three comments
Posted Jul 18, 2006 9:04 UTC (Tue) by ncm (subscriber, #165) [Link]
Not at all... it just means that backup power is necessary for a reliable system. Disk drive designers have learned not to pretend they can make a whole system reliable all by themselves, and that (furthermore) the market won't pay for them to try. It doesn't take much backup power; if you can get the CPU's or ATA interface's power to drop out of tolerance a few seconds before the drive's, that may be all you need.
Three comments
Posted Jul 19, 2006 7:17 UTC (Wed) by drs (guest, #16570) [Link]
My understanding of this problem (recalling a Ted Tso talk on the issue)is that as system voltage sags in an unexpected power failure, different
system components fail to operate correctly at different voltage levels.
More specifically, the voltage at which main memory maintains coherency is
significantly above the voltage at which the DMA engines in the
North/South bridge stop operating. So there is every likelihood that the
DMA engines will happily write random garbage from main memory to the
still operating disk. :(