Those hex graphics look familiar.
Amazing how, my blog from 10 years ago is still relevant today.
Yes, and believe it or not, I participated in the grc development and I showed him the exact same image and suggested to SG, when you 'recover' a sector look at entropy of the sector before and after it, and then compare to what you have recovered. This will give a pretty good idea if what you have 'recovered' isn't actually random nonsense. The self proclaimed guru ignored this.
I also urged him several times, to write recovered data to a different drive. This isn't that hard I know because I have written DOS based data recovery software too and the destination drive was just a simple parameter I passed along with a write command. So it could be the source drive or some other drive. I believe that coding this 6.1 update took several years, adding the option to write to a different drive should have been achievable and would have made so much difference!
Anyway, during course of development he had several, how do you call this, phenomena he ran into which he initially explained in the way he so often does, as 'conspiracies' as if hard drives were hiding certain things from us, that they wrote corrupt data without telling us, how they were not telling us about failed reads etc.. I immediately explained to him that cause of corruption could be somewhere else, not the hard drive, and that hard drive may actually believe it's writing correct data. I told him so several times even .. It's a known phenomena and it's called silent corruption.
It goes like this: if I read from a drive and place it in a buffer (RAM) and the data is corrupted while in the buffer, and I then write it back, the drive computes a new ECC over what I write back. As far as the drive is concerned this is valid data and there's no reason to report errors. And this is exactly what the 'guru' ran into but failed to reach the correct conclusion initially. Instead he blamed the drive. (they're lying to us and I SG am on to them!!) When he finally was forced to change his view because a mem test on that PC where this was observed revealed memory issues he adopted it, hyped it, and added this lame memory check to SpinRite.
During development, which I followed closely, I basically offered what I know about data recovery but I was largely ignored. That's okay, but then I come to certain conclusions along the way. For example I observed how 'testers' despite the advice not to run SpinRite on SSDs, did so anyway and observed improved performance. Everyone was surprised, not me as this can be easily explained by tons of research papers. I told him he was simply reading 'cold' (slow) data that weakened over time due to imperfect retention and that if you simply re-write the data it solves the issue. Modern drives do this by themselves because it's a known phenomena.
And so I did and slowly SG's stance on SSDs changed and then he began explaining the observation as if he understood what was happening, which was demonstrably wrong (he blamed read disturb). When I did a blogpost on what I observed and basically reached the conclusion he's no expert and hard drive guru at all, Now he's using this as selling point for SpinRite, and using it to 'prove' his snake oil is still relevant today.
FWIW read-disturb is a real thing, but several research papers (which I shared with him) identify retention as the biggest factor. Simply put, we can:
- Measure if bit errors are a result of increased cell charge (disturb errors, they force extra electrons into neighboring cells) or decreased charge (retention errors, charge leaks from cells and once below critical threshold the value of the cell flips).
- We can examine by experimenting .. We take NAND and age it (by p/e cycles) so we can observe anomalies easier. We then compare effect of read disturb by writing to specific cells, say 10000 times and observe effect on neighboring cells .. Or we let same artificially aged NAND just sit after writing data .. It turns out just letting data sit is as 'effective' as thousand and thousands of p/e cycles. There's no comparison, retention is the biggest factor unless we unleash unrealistic amounts of p/e cycles on neighboring cells (which may be realistic in some specific scenarios but no on the average Joe's PC).
SG ignores this and he does because 'he knows' .. After all he's the guru ..
I participated in his newsgroup with the hope to convince him to write recovered data to a different drive and shared some of my observation along the way. I am glad I did because I now know SG is nothing but a phoney to put it mildly. He BTW has now blocked me from accessing any of his websites (I guess he never heard of VPNs).
