Which Filesystem is Best for CompactFlash? 100
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 (Score:4, Interesting)
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 (Score:4, Informative)
JFFS2 may be best, but it isn't a good match (Score:5, Informative)
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 (Score:1)
http://wiki.laptop.org/go/Logfs [laptop.org]
A solution in search of a problem. (Score:4, Insightful)
Re:A solution in search of a problem. (Score:5, Insightful)
=Smidge=
Re: (Score:3, Insightful)
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: (Score:1)
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: (Score:2, Informative)
Re: (Score:3, Interesting)
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: (Score:2)
Err... is still only solving half the problem.
Re:A solution in search of a problem. (Score:2)
Re: (Score:2)
I actually bothered to read and think about the problem and situation posited.
Re: (Score:2)
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 (Score:5, Informative)
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 (Score:4, Interesting)
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 (Score:5, Informative)
Re: (Score:1, Informative)
Re: (Score:2)
So for my usage there is no benefit to using tmpfs instad of a ramdisk.
Don't use Reiser (Score:5, Funny)
I don't have any mod points... (Score:2)
Re: (Score:2, Insightful)
Re: (Score:3)
And I don't much care what he is feeling right now, given the circumstances...
Re: (Score:2)
Re: (Score:1)
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 (Score:1, Funny)
RIP, hot grits, we barely knew ye.
Unwriteprotecting a CF card? (Score:2, Interesting)
Re:Unwriteprotecting a CF card? (Score:4, Informative)
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: (Score:1)
Re: (Score:2)
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 (Score:2)
Re: (Score:1, Interesting)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Doesn't CF already do this for you? (Score:5, Insightful)
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: (Score:3, Interesting)
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? (Score:1)
Re: (Score:3, Informative)
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: (Score:2)
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: (Score:2)
Re: (Score:1)
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 (Score:5, Informative)
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.
Beware journaling on flash. (Score:5, Insightful)
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. (Score:1, Interesting)
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: (Score:3, Funny)
Thank you, I'm here all week.
Re:Beware journaling on flash. (Score:4, Insightful)
That's what wear leveling is for.
http://en.wikipedia.org/wiki/Wear_levelling [wikipedia.org]
Re: (Score:2, Interesting)
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: (Score:1)
Re: (Score:2)
Also, the flash medium itself might perform some sort of wear-levelling.
File system isse, or application level issue... (Score:2)
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? (Score:5, Informative)
jffs was designed (Score:2, Informative)
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: (Score:2)
Re: (Score:1)
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. (Score:4, Insightful)
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? (Score:1, Interesting)
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 (Score:4, Informative)
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: (Score:2)
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 (Score:2, Interesting)
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? (Score:2)
Too bad you can't use ZFS (Score:3, Insightful)
Re: (Score:2, Informative)
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 (Score:1)
UDF
Supported by Mac, Linux, and Windows.
It's really the best solution.
Re: (Score:1)
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! (Score:4, Insightful)
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 (Score:3, Insightful)
Re: (Score:3, Informative)
These are MRAM chips. Fast as flash but as reliable as ram. Write, page and thrash all you want.
Re: (Score:2)
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: (Score:2)
Use a non-journaled fs with no write cacheing. (Score:2, Insightful)
FS specifically for Flash & embedded systems (Score:5, Informative)
-- Emery Berger [umass.edu], Dept. of Computer Science, UMass Amherst
Block Emulation in Compact Flash (Score:5, Insightful)
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: (Score:2)
Can you provide URLs that talk about that?
Re: (Score:2, Informative)
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 (Score:2, Interesting)
NVSRAM as a journal? (Score:2)
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 (Score:2)
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? (Score:2)
Red herrings (Score:2)
Is it really a problem? (Score:2)
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 (Score:2)