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

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

[big daddy kane]

YAFFS [aleph1.co.uk] 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.

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.

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

[Sleeping Dog]

Wondering how comes that Logfs from Jorn Engel didn't come up in the discussion yet.

http://wiki.laptop.org/go/Logfs [laptop.org]

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:

[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

Re:

[modecx]

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.

Right. And the one solutiuon would be to set the kernel such that it flushes the write cache very often, so they will hopefully not pull it during a write event. Of course, doing this will likely burn up cycles on their flash media REAL quick

Re:

[Anonymous Coward]

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.

There's no need to hack the kernel. Most journaling filesystems already support external journals, so all you need it a few megabytes of SRAM accessible as a block device. Many of the IPC boards that support Disc-On-Chip also support Battery buffered SRAM in the same socket.

Re:

[dgatwood]

You'd still have to mount it in synchronous mode so the kernel doesn't do any write caching. External journals only go so far. Journals guarantee filesystem consistency, but not data consistency. So you could still have a journal that says that a transaction was written to disk but that was actually in-flight in the buffer cache. At least flash parts don't do write reordering, so it's not as bad as it could be, but journaling to SRAM is still only half the problem.

Re:

[dgatwood]

Err... is still only solving half the problem.

Re:A solution in search of a problem.

[darkonc]

With ext3, you can specify '-o data=journal'. This forces journaling of data. If you're using ext3fs (or most other general purpose FSs) you should also try using '-o noatime' -- It disables updating access times, which could cause bit fatigue for the inodes of heavily used files.

You'd still have to mount it in synchronous mode so the kernel doesn't do any write caching. External journals only go so far. Journals guarantee filesystem consistency, but not data consistency.

Re:

[DerekLyons]

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

I actually bothered to read and think about the problem and situation posited.

Re:

[Smidge204]

In that case you should have no problem answering my question, rather than dismissing it with a snide comment.

If you are going to claim that he's using the wrong hardware then you obviously think there is better hardware, and in order to make that comparison you must know all about the project budget, operating environment, size and weight constraints, power availability etc. Please share because I don't see anything in the summary that tells us why he chose CF - even between the lines.
=Smidge=

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.

Re:

[Anonymous Coward]

have you ever heard of tmpfs

Re:

[MikeFM]

tmpfs might be good for some situations but I don't want it to grow out of control so I like having a hard limit to what can be stored. I also don't like swap because it wears out your hdd and slows everything down a lot. If you want to run fast enough that you'll use CF to improve load times then you should really not be using swap.

So for my usage there is no benefit to using tmpfs instad of a ramdisk.

Don't use Reiser

[Anonymous Coward]

It's murder to install and debug.

I don't have any mod points...

[Archeopteryx]

...or I would have tagged this one as FUNNY!

Re:

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

Re:

[Archeopteryx]

She's dead and feels nothing.

And I don't much care what he is feeling right now, given the circumstances...

Re:

[Lars T.]

Are you going to do the same for the two children?

Re:

[xsonofagunx]

Do What Thou Wilt Shall be the Whole of the Law.

Just because. I'd have replied with "All Hail Discordia" if you were of that persuasion as well. It's always nice to see someone with similar beliefs, and I like to acknowledge them as such.

Good on you, in any case.

Natch

[Anonymous Coward]

Well, there's slashdot's joke template for the next 10 years.

RIP, hot grits, we barely knew ye.

Unwriteprotecting a CF card?

[NeMon'ess]

I have a CF card that I use with one of the handful of mp3 players that use them. A few weeks ago I visited my family and took the player and my camera which uses SD. I left the camera cable at home. My uncle and I wanted to try and view my photos on his TV. He has a Canon SLR that takes CF. So I attempted to use the multi-card reader on his printer to copy the pictures from the SD card to the CF. After formatting my CF in his camera, Win2k said the card was write-protected and could not copy my pictu

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 [metafilter.com]

You can download the program from here [totalbiscuit.com] - 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:

[feld]

perhaps 'dd' would be of use? then fdisk to re-partition and then make your new partition?

Re:

[Technician]

It also wouldn't let me format it. I used my mp3 player to format the card, but Windows still says it's write-protected.

SD cards have a dum dum switch on the side of the card. It didn't get bumped into the lock position by any chance? That little switch on the side of the card will cause all your symptoms as it prevents all writes including a format.

Write back and let us know if it was the dum dum switch.

Re:Oops

[Technician]

I just re-read your comment. It's the CF not SD card that is write protected. Please disregard my parent post.

Re:

[Anonymous Coward]

Fine, yeah Anonymous Coward, blah, blah, blah... If slashdot.org would let me log in...

Anyway, had a similar problem with a SD card for a Canon camera. I inserted it into a Sony laptop, and the camera wouldn't recognize the card from that point on. As far as I was able to determine, Canon uses a non-standard format for their cards. I think they set a reserved bit (or register) on the card. It was a pain-in-the-ass, but there are free utils to help.

Here are some links that I found useful.

Re:

[bcmm]

Check the write protect switch. I had a faulty SD card with a write protect switch so loose that inserting it into a reader almost always moved the switch to protect. It took me a while to work out what was happening and put some tape on it.

If your sure it's a software problem, then you could try writing zeros over the MBR with dd or something to make it look like completely unformatted media.

Re:

[bcmm]

s/your/you're

Re:

[Gulthek]

Might as well s/SD/CF/g while you're at it. But that won't really fix the post.

Re:

[bcmm]

Well, I don't know what a CF card looks like or whether it's possible for the switch to get flicked like that.

Re:

[bcmm]

Hmm, seems CF doesn't have a write-protect switch. Try the second suggestion though.

Re:

[xsonofagunx]

Some printers with multimedia-card slots (my Canon Pixma, for example) lock the card as read-only. You can change it in the printer's settings (not in software, but on the printer's hardware settings). It locks it because it's expecting cards from digital cameras, which you would have no reason to overwrite, but if you're taking them from MP3 players (or, in my case, a Gameboy Advance M3 media player [ie... media and GBA/DS game player - wonderful bit of hardware btw]) it considers it as a digital camera ca

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:

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

Can any explain how wear-leveling really works?

[AZPolarBear]

Unless it's FM, wear-leveling needs to know about which blocks are free in order to choose the least used blocks first. If FAT FS isn't used then there is likely no wear-leveling. Possibly not even under FAT32.

Re:

[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-byt

Re:

[Sloppy]

The underlying CF structures keep track of where 'logical sector 2' exists in the physical media - even after things are rearranged.

But that just raises the question: where does it store this mapping? In a page of flash that it has to write to, every time the map changes? ;-) I smell magic.

Re:

[buysse]

Maybe a couple of pages of SRAM? Static RAM doesn't require refresh power, so it's non-volatile, but has none of the problems that flash does (like extraordinarily slow writes, or having a limited number of erase cycles.) It has its own problems, like being ridiculously expensive by comparison, but a 4K block should be enough to hold the map. I don't really know how the magi^H^H^H^H wear leveling works, just a guess.

Re:

[Anakron]

Static RAM doesn't require refresh power

Right so far..

so it's non-volatile

Nope - volatility refers to whether the medium stores data when all power is turned off. SRAM is volatile.

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.

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.

Damnsmalllinux agrees with you.

[Anonymous Coward]

www.damnsmalllinux.org
If you're using dsl on a compact flash, you're advised to do a frugal install. DSL reads from the cf on boot but then runs completely in memory. The flash is almost never written and only read once per boot. The result is that it should live forever.

As you note, a journaling file system will trash your cf reasonably fast. As for Reiser, he's been charged with murder and the future of the file system is somewhat in doubt. http://en.wikipedia.org/wiki/Hans_Reiser [wikipedia.org]

Re:

[Anonymous Coward]

More stable than the author, even.

Thank you, I'm here all week.

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]

Re:

[notarus]

Wear leveling will have the effect of keeping the writes evenly distributed across the flash. What it won't do is save you from reaching your max-write counts. While many flashes are good for 1000+ writes per block, writing a journal entry for each change is going to dramatically increase the speed you reach that number.

Further, I'd point out that you shouldn't be writing to the CF much except during the setup phase. The reason you want a journal is to recover from a failure before the disk is fully writte

Re:

[big daddy kane]

Plenty of flash specific file systems use journalling, such as JFFS and YAFFS. Having a log structured FS can even provide a simple and intrinsic form of wear leveling. However, if you're using flash hardware such as Compact Flash, which has built in hardware block mapping, you might not want a journaled FS.

Re:

[Ihlosi]

That just isn't true of any journalling flash-file system that is worth its salt. The journal isn't in a single location in the flash - it is interwoven with the data on the flash. Flash use is bananced over the entire flash.

Also, the flash medium itself might perform some sort of wear-levelling.

File system isse, or application level issue...

[topham]

Are you really having a filesystem issue? Does the filesystem become corrupt, or does the database / logfile?

journaling filesystems will help protect the filesystem structure, but they are not going to protect you're database from becoming internally corrupt.

Whatever you're using for a database should be performing a filesystem sync, if it isn't you will likely get inconsistent transactions.

let me guess - gaming terminal?

[toby]

You probably want a filesystem tailored to Flash characteristics, such as YAFFS [aleph1.co.uk].

jffs was designed

[elhedran]

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

If you did even a small amount of research you would have seen that JFFS2 was designed for flash memory devices, and has journaling. Its a little harder to make file systems for (at least the last time I was doing so) but given your criteria its what you are looking for.

Re:

[TheRaven64]

If you did even a small amount of R'ing TFS, you would see that they author actually mentioned JFFS2. If you then did a small amount of research, you would see that JFFS2 has scalability issues and probably shouldn't be used for a 1GB filesystem. JFFS3 should address some of these problems, but it is not finished yet.

Re:

[elhedran]

lol, I read the summary, saw JFFS2, and then got wikipedia article. What made you think I didn't see him suggest JFFS2 as one of his options?

As for the scalability issue, well I haven't come accross a need for 1gb in a single mount point yet, but that could just be me. Just because he needs 1gb of storage does not mean he is unable to partition it into two or more jffs2 partitions.

However I will admit I don't see as much use of jffs as I used to. It has been a while since I've been involved directly in c

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

do you ever need to delete a file?

[Anonymous Coward]

if you don't need to delete anything--if you're just appending to the log indefinitely, w/ no chance of running out of space--how about a fs that never truly deletes anything?

there was a slashdot story about such a filesystem a while ago:
http://linux.slashdot.org/article.pl?sid=05/10/04/ 1410241 [slashdot.org]

and a quick googling turned up a paper on the idea:
http://www.hpl.hp.com/personal/Alistair_Veitch/pap ers/elephant-hotos/elephant.pdf [hp.com]

-- kieran hervold

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:

[piranha(jpl)]

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.

Keep in mind Linux will kill processes which use "too much" RAM, nullifying graceful memory shortage recovery code. See: Memory overcommittal, or how to avoid the OOM killer. [livejournal.com]

Ramdisk

[slimjim8094]

Do all of your work in a ramdisk. Flash has write-limitations, so you want to be limiting the writes to it at all costs.

Obviously, any important changes should be written, but any FS should work for that, since you probably only will need to write on database change, and/or OS shutdown.

Flash-Filesystems?

[gweihir]

There are now several in the current kernel. Look ath them before looking at other solutions.

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:

[KonoWatakushi]

Actually, there would be little wear from the uberblocks; there are 128 of them written in sequence every 5 seconds or so. As such, it would take nearly three years of constant use for them to reach their wear limit. Even with no wear leveling, ZFS would be an excellent filesystem for flash.

Furthermore, when blocks inevitably do go bad, ZFS can detect and correct the faulty blocks. At present, this only applies to metadata, though it will be possible to replicate data as well in the future. ZFS uses rep

Rediculous Suggestions

[feld]

You don't need a journal for compact flash, and you certainly don't need the complexities of ext2. What you need is something simple, but scales well.

UDF

Supported by Mac, Linux, and Windows.

It's really the best solution.

Re:

[brokenin2]

yeah.. I'm surprised I haven't seen any more suggestions of Reiser4. It does atomic writes and keeps everything consistent without the use of a journal at all. It seems like that would keep your writes cut in about half without any real downside to your project.

I know it's still somewhat experimental, but I've used it before just for play, and it didn't throw any of my files away, and that was about a year ago.

I know Hans is in jail, and Reiserfs's future is uncertain, but at least for now it seems like t

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.

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

Re:

[mnmn]

He can always use the MR2A16A chips if he can make his own circuitboard.

These are MRAM chips. Fast as flash but as reliable as ram. Write, page and thrash all you want.

Re:

[infolib]

But note that the MR2A16A is only 4Mbit. NEC has a 16 Mbit MRAM out, but you'll get nowhere the same capacity as with flash for your space and money.

I'm kinda partial to MRAM since I do my thesis in spintronics, but it's just not there yet. Maybe some MRAM-buffered flash system would be handy, but that goes a bit beyond doing your own circuit boards.

Re:

[mnmn]

Wow thanks. I think I'll go with the NEC chips for a XIP Linux system that never has to boot. Booting itself will just be an interrupt. Hopefully theyre cheaper than $50 and hopefully still they're free as samples. The exposure I'll generate with it in my projects should give them enough business in time.

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.

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 [umass.edu]. It's been deployed on a number of very small platforms (including turtles [umass.edu] (!)).

-- Emery Berger [umass.edu], Dept. of Computer Science, UMass Amherst

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.

Re:

[bgat]

> smartmedia and xD cards expose a raw NAND interface

Can you provide URLs that talk about that?

Re:

[Not Invented Here]

Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.

Wikipedia on xD cards [wikipedia.org]
Instructions to fit an xD card to a Mattel Juicebox [elinux.org]
A comment on LWN from Wookey, who knows a lot about flash [lwn.net]
xD card pinout [pinouts.ru]

My best advice is to ask people on the linux-mtd mailing list [infradead.org] for specific details.

ext3 in full journaling mode

[bucksontour]

Im also running a cutdown knoppix OS on an SBC using 1GB CF. The stock distro shipped with 2.4 kernel with no ext3 support and we experienced fs corruption on shutdowns during periods of high disk write activity using ext2. I hand rolled a 2.6.13 kernel with compiled in ext3 support and this has increased realibility when using full jouranal mode (not ordered or writeback). A word of warning, most underlying flash is going DMA enabled; we've been buying Kingston pro elite which was working perfectly in pio

NVSRAM as a journal?

[toybuilder]

As someone else already pointed out, if the system is intended to use CF FLASH, there is already wear-leveling supported by the CF card and so the FLASH can be mostly treated as a IDE device.

JFFS2 is probably not the fs to use in this case. (At least when I last looked - but that was almost 2 years ago).

Assuming that you don't intend to have the user change out CF cards willy-nilly, I think one possibility to consider is to have a small battery-backed SRAM MTD block device be your journaling partition. SR

JFFS and UnionFS

[rwa2]

The Journalling Flash FileSystem was developed specifically to wear out your flash memory evenly (and not wear out some prematurely). But you already knew that since you brought it up.

The flatfile database sounds like the killer, though, especially since you want changes to survive unexpected reboots.

I'd suggest you use the ram-based UnionFS (so your CF is mounted RO but you can still write changes and make mods to the view of the FS in RAM). Then periodically you'd flush from UnionFS to CF to make things

How about a RAMDISK?

[green pizza]

You could consider two partitions on the CF card, one for storing config files and such (mounted RW only when updating) and the other partition could store an image that would be loaded into a RAMDISK. Ram is cheap and flash is slow.

Red herrings

[meowsqueak]

You could use ext2 or cramfs, mounted read-only. Forget all those comments about JFFS etc - CF is not the same as a 'flash' device, it basically behaves like a hard disk with limited write lifetime.

Is it really a problem?

[Overzeetop]

Do you know that reliability will be a problem?

Taking a 66x flash card and writing continuously on it until you hit a million cycles would take (1E9B*1E6Cycles/(66x1.5E5B/s)/(60s*60m*24h)= 1169 days, or over 3 years of 24/7 writes. Okay, half that if you're just using 512M as your db. Still, that's under continuous duty. At 25% duty cycle (1/2 read operations, 1/2 write operations, data trasfer occuring _only_ 12 hours a day on average) of the HD on a daily average you've still got 7 years of life. Is the p

Shutdown sequence or improved CF

[jbeaupre]

This might not be practical at this point in the project, but what are the chances of modifying the power-off sequence? If the OS can detect an "off", could you delay actual shutdown until writes are complete? Alternately, maybe someone needs to develop a CF with a small capacitor and RAM cache (or maybe put it on the host side). Host device gets shut down yet the CF still has enough juice (and brains) to finish the last few writes, discarding any partial blocks. Putting it on the CF might even make hot