> Two things:
> 1- power loss. Fixing things to write to disk is bound to fail in
> adverse conditions. If the drive suffers from write problems and the
> write takes longer than the charge of your capacitor lasts, your
> data is still toasted. nonvolatile memory with finite write time
> (like NVRAM/Flash) will help to save the Cache. I don't think vendors
> will do that soon.
> 2- error handling with good power: with automatic remapping turned on,
> there's no problem, the drive can re-write a block it has taken
> responsibility of, IBM DTLA drives will automatically switch off the
> write cache when the number of spare block gets low.
> with automatic remapping turned off, write errors with enabled write
> cache get a real problem because the way it is now, when the drive
> reports the problem, the block has already expired from the write
> queue and is no longer available to be rescheduled. That may mean
> that although fsync() completed OK your block is gone.
I think we have gotten away from the original subject. The problem (as I
understood it) wasn't that we don't have time to write the whole cache...
the problem is that the hard disk stops in the middle of a write, not
updating the CRC of the sector, thus making it report as a bad sector when
trying to recover from the failure. No?
I think most people here are convinced that there is not time to write a
several-MB (worst case) cache to the platters in case of a power failure.
Special drives for this case could of course be manufactured, and here's for
a theory of mine: Wouldn't a battery backed-up SRAM cache do the thing?
Anyway, maybe it is just me who have been thrown off-track? Are we
discussing something else now maybe?
| Martin Eriksson <email@example.com>
| MSc CSE student, department of Computing Science
| Umeň University, Sweden
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/