title: What causes Silent Data Corruption on HDDs?
body: <p>Some landmark <a href="https://www.google.com/search?q=hard%20drive%20corruption%20study" rel="noreferrer">studies</a> a number of years ago now showed that <a href="https://en.wikipedia.org/wiki/Data_corruption#Silent_data_corruption" rel="noreferrer">silent corruption</a> in large datasets was far more widespread than previously anticipated (and today I guess you'd say it's <a href="http://www.zdnet.com/article/data-corruption-is-worse-than-you-know/" rel="noreferrer">more than commonly realized</a>).  </p>
  
  <p>Assuming that the application and OS wrote a sector and had time to let everything flush, with no crash or abnormal shutdown, or software bugs that would command wrong data to be saved.</p>
  
  <p>Later, a sector is read back in, and there is no read error from the HDD.  But it contains the wrong data.</p>
  
  <p>Since HDD data encoding contains error correction codes, I would assume that any mysterious state change to a bit would generally be noticed by the checking.  Even if the check is not very strong so some errors slip through, there would still be vastly more detected errors that tell you something is wrong with the drive.  But that doesn't happen:  apparently, data is found to be wrong with no symptoms.  </p>
  
  <p>How can that happen?</p>
  
  <p>My experience on a desktop PC is that sometimes files that were once good are later found to be bad, but perhaps that is due to unnoticed problems during writing, either moving the sectors or in the file system tracking of the data.  Point is, errors may be introduced at write time where data is corrupted inside the HDD (or RAID hardware) so wrong data is written with its error correction codes to match.  If that is the (only) cause, than a single <em>verify</em> should be enough to show that it did write OK.</p>
  
  <p>Or, does data go bad after it has been seen to be OK on the disk?  That is, verify once and all is fine; verify later and an error is found, when that sector has not been written in the interim.  I think this is what is meant, since the write-time errors would be easy to deal with through improved flushing checking.</p>
  
  <p>So how can that happen without tripping the error correction codes that go with the data?</p>