Slashdot Mirror
Computer Voodoo?
jbeaupre asks: "A corollary to 'Any sufficiently advanced technology is indistinguishable from magic' is that sometimes users have to resort to what I call 'computer voodoo.' You don't know why it works, you barely care how it works, but you find yourself doing the strangest things because it just seems to work. I'm talking about things like: smacking a PC every 5 seconds for an hour to keep it from stalling on a hard drive reformat (with nary a problem after the reformat); or figuring out the only way to get a PC partially fried by lightning to recognize an ethernet card, after booting into Windows, is to start the computer by yanking the card out and shoving it back in (thereby starting the boot processes). What wacky stuff have you done that makes no obvious sense, but just works?"
Usually whenever it would start going on the fritz a good punch or kick to the tower would get it going again. And also stop that damn whirring noise. It always makes me laugh when I'd see people hitting the monitor. Because THAT is where everything is XD
Here's how it works.
:)
IDE drives keep a list of spare sectors to be used if one of the "primary" ones gets damaged. However, if a sector gets damaged and it already contained data, the drive won't reallocate it, because it would have no way of recovering the information. So it keeps "hoping" that some day the data will be readable again, and when that happens, it'll reallocate the sector. However, it never happens.
When you overwrite a defective sector, the drive says "aha! since the user overwrote the information, it means it's not important anymore; so I'll go ahead, mark the sector as bad and replace it with a spare". That's why overwriting gives the drive a chance to remap all bad sectors to clean ones.
This is a trick I learned by reading the documentation on smartd; if SMART reports defective or unreadable sectors, there's a way to figure out which files reside in those sectors and overwrite them with zeroes; the file will of course be lost, but by overwriting you let the drive reassign the sector and everything is peachy again.
By the way, if you reformat the drive with the destructive verification option (-c -c) it's likely that when the test overwrites to verify readability, the same reassigning process will take place; the standard "-c" test is a read-only test that's why you're unable to format a drive without the overwriting procedure.
So you see, not voodoo.
This trick even works non-destructively: dd if=/dev/hda of=/dev/hda bs=512 A friend of mine showed me this method a few years ago and it has helped recover failing drives over a dozen times since.
The hard drives do a dynamic re-mapping of bad sectors to a different area. If you write an entire sector, and the sector was already marked a 'unreadable', the drive has an opportunity of using the 'secret' sector area instead. From then on, reads for this sector will come from the secret area. There are a limited number of secret tracks.
This is one of the 'gotchas' with multimedia content. A hard drive may have fast access times and a fast bus, but if there are persistent CRC errors (and there is quite often CRC errors on a non-failing drive!), then the drive may have to take 15 or so separate reads of the track to reconstruct - It may also temporarily move the surrounding tracks to the secret area, then zero out the surrounding tracks in order to reduce track-to-track crosstalk.
All of this takes time, and quite often any real time media bandwidth budgets get blown when this happens.
The neat thing is, when this does happen, it is never an error. The program does finally get the data, but it just takes longer than expected. Typically one way to find out if the drive has remapped tracks on you is to have a program which measures track to track access time sequentially, and find the track boundaries that take a lot longer than a move from adjacent tracks should.
Jeff
ipv6 is my vpn