Re: amd64 sata_nv (massive) memory corruption

["John Stoffel" <john@stoffel.org>]

>>>>> "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.