We have information from a Compact Flash manufacturer that says you should have hardware to solve this problem - I do not believe there is a software solution. The problem is caused by the fact (as you state) that CF stores metadata in the flash blocks along with the disk block data. If the metadata is corrupted by an aborted write, it can affect all of the disk blocks stored in the flash block, and the metadata can even be so corrupt that you lose unrelated blocks. Our most common scenario for failure is to lose disk block #0, which, of course, is the boot block for our OS. We solve this using hardware. You need to use buffers to disconnect the CF's ATA reset, output-enable and write-enable signals from their source on the bus, and hold up DC power to the pull-ups, the buffers and the CF itself for at least 10ms-20ms after detecting the imminent loss of power. This is being implemented in our new hardware designs, and we have not yet gotten one back from fabrication to test. But it sure looks like it will work to solve the problem. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of tyson@irobot.com Sent: Monday, November 24, 2003 4:47 PM To: LinuxBIOS Subject: Off topic CF questions
This is a bit off topic, but I need some pointers and we seem to have quite a few really smart people on this list. ;-)
I'm trying to learn about the issues and solutions to using CF cards for
data logging in appliances where the power may be pulled at any time.
There are sort of two classes of logging. One would be classic "write only" logging. The other would be things like total run time, an odometer, that sort of thing where you might want to something that amounts to erase the old value and over write it with a new one. Obviously the second case would degenerate a bit with at least "double buffering" and could get as "bad" as a "write only" log history.
I say write only, meaning that the download/reset/erase procedure could be under controlled conditions and not a concern.
My issue is that CF cards present and IDE abstraction that hides the underlying block sizes and the fact that FLASH is erased as a block (and
unknown block) and rewritten from scratch. I have absolutely no idea what size these blocks are such that I might separate my "read-only" partitions from my "write only" partitions with a buffer partition. I also have absolutely no idea what happens to these things when the power
is pulled, esp. in the middle of an erase/write cycle or how these erase/write cycles might be optimised.
Any pointers or suggestions would be greatly appreciated.
Thanks! Ty