Karl Bongers wrote:
On Thu, Jan 22, 2004 at 10:51:00AM -0600, Richard Smith wrote:Our most common scenario for failure is to lose disk block #0, which, of course, is the boot block for our OS.Well that would be a drag, that block #0 is nice to have around.
Yeah according to a SanDisk FAE I spoke with if you can zero that block with direct writes then you could reclaim the disk. The problem is that there is not an easy way to write zeros to the section once block 0 starts throwing a CRC error. Dos, windows, and linux all want to read block 0 before they let you do anything with that device. Since the read fails its as if the device never exists. So you can't use any disk edit tool or dd, etc to write to it.
I read that by using the IDE Taskfile IO support you can issue block reads and writes to an IDE device below the filesystem layer which would be the only OS based way to fix them. My current solution is to pop them into our cannon digital camera and have it re-format the device. It's fixed most but not all of our disks with errors. The drawback is that you lose all the info.
At least you don't have head crashes, my hope is that CF is at least as reliable as HD given limited controlled writes. For my application I'm looking at logs that grow about 4MB/month(log every 5 minutes about 350 bytes). They are erased every 3 months.
If you don't have an enviroment where you can lose power often then CFs will work nicely. I have kind of a worst case in my bring up of new hardware where the power rails could be all over the map depending on if I happen to short something out with the scope probe or plug a cable in backward or the system hangs such that I have to turn it off to reset it.
-- Richard A. Smith rsmith@bitworks.com