Messages in this thread | | | Date | Thu, 7 Aug 2008 14:53:18 -0400 | From | "John Stoffel" <> | Subject | Re: amd64 sata_nv (massive) memory corruption |
| |
>>>>> "Martin" == Martin K Petersen <martin.petersen@oracle.com> writes:
>>>>> "Linas" == Linas Vepstas <linasvepstas@gmail.com> writes: Linas> My problem is that the corruption I see is "silent": so Linas> redundancy is useless, as I cannot distinguish good blocks from Linas> bad. I'm running RAID, one of the two disks returns bad data. Linas> Without checksums, I can't tell which version of a block is the Linas> good one.
Martin> But btrfs can.
Maybe. I'd not trust btrfs even now because the on-disk format is going to change yet again from the currently released version. I'm personally interested in it, but not quite enough to use it. :]
Linas> There is also in interesting possibility that offers a middle Linas> ground between raw performance and safety: instead of verifying Linas> checksums on *every* read access, it could be enough to verify Linas> only every so often -- say, only one out of every 10 reads, or Linas> maybe triggered by a cron job in the middle of the night: turn Linas> on verification, touch a bunch of files for an hour or two, Linas> turn off verification before 6AM.
If you're reading the file off disk, it doesn't cost anything to verify it then, esp if the checksum is either in the metadata or next to the blocks themselves.
It's corruption in files which aren't read which turns into a problem.
Martin> All evidence suggests that scrubbing is a good way to keep Martin> your data healthy.
Yup. And mirroring anything you think is important. Disk is cheap, mirroring is good.
Heck, I'd pay good money for a SATA disk which mirrored inside itself or which joined two seperate spindle/head assemblies into one and did all the error correction at a low level.
| |