Slashdot Mirror
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!"
I run about a dozen machines running pebble (and soon, voyage) which are both debian based CF distros, and we don't have much problem with them at all. They get powered on and off a lot, I do quite a few live updates of specific files, etc, no problems.
Is it possible you're not actually suffering FS corruption but instead having problems with CF that just isn't suited for the task? We started this project using kingston, which is good flash for cameras, but we ran into lots of dead sectors. We've been using Lexar since, with no issues at all (of the 13 machines, i think we've lost 1 sector in 2 years).
It's murder to install and debug.
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.
I can testify from personal experience doing the same thing that if you power down a CF card while it is writing, you will get a bad sector. It can be recovered by rewriting it, but the sector is unreadable. (Tested on SanDisk and Lexar brand cards; that was enough to convince me that I needed a file system that could cope.)
:-( (And, of course, replacing the main file system is not a "quick patch.")
Thus, any classical fixed-location file system (inode or FAT style) is NOT suitable for embedded appliance use on compactFlash cards.
This severely pissed me off, because the essence of wear-leveling is out-of-place writes, and I just assumed that any CF manufacturer with an ounce of brains would implement a two-phase commit, ao each sector write would be atomic: after a power cycle, either you'd see the new contents, or the old contents, but never anything else. The window is narrow, so I hadn't noticed it during development; we had shipped products and got field failures.
It MAY be possible to adapt a block-based journaling FS like Ext3 to this brain-damage, since it can unconditionally replay the journal on power-up and overwrite the problematic sectors. You just need to ensure that single-block corruption can't mess up the journal. or the superblock. And you need to journal the data as well as the metadata.
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.