Hard drive protection

Posted Oct 14, 2005 21:08 UTC (Fri) by zblaxell (subscriber, #26385)
Parent article: Hard drive protection

I can see the bug reports now:

Bugzilla #121314: hdapsd failed to park heads last week

Description:
Last week my laptop fell off of the table due to its power cable becoming entangled with the resident feline. According to the debugging log, the specific sequence of accelerations as the laptop bounced off of first the cat, then the table leg, then the floor, then down the stairs, was analyzed by the Bayesian classifier and determined to be 95% likely to be "harmless accelerometer noise" and the hard disk heads were not parked. Unfortunately, when the laptop hit the bottom step and slid across the floor to the wall, the final impact caused the disk heads to slam into the journal area of the filesystem, destroying both completely. Fortunately I recorded the incident with several high-speed video cameras that I just happen to have distributed throughout my house, and I was able to precisely measure the distances travelled by the laptop using the black-and-white square tiles on the floors and walls, which are all exactly 27.6cm on a side.
Now that I've replaced the hard disk and restored my backups, I can now get online, open this bug and attach the video files for some open-source guru to analyze.

I too am wondering what the hard disk manufacturers are thinking. There is at least one (sometimes three or more) embedded CPU inside a hard disk which could process the accelerometer data using code and algorithms written by people who actually have the equipment to test and debug them. If there's room for the sensor device in the drive controller board and chipset, there's room for the code and data to process its output too.

What's next? Do we start moving the ECC, DSP, or servo control functions out of the drive and into the host CPU? Modern host CPU's are certainly capable of doing the data processing (at least the parts that can tolerate high latency), it would save a few cents per disk to reduce the specs of the embedded controller a little, and users who buy the cheapest disk available at any given time wouldn't notice. XT hard disks used to do even the highly latency-sensitive operations (remember sector interleaving?) in the host CPU, so it's not a new idea. Heck, last time I checked, the Microsoft family of operating systems still supports the sector interleave parameter for formatting disks...

IMHO subsystems like this (including other things like fan controllers and CPU temperature sensors should not depend on the host CPU at all. The host CPU is busy doing other things, thank you very much, and may not always be able to respond to a whiny little sensor nobody has ever heard of, even if that sensor is warning of imminent destruction. This is why good laptops have embedded controllers with their own CPU, memory, and a sane policy in firmware. It's always nice to be able to control these things from the host OS, but a sane system design never requires it.

What happens to one of these disks if the host CPU's OS locks up, and the frustrated user throws the laptop at a nearby wall? ;-)