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!"
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.
Once you've already chosen the wrong hardware - no amount of software will fix the problem.
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 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 pictures to it. 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. Anyone know how I can restore my card? It's only 256MB, but I'm peeved because it's my card, non Canon's. It could have been a 2GB and worth much more. I know this is offtopic. Mods, please maybe just leave this comment be at +1?
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.
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.
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.
You probably want a filesystem tailored to Flash characteristics, such as YAFFS.
you had me at #!
http://en.wikipedia.org/wiki/JFFS2
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.
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 am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
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?
/ 1410241
p ers/elephant-hotos/elephant.pdf
there was a slashdot story about such a filesystem a while ago:
http://linux.slashdot.org/article.pl?sid=05/10/04
and a quick googling turned up a paper on the idea:
http://www.hpl.hp.com/personal/Alistair_Veitch/pa
-- kieran hervold
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
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
There are now several in the current kernel. Look ath them before looking at other solutions.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
...or I would have tagged this one as FUNNY!
Dog is my co-pilot.
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.
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.
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.
Well, there's slashdot's joke template for the next 10 years.
RIP, hot grits, we barely knew ye.
If the writable portion of the drive only needs a couple of files on it (a logfile and your flat database file), maybe you don't need a filesystem at all? Just divide the drive into 3 partitions (read-only system partition, log partition, and database partition) and write to and read the partitions directly. (a la "/dev/hda2") There will be no chance of filesystem metadata corruption because there is no filesystem, hence no need for journalling. All you will have to be careful of is to make sure that whatever program is using this logfile and this flat database file can deal properly with a partial write.
The atomic writes where a write is confirmed correct or discarded makes reiser4 sound like the perfect flash match in a hot plug and play environment. I would love to hear what reasons there would be against it (besides not yet being a default linux kernel option).
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.
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.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
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.
Cut that out, or I will ship you to Norilsk in a box.
Insert humour about the nickname being "hung well, low"
Oh slashdot.
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
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.
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.
-- Emery Berger, Dept. of Computer Science, UMass Amherst
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.
I just re-read your comment. It's the CF not SD card that is write protected. Please disregard my parent post.
The truth shall set you free!
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.
Wondering how comes that Logfs from Jorn Engel didn't come up in the discussion yet.
http://wiki.laptop.org/go/Logfs
Kris Buytaert
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 mode. Kingston bless them have now changed to samsung DMA enabled flash, and still call the product Pro Elite, its even got the same P/N, but its completly different underlying technology. Our CF slot has pin 34 (DMA pin) NC (not connected). You can set ide=nodma in grub / lilo but we're still seeing CF corruption on DMA enabled CF. Ive changed to Lexar 40X standard - non DMA part and 100% relibility restored. YMMV. But different CF brands seem to behave differently wrt curruption in DMA enabled mode. Ive called Kingston tech support and sandisk both claim all their technology is going this way.
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. SRAM's are fast and fairly low power (although at the expense of wiring real-estate).
Now, which journaled fs is the question - I haven't peeked under the covers on fs's in a long time, but my recollection is that ext3 puts the journal on the same partition as the filesystem itself, which won't work with scheme. I know that there are fs's on other OS (Solaris) where you can put the journal on a different partition.
Good luck.
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 permanent. This might reduce the amount of write you make to your CF, to prevent your application from needlessly thrashing to CF for every little update. At least now your wear time should be more predictable.
Other CF-based linux things I've seen only writeback to flash when requested to "save".
If you just wanted to throw money at the problem, you could simply throw in a CF microdrive (real hard disk in CF type II container). Then you'd have 4GB to play with, and not worry about wearing out your flash memory.
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.
We're looking at putting both CF and a HDD in our embedded system. We'd like to use a RO CF to boot up and send us an alert if the HDD gets fscked. The problem we're having is that we'd like to use a standard distro (say Debian) overall, but we need to have a two-stage boot to make sure the HDD is fine and not to screw up the system.
/boot and /etc on flash anyway... And we're also hitting the dma/pio CF problem :-((..
Any clues on what we can try? Should we modify initrd to pivot_root differently based on the HDD fsck status?
We'll probably have
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.
I build a OpenBSD system for use on a soekris net4501 with a 128MB Comact Flash. The root filesystem is mounted RO. In the boot process a small RAM Drive is created for non-persitent log/tmp files. If the log files are required for long term storage they are forwarded to a different syslog host.
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 product going to last that long in the marketplace without an upgrade?
Maybe I've slipped a decimal somewhere, but it looks like you might not be able to actually hit the cars limits under normal operating conditions.
Is it just my observation, or are there way too many stupid people in the world?
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-swapping a little more robust.
The world is made by those who show up for the job.