Which Filesystem is Best for CompactFlash?

HungWeiLo asks: "We're currently using a Debian-based distribution for an embedded device where we're placing our primary kernel and filesystem on a 1GB CompactFlash card. The kernel will be placed in a read-only partition, while the other partition will be used for logging actions in the system and hosting a flatfile database. The concern here is the need to journalize the data (ext2 corrupts pretty badly since we power it on and off), and the need to minimize thrashing of the CompactFlash (we're using industrial-strength, million-write-cycle+ versions, but that can quickly get us into trouble if the filesystem constantly writes to the flash). Does anyone have any experience using filesystems in this situation? Which one should I look into for this type of application? Ext2? Ext3? Reiser? JFFS2? Help!"

A solution in search of a problem.

[DerekLyons]

Once you've already chosen the wrong hardware - no amount of software will fix the problem.

Re:A solution in search of a problem.

[Smidge204]

So what do you know about this guy's project that the rest of us don't?

=Smidge=

Doesn't CF already do this for you?

[andyross]

I was under the impression that CF cards, which present a traditional 512 byte block interface at the hardware level, automatically hides the complexity of managing separate flash block; and in so doing automatically rotates writes so as to avoid wear. Is this not correct?

I guess a better way to ask the question is: are you sure you have a problem here at all? Have you observed wear problems with ext3 and CF hardware? My understanding is that the only meaningful file system you should be doing with CF hardware is mounting the filesystem with noatime.

Beware journaling on flash.

[Yaztromo]

The answer for your read-only kernel partition is easy. Use a simple, non-journaled filesystem. Ext2 is perfect for this. As the filesystem will never be written, you don't have to worry about partial overwrite issues.

Journaling on flash isn't exactly a good idea. The problem here is that the journal is going to be written to very frequently, and it will always be located in the same location, you could very easily hit that max-writes inside the journal, which is going to cause all sorts of havoc. So I'd be very weary of adopting a journaling filesystem on a flash device -- you'll introduce failure in the journal itself, which is going to cause all sorts of write access issues down the road.

Personally, I'd stick to a non-journaled filesystem which has good bi-directional pointer support for sector/cluster chaining. Ext2 is thus a good choice, as may be Reiser3 (with journaling disabled).

Yaz.

you need to revisit your design.

[isaac]

ext2 will be just fine for your read-only root. CF is the wrong choice for locally writeable storage in an environment where you could lose power at any time. Either build some measure of power isolation into your product to provide time for a graceful shutdown or use media without write-cycle limitations (microdrive?)

JFFS2 doesn't do you a lick of good on CF where the flash structure is abstracted by a translation layer. You don't want a journaling filesystem, either.

-Isaac

Too bad you can't use ZFS

[Wesley Felter]

ZFS sounds great for flash, since (unlike journaling filesystems) it doesn't write anything twice during a transaction and it also spreads writes around because of copy-on-write. You'd get a lot of wear on the uberblocks, but the card's wear-leveling should take care of that. Too bad it's not available for Linux.

Re:A solution in search of a problem.

[dgatwood]

Start out that he's trying to have a device reliably not corrupt data when unplugged hot, but he's using flash memory as the non-volatile storage. Flash writes are way too slow, so there's always the possibility that some of the last changes won't make it out in time.

One possible solution is to add a lithium cell or LiPo battery or whatever to power the CPU and flash long enough to do an orderly shutdown on power loss. Alternatively, you could hack the Linux kernel to do write caching to battery-backed static RAM, then read it back in like a journal when the hardware comes back. Either way,

The most important thing, though, IMHO, is to mount the volume synchronously. This will be a performance hit, but should nearly eliminate any filesystem corruption risk when combined with a journal.

Re:Beware journaling on flash.

[merreborn]

it will always be located in the same location, you could very easily hit that max-writes inside the journal, which is going to cause all sorts of havoc

That's what wear leveling is for.

http://en.wikipedia.org/wiki/Wear_levelling [wikipedia.org]

Entire CF Drive should be Read Only!

[Fallen Kell]

You have a serious design problem already. Even with industrial grade CF drives you will not be able to last long if as you said "we power on and off", and you were correct in your statement, "need to minimize thrashing" the CF drive.

Someone somewhere made a bad design choice. The entire drive should be read-only and the OS should be running on a small RAM disk. Hosting a flat-file database and storing log data will very quickly destroy the drive.

Use a non-journaled fs with no write cacheing.

[jonadab]

You don't need journalling if you turn off write cacheing. (You can still use read cacheing.) Indeed, without write cacheing there wouldn't be much point to journalling. If turning off write caching kills your performance, then your application is doing too much writing for Flash RAM to be a reasonable storage medium. So, you don't need a journalled filesystem.

Good idea, poor wording

[molafish]

Sometimes your design requires the use of a certain piece of hardware. Size, cost, compatability, a million things... Besides, there's nothing at all wrong with implementing with CompactFlash. Explain to me why "you will not be able to last long" turning the device on and off "Even with industrial grade CF drives". CF cards are obviously turned on and off a lot (think about PDAs, cameras, etc). What will reduce the life of a CF device is, like the OP is concerned about, the number of reads/writes. I just recently made the switch to industrial cards for my company's project, because we started to see failures in cards after about 1 year of 24/7 service with win98 on fat and XPe on ntfs (yes, ntfs failed faster). I think there is more to this solution. After you find the filesystem with the fewest overhead reads/writes, you might want to find a way to provide even better protection due to power loss: load the entire flash card in memory and run the OS off of that; only write to disk when work is completed that really needs to be saved. The problem: you need 1 gig of memory just for your CF contents, plus whatever memory is needed for running procs. That's hard to come by in embedded systems... Added benefit: faster execution time. I know XPe optionally implements this feature, they call it Enhanced Write Filter (EWF). There's also a File Based Write Filter (FBWF) coming out in the XPe SP2 Feature Pack 2007. Apparently it is meant only to protect files that are constantly being written. Perhaps this is the solution to the small amount of available ram. As for linux, I would be interested if anyone knows of solutions for these features, as I'd really love to port my application over to linux if I can provide instant on/off and no corruption capability.

Re:I don't have any mod points...

[hugetoon]

Sorry, but it's not fun at all actually. No i'm not religious extremist of any kind, but just try to figure what people involved in the story you allude to feel like these days, definitively not fun.

Block Emulation in Compact Flash

[Not Invented Here]

There's one important thing to remember about Compact Flash: it is not a raw flash device. There are robust filesystems to run on raw flash (YAFFS, JFFS2), but they only provide limited help when running on Compact Flash. A Compact Flash already contains a flash filesystem layer, which emulates an ATA disk on top of NAND flash. The manufacturer of this emulation layer does not publish documentation, and may change the implementation between production batches without changing the part number.

This is fine for a digital camera: it only writes a file when you press the shutter, and the user turns it off with a soft power button which will wait until the write is complete. The only way to turn off the power during a write cycle is to pull out the battery, and the manual tells you not to do that.

The question here is: what filesystem to run on top of this undocumented emulation layer, to provide reliability if the power is removed? I wish I had an answer to that. I feel your pain, as hardware designers always leave me stuck with this same unsolvable problem.

I'll pass on some advice I've received before: smartmedia and xD cards expose a raw NAND interface, allowing you to run JFFS2 or YAFFS directly on the flash. I've never managed to persuade a hardware designer to pursue this approach, but maybe one of you will succeed.