Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Only with a UPS
Posted Sep 10, 2009 17:34 UTC (Thu) by ncm (subscriber, #165)
Second, more subtle but probably more important, drives lie about what is physically on disk. To look good on benchmarks, they tell the controller that sectors have been physically copied to the platter while they are still only in buffer RAM in the drive -- up to several megabytes' worth. A few seconds after the last controller operation, these writes have drained to the disk. Before that, there's no guessing which have been written and which haven't, and blocks the system meant to write first may be written last. As a consequence, after powerup the file system sees blocks that are supposed to have important metadata in them with, instead, whatever was left there.
Posted Sep 10, 2009 18:05 UTC (Thu) by flewellyn (subscriber, #5047)
Posted Sep 10, 2009 19:19 UTC (Thu) by ncm (subscriber, #165)
OS developers don't count power drops among crashes because those aren't their fault. That's commendable, because when they say "crash" they mean something they accept responsibility for.
Posted Sep 10, 2009 22:20 UTC (Thu) by flewellyn (subscriber, #5047)
Handling power drops, to me, seems to be a matter of impossibility, at least as long as disks lie about when writes actually complete.
Posted Sep 11, 2009 8:29 UTC (Fri) by jschrod (subscriber, #1646)
Posted Sep 10, 2009 18:18 UTC (Thu) by aliguori (subscriber, #30636)
Not really. You can make a disk tell you when data is actually on the platter vs in the write cache. Furthermore, most "enterprise" drives have battery-backed write caches that guarantee enough power for the write caches to be flushed.
Posted Sep 10, 2009 19:06 UTC (Thu) by ncm (subscriber, #165)
No, you can ask a disk to tell you. It might even be honest about it if you never get the buffer too full. The commercial incentives to lie for the sake of benchmarks are extremely strong. Drives that don't lie cost a lot more, and are slower. Honesty is an extra-cost option. If you don't pay for honesty (few do) you won't get it.
Honesty usually costs a lot more than a UPS.
Posted Sep 10, 2009 19:12 UTC (Thu) by dlang (✭ supporter ✭, #313)
I think this is a myth like the drives that use platter energy to power themselves to write their buffer.
if you can point to a drive that includes a battery backup on the drive please post a link to it.
Posted Sep 10, 2009 19:22 UTC (Thu) by ncm (subscriber, #165)
Posted Sep 11, 2009 16:24 UTC (Fri) by nix (subscriber, #2304)
Posted Sep 11, 2009 14:41 UTC (Fri) by anton (guest, #25547)
First, if power drops during a physical write operation,
that sector is scragged. If it was writing metadata, you have serious
problems with whatever files that metadata describes, if anything
points to that sector.
And a modern file system can protect against the corruption of a
E.g., in a journaling file system, that sector is either in the log
or in the permanent storage. If it's in the log, just stop the replay
when you encounter the sector. If it's in permanent storage, then you
will notice that the replay write fails, and the file system can remap
the sector/block to a working one (or the drive might remap it
transparently on the replay write, or might just perform the write on
the original sector; in these cases the file system has nothing to do).
Of course, if the file system performs only meta-data journaling, then
it will likely not notice corrupt data (because it is not accessed
during replay), but apparently neither the file system maintainer nor
the user (or whoever decided to use a meta-data journaling file system) cares about data
anyway, so that's ok.
In a copy-on-write file system, the sector either contains the root
of the file system, or it contains something written after the last
root. In the latter case these blocks are unreachable anyway after
recovery (unless there is also an intent log, in which case the
discussion above applies). If the root is affected, then on recovery
the youngest alternative root is read, giving us the latest consistent
state of the file system.
Second, more subtle but probably more important, drives
lie about what is physically on disk.
With write caching disabled, the results of my experiments (both in
performance and in what was on disk after powering off) are consistent
with the theory that the drive reports the completion of writes only
after the sector hits the platter and (with the program I used)
consequently only wrote the sectors in order.
BTW, it's not just the drive manufacturers that default to fast
rather than safe; the Linux kernel developers do a similar thing (with
a much smaller performance incentive) when they disable barriers by
default, and turned ext3 from data=journal to data=ordered (and letting
data=journal rot), and recently to data=writeback (although that may
be just to make ext3 as bad as ext4 so people will not switch back).
Hmm, are Solaris or BSD developers less cavalier about their user's data?
On the subject: UPSs and computer PSUs can fail, too. Better
recommend a dual power supplies with dual UPSs; double failures should
be relatively rare.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds