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

[Nate Duehr]

Jim Ockers wrote:
> Hi Cluebies,
> 
> I'm not sure what to do about this problem.  I'm hoping someone
> on the list has some ideas about how to fix it.  This e-mail is 
> long but thorough.
> 
> We have a Via motherboard with an IDE interface and a compactflash
> socket that makes CF cards act like IDE disk drives.  (I.e., /dev/hdd)
> The IDE controllers are on IRQ14 (primary) and IRQ15 (secondary).

[snipped good big explanation of problem... GRIN...]

Jim, thoughts:

-----------
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.

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.

------------
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...

-------------
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.

(Sorta vague, I know... but "as often as necessary" really depends on 
the app and whether or not you can handle a sudden power outage and come 
back online in some "sane" state even if you lost the data.  Data like 
user settings would have to be copied to the CF card immediately, where 
things like logs or other things could be done slowly to avoid excess 
writes to the CF card.)

If you have enough RAM in the devices to mount a RAM disk at boot time 
and then chroot into it as part of your normal startup, it might be 
worth looking into.

You gain speed (CF is slowwwww as a "disk"), and you lose the IRQ 
problem completely except during configuration and/or logging writes to 
the CF card, because you eliminate most writes to the CF card, extending 
its life span to many many years, probably.

-------------
You could do BOTH as well, extending the life of your card but also 
running from RAM disk most of the time...

How to deploy the above in the field on systems already "out there"... 
now that's an interesting challenge!

Disclaimer: The last time I played with jffs2 was a few years ago, I 
don't think there's been anything "better" done for CF filesystems, but 
maybe there has.

Nate
_______________________________________________
CLUE-tech mailing list
CLUE-tech at cluedenver.org
http://cluedenver.org/mailman/listinfo/clue-tech