Tweet
FYI: Bad cable causes spurious drive errors
Just a little something to increase my post karma.
I was preparing a brand new 750 GB WDC Scorpio Blue (WD7500BPVT) 2.5" hard disk to install in place of my 3+ year old 500 GB 3.5" hard disk.
On my first attempt, I was able to partition the new disk using gdisk. However, attempting to format it using mke2fs resulted in apparent drive media errors. A check with smartctl resulted in a FAILED READ error. That is, smartclt wouldn't even complete any of its tests (e.g. long, short, conveyance). The OS (kernel 2.6.38) even hung, dropping me to the text-mode only console.
I was prepared to return the disk for warranty replacement (since it was brand new anyway), when I decided on a whim to replace the SATA data cable I used to connect it to the motherboard, and voila, I managed to reformat the drive successfully with gdisk and mke2fs.
Or almost: mke2fs and e2fsck reported the presence of bad blocks in one partition. My suspicion was that this was an "error" caused by my earlier attempt to format the partition (using the bad cable). To test my theory, I used ddrescue (plain dd and shred would probably work as well) to overwrite the (as yet empty) bad partition with zeros. That is, "/sbin/ddrescue /dev/zero /dev/sdbX" with the optional --force flag.
A subsequent format by mke2fs resulted in a partition with no apparent bad blocks.
I'm now running the smartctl "long" test on the drive to see if it's really error free. Prior to this I'd formatted all partitions using mke2fs with the -c flag (check).
Hope somebody finds this useful ...
I was preparing a brand new 750 GB WDC Scorpio Blue (WD7500BPVT) 2.5" hard disk to install in place of my 3+ year old 500 GB 3.5" hard disk.
On my first attempt, I was able to partition the new disk using gdisk. However, attempting to format it using mke2fs resulted in apparent drive media errors. A check with smartctl resulted in a FAILED READ error. That is, smartclt wouldn't even complete any of its tests (e.g. long, short, conveyance). The OS (kernel 2.6.38) even hung, dropping me to the text-mode only console.
I was prepared to return the disk for warranty replacement (since it was brand new anyway), when I decided on a whim to replace the SATA data cable I used to connect it to the motherboard, and voila, I managed to reformat the drive successfully with gdisk and mke2fs.
Or almost: mke2fs and e2fsck reported the presence of bad blocks in one partition. My suspicion was that this was an "error" caused by my earlier attempt to format the partition (using the bad cable). To test my theory, I used ddrescue (plain dd and shred would probably work as well) to overwrite the (as yet empty) bad partition with zeros. That is, "/sbin/ddrescue /dev/zero /dev/sdbX" with the optional --force flag.
A subsequent format by mke2fs resulted in a partition with no apparent bad blocks.
I'm now running the smartctl "long" test on the drive to see if it's really error free. Prior to this I'd formatted all partitions using mke2fs with the -c flag (check).
Hope somebody finds this useful ...