On 8/20/2008 1:13 PM, James G. Sack (jim) wrote:
David Brown wrote:
On Wed, Aug 20, 2008 at 08:52:03AM -0700, Gus Wirth wrote:
Consider the cache on the hard drive. One of the boasting points of hard
drive manufacturers is the size of the RAM cache for the drive. What
isn't specified is how that cache behaves under a power loss. Does it
try and write itself to the disk? Does it just dump everything? Even if
the operating system has done a perfect job in syncing memory to disk,
it still hasn't really been written out until the drive itself flushes
its own cache. And you have no control over that.
If you have a modern linux kernel and the drive/controller path
supports write barriers you can do a lot to mitigate losses even with
a large cache.
Basically, a well-designed filesystem inserts write barriers between
certain writes, and the drive will make sure that all writes before
barrier happen before those afterward. Unfortunately, most of the
filesystems seem to silently just not use barriers if they aren't
present (XFS complains loudly) even though their presence
significantly helps reliability on power loss.
So I wonder which (controllers &) drives support write barriers. How
does one find out? The hdparm help and manpage seem silent about it. I
suppose there might be some parm in /sys/block/sda (or?), but I can't
see anything obviously relevant.
I did find a lwn article about the subject (may, 2008)
http://lwn.net/Articles/283161/
It includes this:
"""
So barriers are disabled by default because they have a serious impact
on performance. And, beyond that, the fact is that people get away with
running their filesystems without using barriers. Reports of ext3
filesystem corruption are few and far between.
"""
The ATA spec, available here: http://tinyurl.com/69xrpj
doesn't appear to contain the word 'barrier'. It does support a command
called "Flush Cache". Maybe that's the same thing. Also in the ATA8
command set is section 4.24, called "Write-Read-Verify Feature Set",
which might be it.
Karl
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
