[clue-tech] Bad IDE hardware + compactflash, what to do?

[marcus hall]

On Thu, Dec 15, 2005 at 04:55:47PM -0700, Nate Duehr wrote:
> CF as an IDE device will surely "kill" the CF eventually.  CF is rated 
> for a fairly low number of read/writes per location before it fails, if 
> compared to say, a hard disk.  It's a LOT of them, but it's still much 
> lower than any other magnetic media.
 
Last I have heard, CF is typically rated for 400,000 writes to each block.
But, there are also spare blocks and extra blocks that are cycled through
to increase the cycle time.  A typical strategy guarantees 8 spare blocks
per 4MB, so writing the same block repeatedly would cycle through 9 physical
blocks.  Writing to more blocks within each 4MB region would cycle through
more blocks, giving even more "wear".

> They'll last a long time, but things like swap that write to the same 
> locations over and over and over will "burn out" that portion of the CF 
> card fairly quickly... measured probably in years, but...
> 
> If you have swap mounted on CF - watch out for alerts of bad sectors 
> after a couple of years.

Agree there..  Most embedded systems run without any swap (or so I believe).
 
> I've seen the above problem handled in two ways with IDE/CF-booted 
> embedded machines, and at least one of the ways would also help you with 
> your IRQ problem.
> 
> One way is the method that handhelds.org uses on the Linux PDA's... 
> their jffs2 filesystem.  (Journaling Flash Filesystem 2)  It's 
> specifically designed to "spread out" the physical write locations over 
> the entire CF card, thus extending its life.
> 
> jffs2 also has the added benefit of on-the-fly compression... saving you 
> precious flash space...

I do not believe that you can run jffs2 on a CF device.  The CF device
itself emulates an IDE drive, and jffs2 is connected to the MTD device
driver, which works with NOR flash devices (and NAND devices as well, now),
but I don't believe that you can run it on an IDE or IDE-like device.

> The second idea is much neater/cleaner if your code can do it... and you 
> have a way of "getting there" on the devices already deployed to the 
> field...
> 
> Mount the CF card only long enough to read the ENTIRE filesystem into a 
> RAM disk.  Then run from RAM disk with a process of your own creation 
> that copies any data that needs to be saved to the CF, only as often as 
> necessary.

But then you burn up a lot of RAM to hold your filesystem in.  Certainly
if you have the RAM to burn, that is an option, and it gives you fast
access.

Another option is to use cramfs, which compresses the data onto the flash.
It is a read-only file system, so there aren't any issues with writing
to the flash.  It is a bit slower for initial access, since the data
must be read from relatively slow FLASH on the first access, and then
it must be decompressed.  But, if you have the RAM to spare, the data will
stay in the block cache and be readily available on the next access.  Any
data that is rarely accessed in the filesystem will not be sitting in
RAM (or will be eventually discarded in favor of something else that is
referenced).

Of course, you may want some data that can be written, so you may have some
space in the flash as an ext2 or ext3 filesystem.  Appropriate symlinks
from the cramfs partition into the volatile partition allow you to remap
certain files or directories from the cramfs to the extX filesystem.  Be
sure to mount the filesystem with the "noatime" option to keep from rewriting
inodes every time a file is accessed (you probably don't really care about
atime on the files).

-- 
Marcus Hall
marcus at tuells.org
_______________________________________________
CLUE-tech mailing list
CLUE-tech at cluedenver.org
http://cluedenver.org/mailman/listinfo/clue-tech