Bad sectors, S.M.A.R.T., SpinRite, firmware on platter and drive id questions

bad-blocksdata-recoverysmart

  1. Is it possible for S.M.A.R.T. to give false readings (say I was fiddling with lots of recovery programs, transfers, so on and so forth) or is it absolutely a read-only direct correlation to the physical status of a drive?

  2. Does SpinRite level 5 "recover bad sectors" operate on those marked at the factory? Are they on the same level as your generic bad sector, with SpinRite thus having full access?

  3. The main firmware of (many?) drives, like a WD Passport is stored on the platter. How is it protected? Might SpinRite's sector recovery corrupt it?

  4. Is the failure of a drive to report valid identity information (hdparm -I /dev/xx) consistent with corrupted firmware, or just general disk failure? I may be misunderstanding the role of firmware here. I feel I've read a drive's identity information is on the platter, just like the partition tables and so on. Is this true?

Best Answer

  1. Smart records a large number of values on the disk. For each value there is a limit before errors are reported. If you are getting smart errors your disk is most likely in a bad shape, but smart is not guaranteed to give a warning. Some types of abuse (starting and shutting down the disk very often) can give early smart errors.

  2. I don't know what interface SpinRite uses against the disk. There are on some disks a factory interface used when producing the disks, but I don't think the disks exposes this without special hardware. Otherwise it can only read/write the standard drive parameters, and not easily access blocks marked as bad by the firmware.

  3. No disk (after IDE) stores the whole firmware on platter. Because it needs a firmware to read the platter. Disks before IDE/SCSI some times did not have firmware. I see no reason to store firmware on platter.

  4. The information about the disk geometry and such is stored in firmware on chip. Failure to report it can be a sign of a dead disk, but also communication problems with the disk (for example a master/slave conflict).

If the disk can't report geometry you will usually not be able to read it anyway. In those cases I typically recommend restoring from backup... Because you do have backup, right?

Related Topic