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.

--
Grant Edwards                   grante             Yow!  NEWARK has been
                                  at               REZONED!! DES MOINES has
                               visi.com            been REZONED!!

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

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

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