Live data from Hacker News

Silent Data Corruption Is Real

changelog.complete.org

11–20 of 154 posts

Re: Silent Data Corruption Is Real

#11

I'm not a database expert, but this seems like something I should worry about, at least a bit. Is this a problem if you store all your persistent data in a database like MySQL?

If your database does ZFS-like checksumming on all of its data, including the structures that it uses to find the data that you put in, and has the ability to correct errors, then no.

Realistically though, I don't know if MySQL has this. You'd probably be better off using a filesystem that gives these kind of guarantees and running your database on that.

Re: Silent Data Corruption Is Real

#12
The exact same silent data corruption issues just happened to my 6 x 5TB ZFS FreeBSD fileserver. But unlike what the poster concluded, mine were caused by bad (ECC!) RAM. I kept meticulous notes, so here is my story...

I scrub on a weekly basis. One day ZFS started reporting silent errors on disk ada3, just 4kB:

    pool: tank
   state: ONLINE
  status: One or more devices has experienced an unrecoverable error.  An
          attempt was made to correct the error.  Applications are unaffected.
  action: Determine if the device needs to be replaced, and clear the errors
          using 'zpool clear' or replace the device with 'zpool replace'.
     see: http://illumos.org/msg/ZFS-8000-9P
    scan: scrub repaired 4K in 21h05m with 0 errors on Mon Aug 29 20:52:45 2016
  config:
          NAME        STATE     READ WRITE CKSUM
          tank        ONLINE       0     0     0
            raidz2-0  ONLINE       0     0     0
              ada3    ONLINE       0     0     2  
I monitored the situation. But every week, subsequent scrubs would continue to find errors on ada3, and on more data (100-5000kB):

  2016-09-05: 1.7MB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-09-12: 5.2MB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-09-19: 300kB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-09-26: 1.8MB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-10-03: 3.1MB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-10-10: 84kB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-10-17: 204kB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-10-24: 388kB silently corrupted on ada3 (ST5000DM000-1FK178)
  2016-11-07: 3.9MB silently corrupted on ada3 (ST5000DM000-1FK178)
The next week. The server became unreachable during a scrub. I attempted to access the console over IPMI but it just showed a blank screen and was unresponsive. I rebooted it.

The next week the server again became unreachable during a scrub. I could access the console over IPMI but the network seemed non-working even though the link was up. I checked the IPMI event logs and saw multiple correctable memory ECC errors:

  Correctable Memory ECC @ DIMM1A(CPU1) - Asserted
The kernel logs reported muliple Machine Check Architecture errors:

  MCA: Bank 4, Status 0xdc00400080080813
  MCA: Global Cap 0x0000000000000106, Status 0x0000000000000000
  MCA: Vendor "AuthenticAMD", ID 0x100f80, APIC ID 0
  MCA: CPU 0 COR OVER BUSLG Source RD Memory
  MCA: Address 0x5462930
  MCA: Misc 0xe00c0f2b01000000
At this point I could not even reboot remotely the server via IPMI. Also, I theorized that in addition to correctable memory ECC errors, maybe the DIMM experienced uncorrectable/undetected ones that were really messing up the OS but also IPMI. So I physically removed the module in "DIMM1A", and the server has been working perfectly well since then.

The reason these memory errors always happened on ada3 is not because of a bad drive or bad cables, but likely due to the way FreeBSD allocates buffer memory to cache drive data: the data for ada3 was probably located right on defective physical memory page(s), and the kernel never moves that data around. So it's always ada3 data that seems corrupted.

PS: the really nice combinatorial property of raidz2 with 6 drives is that when silent corruption occurs, the kernel has 15 different ways to attempt to rebuild the data ("6 choose 4 = 15").

Re: Silent Data Corruption Is Real

#13
post #3

It really bugs me (and has for a while) that there is still no mainstream linux filesystem that supports data block checksumming. Silent corruption is not exactly new, and the odds of running into it have grown significantly as drives have gotten bigger. It's a bit maddening that nobody seems to care (or maybe I'm just looking in the wrong places) (...sure, you could call zfs or btrfs "mainstream", I suppose, but whe…

What would you do with a failed checksum on a filesystem level? These errors could be and likely to be transient too.

Re: Silent Data Corruption Is Real

#14

I'm not a database expert, but this seems like something I should worry about, at least a bit. Is this a problem if you store all your persistent data in a database like MySQL?

If your database does ZFS-like checksumming on all of its data, including the structures that it uses to find the data that you put in, and has the ability to correct errors, then no. Realistically though, I don't know if MySQL has this. You'd probably be better off using a filesystem that gives these kind of guarantees and running your database on that.

Every ACID compliant database is supposed to calculate checksums.

Re: Silent Data Corruption Is Real

#15
post #6
post #3

It really bugs me (and has for a while) that there is still no mainstream linux filesystem that supports data block checksumming. Silent corruption is not exactly new, and the odds of running into it have grown significantly as drives have gotten bigger. It's a bit maddening that nobody seems to care (or maybe I'm just looking in the wrong places) (...sure, you could call zfs or btrfs "mainstream", I suppose, but whe…

Btrfs has experienced some data loss bugs in recent memory. It looks like ZFS is the only remaining option. https://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Da... https://www.spinics.net/lists/linux-btrfs/msg59190.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...

Yes I have tried to use btrfs several times for work projects and personally because I was very excited about it but every time I have ran into severe bugs even though it was said to be "stable". I have given up for now, maybe I will check back in a couple more years.

Re: Silent Data Corruption Is Real

#17
Oh, yes. Silent bit errors are tons of fun to track down.

I spent a day chasing what turned out to be a bad bit in the cache of a disk drive; bits would get set to zero in random sectors, but always at a specific sector offset. The drive firmware didn't bother doing any kind of memory test; even a simple stuck-at test would have found this and preserved the customer's data.

In another case, we had Merkle-tree integrity checking in a file system, to prevent attackers from tampering with data. The unasked-for feature was that it was a memory test, too, and we found a bunch of systems with bad RAM. ECC would have made this a non-issue, but this was consumer-level hardware with very small cost margins.

It's fun (well maybe "fun" isn't the right word) to watch the different ways that large populations of systems fail. Crash reports from 50M machines will shake your trust in anything more powerful than a pocket calculator.

Re: Silent Data Corruption Is Real

#18
post #14

Earlier quoted context omitted.

If your database does ZFS-like checksumming on all of its data, including the structures that it uses to find the data that you put in, and has the ability to correct errors, then no. Realistically though, I don't know if MySQL has this. You'd probably be better off using a filesystem that gives these kind of guarantees and running your database on that.

Every ACID compliant database is supposed to calculate checksums.

Good to know.

Re: Silent Data Corruption Is Real

#19
post #3

It really bugs me (and has for a while) that there is still no mainstream linux filesystem that supports data block checksumming. Silent corruption is not exactly new, and the odds of running into it have grown significantly as drives have gotten bigger. It's a bit maddening that nobody seems to care (or maybe I'm just looking in the wrong places) (...sure, you could call zfs or btrfs "mainstream", I suppose, but whe…

Making data on individual drives is probably not a long term goal for integrity. It is more likely that multi homing data in geographically disjoint locations with some sort of syncing is a better long term goal. Fixing silent data corruption on a single drive doesn't solve any of the much more likely disasters, like fire, flooding, weather, etc. Not even datacenters can withstand lightning.

Re: Silent Data Corruption Is Real

#20

Shouldn't RAID 1,5,6 protect against data corruption because of disk errors?

Some disk errors, yes, but something as simple as a power failure can easily corrupt your data:

http://www.raid-recovery-guide.com/raid5-write-hole.aspx

https://blogs.oracle.com/bonwick/entry/raid_z

Post reply on HN