I made a drive image of an SSD using dd a while back. I had to go back to the image to do a repair, and something is wrong with the image. When put back on the SSD and a boot is attempted, Windows7 won't boot. I check it with linux and it says the main NTFS FS is corrupted. I run fixes on it and I can mount it and look at many files, but every 50 or so files generates an I/O error when listing the directory entry, let alone trying to read the file.
I do these types of images all the time and consider myself an expert at it, and never have these types of problems (even on source disks that are already dying).
One of the only things I could come up with is I noticed while doing this image restore that the customer (who built it themselves) had used a SATA2 cable on a 6Gb/s SATA3 port (and the SSD is 6Gb/s). Could this have caused corruption of data "on the wire"? Is that even possible? Would wire-caused errors be detected by the mobo, or is it just the drive that does checksums? Do 6G mobos and drives detect when a 3G cable is used and downshift to 3G?
The system seemed to run fine for a year setup this way, so perhaps the errors are very infrequent but doing the image at full-blast reading the whole 120GB in a few mins caused this problem?
The SSD died (actually, is dying) 3 weeks after the image was made, so there is also a chance the drive was just screwing up already and giving me back bad data. However, the customer had no problems with Windows during the 3 weeks until I/O started showing up in Windows.
Lastly, can a mis-wiring like this kill an SSD? This is an OCZ Vertex 420 drive (a brand I don't sell, but they bought elsewhere) and we already have RMA'd the drive once, and it definitely is dead a 2nd time now. Either OCZ SSDs suck bad, or perhaps something else is going on? Perhaps a mis-wiring can cause the SSD to detect errors and request re-dos from the OS causing a multiplication of writes? Just guessing here. Most likely the OCZ just sucks rocks. I read some other people on the net having real big problems with dying OCZ SSDs.
I answered my one of my own questions with a few tests:
Using a SATA2 3Gb/s cable on a 6G port and 6G drive results in 6G speed selected (with modern 2 year-old Intel ICH anyhow). Yikes!
root@sysresccd /root % smartctl -a /dev/sda |grep -i sata SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
As for spurious corrupted data on the wrong cable, my tests so far have been inconclusive (and a bit bewildering). It would seem dying SSDs can spit back wonky data even when they aren't reading the sector that is damaged!
I think it was OCZ that had a bunch of problems with the controllers in those SSDs going bad. If you're controller is going wonky it's probably anybody's guess as to how it's going to behave.
-- Wyatt Zacharias
On Fri, Oct 31, 2014 at 5:48 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
I answered my one of my own questions with a few tests:
Using a SATA2 3Gb/s cable on a 6G port and 6G drive results in 6G speed selected (with modern 2 year-old Intel ICH anyhow). Yikes!
root@sysresccd /root % smartctl -a /dev/sda |grep -i sata SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
As for spurious corrupted data on the wrong cable, my tests so far have been inconclusive (and a bit bewildering). It would seem dying SSDs can spit back wonky data even when they aren't reading the sector that is damaged! _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-
Trevor Cordes -
Wyatt Zacharias