best filesystem for CF on linux

I've read that too.  Unfortunately, it wasn't in the vendor
provided specs for the CF cards.  Sandisk published a
white-paper on how to estimate CF lifetime, and it was quite
clearly based on the assumption that no wear-levelling was done
by the controller in the CF card.

The answer you get from the SanDisk is very sensitive to the
number of spare sectors -- and nobody will spec that either.



Nope. I've been trying to figure out the answer to your
question for a couple years now, and I'm no closer than when I
started.  If you do find out anything, let the rest of us know.

There are (at lest) two issues with CF cards in embedded systems:

1) Wear leveling:
AFAIK, most of the cards use spare blocks and replace worn out blocks
when the write time gets too long. Maybe some cards use a better
algorithm (round robin type of stuff). It does not make sense to use a
file system handling wear leveling on top of a card, as same does not
know about the hardware block boundaries (which may well be completely
unexpected due to the cards controller).

2) When power fails during a write cycle a CF card can die or loose all
it's data. (The controller night do some "wild" stuff on any write
cycle, concerning any data and control information the card holds.) So
in a data acquisition system you will need to supply an accumulator or a
huge capacitor (I saw same with several 1000 F) and shut the system
gracefully down after a completed write cycle.

-Michael

Since most card sellers (including Sandisk) are fabless (or mostly fabless),
the actual chips might be coming from the same sources.  In another word,
build your system with the lowest spec from the industry.



This wear leveling stuff came from unconfirmed sales people.  I.e. Vapor?



Unless you have very sophicated power routing, the cap needs to power the
rest of your system as well.  You still need a power fail detection circuit
to do it right.  In that case, you don't need such a big cap.  The cap is
for noise filtering.  Again, the big cap could be for peace of mind of the
customers, offer by the sales people.



The only solution we offer is to mount the system drive read-only.  Perhaps
with a separate data drive.

IDE compact flash drive
http://ide-cf.info-for.us

What do you mean by this ? There is no source needed. The facts are:

1) there are Linux file systems that handle wear leveling for flash
chips (e.g. JFFS).
2) To do this they need to know what blocks are to be erased as a whole
3) When using a flash card you don't know the size and location of these
blocks

obvious consequence: don't use such a file system with flash cards.

-Michael

Perhaps a "data acquisition" version of your adapter that handles the
"power down on writing" problem would be a good idea for many embedded
Linux applications. I suppose such an adapter would need a capacitor and
a small fast low power processor (e.g. 2022, same has a "parallel slave
peripheral interface" that easily emulates an IDE bus peripheral) and a
bit of static RAM. It could do some kind of cashing and delayed write to
improve whereat effects with file systems that use an FAT or something
similar writing the same blocks again and again. I suppose some 256 K
RAM would help a lot. Writing could be delayed for a long time (several
minutes or even hours after the last write to a block, as long as the
cache is not full). The capacitor would need to last until the complete
cache is written. I think a button that disables the drive and allows
the user to unplug the CF would be good.

-Michael

Yes, we are looking into the 1.8V version of the tiny AVR microcontroller.
It can monitor the power source and deactiviate the signal lines
(CS, Read and Write) when power drops below 4V.  

Actually, if the designer of the power supply did their work, a power down
signal would help quite a bit.



You are suggesting that the microcontroller takes over the IDE functions.  
We are thinking more in terms of passively controlling the signal lines.



IDE compact flash drive
http://ide-cf.info-for.us

IMHO this $7 processor would give you great advantages here. It runs 180
Me instructions per second, so I suppose it's fast enough to emulate the
interface at the IDE site (with included hardware help of the
"Peripheral Slave interface") and the card site. 64 K code flash should
be enough for the task. It includes 20 K RAM, so the a small (but maybe
sufficient) version said write cache could be done without adding a RAM
chip. (Additionally adding no more than just an outlet you can provide
an Ethernet interface for the host through the same channel :-) )

IMHO just preventing write fast enough is only part of the picture. To
provide decent support for a data acquisition device a write cache for
wear out prevention is necessary. This needs a data handling by a
processor and a capacitor big enough to allow for writing the cache on
power down.

I really am thinking about using the processor (which I currently use
for several non-Linux projects) as such a "a PC-card helper" in a
planned Linux project.

-Michael