Anyone familiar with badblocks?

[RaceTM]

Hi all,

I bought two identical drives from a friend. They're both 1 tb Seagate drives. I connected both of them, and started badblocks in read-write mode on both drives. After a few hours, one badblocks session slowed down considerably, to the point where it was pretty much not doing anything. The other session finished a while later. I stopped the first one, and now I'm trying it again.

Anyone know what could be happening?

[BradN]

Have any errors appeared in dmesg? I've noticed a situation where a controller/bus glitch will screw up things and make it perform really strangely (I suspect an I/O operation was never fully completed and couldn't be cleared out), but this was in conjunction with software RAID. (insert side rant about some SATA cables with bad connectors)

Also, read-write testing in theory isn't necessary on modern hard drives - if the data can be read everywhere and can be written somewhere, the drive should be fine, but then again your test here has uncovered some problem that might not even be related to the drive itself.

[RaceTM]

As far as I know, the drive won't re-allocate bad sectors unless you're attempting to write to a sector that has been determined to be bad. So doing a read-only test would tell you about sectors that have already been flagged as bad, but it wouldn't necessarily detect additional bad sectors. That's my understanding anyways, but I don't claim to be an expert

There are some messages in the logs, however I'm not sure how to tell which device exactly they're coming from. Is ata2 supposed to be sdb?:

[BradN]

Yeah, that should be sdb. With the ICRC error, try replacing the cable or swapping it with the other drive's if you don't have another.

You're right that a bad sector won't get reallocated when you do a read-only scan, but all of them will be detected - the drive is performing a checksum (actually ECC in modern drives) on all sectors, and it will know immediately when the data isn't making sense (unless it's a very small defect that just happens to be reading ok, but I've never known this to happen in my experience).

Once it's detected it should be reallocated when something is put there (the drive may do some tests on that sector to see if it's really bad - unexpected power-off can cause data to be written wrong which would mimic bad sectors). Filesystems generally have a policy of never reading places they haven't already written to so bad sectors shouldn't be a problem after performing a read-only scan, but I usually like to manually overwrite them first until badblocks comes back clean and then begin using the drive, just to be certain.

[mbar]

run "smartctl -t offline /dev/sdX" on both of them, and yes, replace the SATA cable -- I had much the same problem some years ago and it wasn' the disk, but broken cable.
After the test is finished, use "smartctl -a /dev/sdX" to see the log and disk health.

[RaceTM]

Thanks guys. I doubt the drive has any issues but I will definitely replace the cable and see what happens. I have already run the smart tests on both drives and they came back clean. I'll report back if I continue to see problems!

[BradN]

Note that when using smartctl -a, ignore the drive health assessment (I have a feeling it will still say healthy even if the drive is on fire), and instead look at the reallocated sector count (but some drives always show 0 there and show a similar category below with the real number). This will give you a good indication of the media status, and when you have similar drives you can compare the other values between them to see if something else looks out of whack. Excessively long spin-up time could be an indication of a failing spindle motor, and excessive seek errors could be the beginning of failure in the head actuator or symptom of vibration, both of which are bad news.

In your case ignore the CRC error count since it's probably being thrown off by a bad connection/cable.

[RaceTM]

Alright, well once again the drive is doing the same thing. Re-ran badblocks, it got through two passes, and it is now slowing to a crawl. dmesg logs are filled with errors happening right now:

[RaceTM]

I don't trust this system. It's given me too many weird problems. I'm now testing the drive in another system....

[drescherjm]

Having a non zero UDMA_CRC_Error_Count is a sign of a bad sata cable or interface.
_________________
John

My gentoo overlay
Instructons for overlay

[RaceTM]

Well, I'm sick of trying to fix this machine with old parts, half of which I don't even know the condition of. This latest problem (sata issues) just put me over the edge. The onboard sata doesn't work, the sata card I'm pretty sure works causes these crc errors, and when I plug in my other sata card (which does work, its brand new), the machine doesn't even post.

So I just came back from the store...new barebones going in.

Thanks for the help, all