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!"

Comments

A little large for JFFS2, but that is being fixed

[hpa]

Last I talked to David Woodhouse (author of JFFS2), he told me JFFS2 didn't really handle filesystems in the gigabyte range very well, but that that was being remedied in order to support OLPC.

So if you can wait a bit, then JFFS2 is probably the right answer.

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=

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.

Odd, ext2 works well for me

[notarus]

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

Re:Odd, ext2 works well for me

[notarus]

Actually, rereading your original comment, I'm not sure my experiences actually are anything like yours.

While we update a couple files a few times a month, we're not writing a database to the cf over and over.

Still, we like the CF based solution-- if we have a hard ware failure, it's quick to swap out, and if the CF fails, we have archives of the file systems made automatically weekly so it's just a matter of untarring to a disk, re lilo'ing, and install.

Re:Odd, ext2 works well for me

[MikeFM]

I use ext3 but make the filesystems read-only and I don't record access times. I store temp files on ramdisks formatted as ext2. I simply avoid writing to the CF whenever posible as I know it'll shorten their life to do so and that CF will never be the best solution for real data storage. I use either normal hdd or network for data storage. CF does make for fast load time of apps in my experience so the OS and frequently used programs and libraries I do try to keep on the CF.

Don't use Reiser

[Anonymous Coward]

It's murder to install and debug.

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.

Re:Doesn't CF already do this for you?

[oz_paulb]

I believe all CF flash cards do wear-levelling, so you can just drop a FAT (or whatever) filesystem on top of it without worrying about over-using certain sectors (like the FAT/root dir on a FAT filesystem).

It sounds like the OP requires journalling - so I'd suggest just choosing any journalling FS that you're comfortable with (and don't worry about whether/not it re-writes sectors a lot, as the CF card will take care of that for you).

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.

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

let me guess - gaming terminal?

[toby]

You probably want a filesystem tailored to Flash characteristics, such as YAFFS.

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

I'd recommend doing experiments

[davidwr]

Before you settle on an answer, pick 2 or 3 possible solutions do some real-world experiments to make sure the chosen solution 1) works well and 2) isn't inferior to another candidate solution.

Don't discount unsophisticated filesystems such as FAT and its variations.

For the read-only filesystem, FAT, MINIX, or even a read-only OS like cramfs might be better under certain circumstances.

Whatever filesystem you use, consider immediate-write-commit for file-system operations or better yet all operations rather than worrying about journaling. Write-on-commit everything is a little slow but it's hard to beat for data integrity after sudden power loss.

As for thrashing due to memory limits - don't use swap space. Ante up for more memory and write your code so it fails gracefully if it is out of RAM.

Consider having your power-down the desktop equivalent of "sleep" or "hibernate" rather than "off." That way, you either never save RAM or only save it at power-off. Use battery-backed-up RAM or NVRAM to make the "sleep" mode if you have to. These also mostly-solve the journaling problem, as you won't have a lot of unexpected fresh-starts.

Re:Unwriteprotecting a CF card?

[duguk]

I had something similar with an SD Card, it would refuse to format and was unformattable. I found some app - smformat I've used before which has helped, I found it again linked here: http://ask.metafilter.com/mefi/22771

You can download the program from here - even though its a totally unrelated problem I think this might help ya.

Can't guarantee it'll work or if its not spyware but it's worked for me before :)

Re:Can any explain how wear-leveling really works?

[oz_paulb]

not sure exactly what you're saying, but I'll take a stab at answering...

Media with built-in wear-levelling (CF Flash, for example) use whatever methods/structures/etc that they want to keep track of flash blocks, how often they've been written/erased/etc (the 'media' is actually storage media (like NAND flash) plus some sort of microcontroller to implement the wear levelling). This underlying physical structure is hidden from the application/filesystem code. Instead, a 'virtual disk drive' of "N" 512-byte logical sectors is presented to the application/FS code (for example, to the FAT filesystem).

When FAT wants to update (example) 'sector 2' of the 'drive', it asks the CF drive to do this. The CF drive may end up moving a bunch of data around, erasing/rewriting physical blocks, discarding bad blocks, etc, and may actually write the updated data to 'block 500' on the flash array. The underlying CF structures keep track of where 'logical sector 2' exists in the physical media - even after things are rearranged.

So, the app/FS code doesn't need to worry about wear levelling - it's taken care of.

On the other hand, if the app/FS code is written with the underlying media type in mind (example: NAND flash), and does its own wear levelling/bad block management, it's possible that this would be more efficient/do a better job than the 'virtual layer' created by media like CF Flash.

Re:Damnsmalllinux agrees with you.

[Anonymous Coward]

More stable than the author, even.

Thank you, I'm here all week.

Re:A little large for JFFS2, but that is being fix

[big daddy kane]

YAFFS might be a better choice. It only works on NAND flash memory (but IIRC compact flash is NAND), but should be a bit faster (mounts writes etc) than JFFS2. However, if you're using compact flash (which includes hardware block mapping) you DO NOT want to use a specialized file system. The point of block mapping flash memory is to present the drive as a traditional hard disk, so traditional FS's can be used on it. If you use a specialized (or write heavy) FS on a block mapped chip you'll most likley end up doing more harm than good. Plus, YAFFS in particular requires specific hardware functions of flash chips (such as OOB write access) that are abstracted by the block mapping layer.

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.

CF cards do NOT do atomic writes

[Anonymous Coward]

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

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. :-( (And, of course, replacing the main file system is not a "quick patch.")

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.

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.

FS specifically for Flash & embedded systems

[Ristretto]

Here's a transactional file system (& more) developed at UMass Amherst that sounds like it might fit your needs. I've boldfaced the key line.

Recent gains in energy-efficiency of new-generation NAND flash storage have strengthened the case for in-network storage by data-centric sensor network applications. We argue that a simple file system abstraction is inadequate for realizing the full benefits of high-capacity low-power NAND flash storage in data-centric applications. Instead we advocate a rich object storage abstraction to support flexible use of the storage system for a variety of application needs and one that is specifically optimized for memory and energy-constrained sensor platforms. We propose Capsule, an energy-optimized log-structured object storage system for flash memories that enables sensor applications to exploit storage resources in amultitude of ways.

1. Capsule features:
2. Capsule provides the abstraction of typed storage objects to applications; supported object types include streams, indexes, stacks and queues. A novel aspect of Capsule is that it also allows composition of objects for instance, a stream and index object can be composed to archive sensed data. The objects expose a data structure-like interface, allowing applications to easily manipulate data.
3. Capsule seamlessly supports storage on a multitude of platforms (both NAND and NOR flashes) with the help of a hardware abstraction layer; the same application can be used on any supported platform. Currently we support storage on the following platforms: Mica2, MicaZ, Mica2 Dot, Telos and our custom NAND flash board. However, the use of an abstraction layer allows supporting a new platform a breeze.
4. Capsule supports checkpointing and rollback of storage objects, allowing the application to tolerate software faults and device failures. The application state is automatically restored when the device restarts.
5. We provide our own file system implementation on Capsule that allows applications using Matchbox and ELF to be ported to Capsule.
6. Flash offers a finite storage medium; once it fills up, free space needs to be created before any further data can be stored on it. Basic Capsule objects perform memory reclamation by supporting compaction.

Click here for the Capsule site. It's been deployed on a number of very small platforms (including turtles (!)).

-- Emery Berger, Dept. of Computer Science, UMass Amherst

JFFS2 may be best, but it isn't a good match

[r00t]

Normally, JFFS2 won't even run on a normal block device. It expects raw flash. There is a driver that adapts it though, but...

CompactFlash looks like IDE, not raw flash. CompactFlash has built-in wear leveling. It's designed to support the typical FAT filesystem that normal people use. All the fancy wear-leveling things in JFFS2 will be wasted.

Of course, the other filesystems are lame too. The others are optimized for rotating media, so they waste space and CPU time trying to avoid disk seeks.

CompactFlash and similar devices really could use special filesystems optimized for the odd combination of near-free seeks and device-supplied wear leveling.

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.