Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Which Filesystem is Best for CompactFlash?

Cliff posted about 8 years ago | from the minimizing-writes dept.

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

Sorry! There are no comments related to the filter you selected.

A little large for JFFS2, but that is being fixed (3, Interesting)

hpa (7948) | about 8 years ago | (#16509667)

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 (4, Informative)

big daddy kane (731748) | about 8 years ago | (#16511497)

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 (4, Informative)

r00t (33219) | about 8 years ago | (#16512595)

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 (1)

Sleeping Dog (5913) | about 8 years ago | (#16514605)

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. (4, Insightful)

DerekLyons (302214) | about 8 years ago | (#16509723)

Once you've already chosen the wrong hardware - no amount of software will fix the problem.

Re:A solution in search of a problem. (4, Insightful)

Smidge204 (605297) | about 8 years ago | (#16509965)

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. (3, Insightful)

dgatwood (11270) | about 8 years ago | (#16510743)

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.

Re:A solution in search of a problem. (1)

modecx (130548) | about 8 years ago | (#16513411)

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:A solution in search of a problem. (2, Informative)

Anonymous Coward | about 8 years ago | (#16514251)

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:A solution in search of a problem. (2, Interesting)

dgatwood (11270) | about 8 years ago | (#16518863)

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:A solution in search of a problem. (1)

dgatwood (11270) | about 8 years ago | (#16519125)

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

Re:A solution in search of a problem. (1)

darkonc (47285) | about 8 years ago | (#16555298)

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:A solution in search of a problem. (1)

DerekLyons (302214) | about 8 years ago | (#16512923)

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:A solution in search of a problem. (1)

Smidge204 (605297) | about 8 years ago | (#16514351)

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=

Re:A solution in search of a problem. (0, Interesting)

Anonymous Coward | about 8 years ago | (#16510165)

and your other suggestions are?

Odd, ext2 works well for me (5, Informative)

notarus (216298) | about 8 years ago | (#16509757)


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 (4, Interesting)

notarus (216298) | about 8 years ago | (#16509791)

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 (4, Informative)

MikeFM (12491) | about 8 years ago | (#16512963)

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:Odd, ext2 works well for me (1, Informative)

Anonymous Coward | about 8 years ago | (#16519039)

have you ever heard of tmpfs

Re:Odd, ext2 works well for me (1)

MikeFM (12491) | about 8 years ago | (#16531625)

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 (5, Funny)

Anonymous Coward | about 8 years ago | (#16509879)

It's murder to install and debug.

I don't have any mod points... (1)

Archeopteryx (4648) | about 8 years ago | (#16510639)

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

Re:I don't have any mod points... (2, Insightful)

hugetoon (766694) | about 8 years ago | (#16514019)

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:I don't have any mod points... (2)

Archeopteryx (4648) | about 8 years ago | (#16516117)

She's dead and feels nothing.

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

Re:I don't have any mod points... (1)

Lars T. (470328) | about 8 years ago | (#16519837)

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

Re:I don't have any mod points... (1)

xsonofagunx (902794) | about 8 years ago | (#16514699)

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 (1, Funny)

Anonymous Coward | about 8 years ago | (#16511039)

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

RIP, hot grits, we barely knew ye.

Re:Don't use Reiser (0)

Anonymous Coward | about 8 years ago | (#16513631)

It's murder to install and debug.

But once it's installed, it's a killer filesystem!

Unwriteprotecting a CF card? (2, Interesting)

NeMon'ess (160583) | about 8 years ago | (#16510017)

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?

Re:Unwriteprotecting a CF card? (4, Informative)

duguk (589689) | about 8 years ago | (#16510777)

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:Unwriteprotecting a CF card? (1)

feld (980784) | about 8 years ago | (#16511033)

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

Re:Unwriteprotecting a CF card? (1)

Technician (215283) | about 8 years ago | (#16512545)

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 (1)

Technician (215283) | about 8 years ago | (#16512753)

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

Re:Unwriteprotecting a CF card? (1, Interesting)

Anonymous Coward | about 8 years ago | (#16513429)

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.

      http://www.engatiki.org/2005/04/28/4 [engatiki.org]

      http://www.engatiki.org/flashrecover [engatiki.org]

      http://acmedigitalphotography.com/blog/?p=105 [acmedigita...graphy.com]

      http://wwww.mckeay.net/secure/2004/10/using_dd_to_ clone_a_hd.html [mckeay.net]

Good Luck.

Re:Unwriteprotecting a CF card? (1)

bcmm (768152) | about 8 years ago | (#16514695)

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:Unwriteprotecting a CF card? (1)

bcmm (768152) | about 8 years ago | (#16514743)

s/your/you're

Re:Unwriteprotecting a CF card? (1)

Gulthek (12570) | about 8 years ago | (#16518101)

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

Re:Unwriteprotecting a CF card? (1)

bcmm (768152) | about 8 years ago | (#16521539)

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:Unwriteprotecting a CF card? (1)

bcmm (768152) | about 8 years ago | (#16521623)

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

Re:Unwriteprotecting a CF card? (1)

xsonofagunx (902794) | about 8 years ago | (#16514779)

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 card, which you really shouldn't be editing (a lot of digital cameras have pseudo-proprietary methods of writing to the cards). Look through the settings on the printer [the actual printer hardware, not the settings in the printer's Windows drivers] for a read-only lock on memory cards. There's probably nothing wrong with your memory card, you just have to tell the printer to allow writing to it.

Doesn't CF already do this for you? (5, Insightful)

andyross (48228) | about 8 years ago | (#16510021)

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? (3, Interesting)

oz_paulb (617486) | about 8 years ago | (#16510099)

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? (1)

AZPolarBear (661815) | about 8 years ago | (#16510921)

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:Can any explain how wear-leveling really works? (3, Informative)

oz_paulb (617486) | about 8 years ago | (#16511023)

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:Can any explain how wear-leveling really works? (1)

Sloppy (14984) | about 8 years ago | (#16511741)

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:Can any explain how wear-leveling really works? (1)

buysse (5473) | about 8 years ago | (#16511993)

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:Can any explain how wear-leveling really works? (1)

Anakron (899671) | about 8 years ago | (#16512605)

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.

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

Anonymous Coward | about 8 years ago | (#16512133)

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.

I don't know the details, but I don't see how this problem is different from a wear-leveling filesystem on unvirtualized flash. I'd assume they work in the same way.

CF cards do NOT do atomic writes (5, Informative)

Anonymous Coward | about 8 years ago | (#16512287)

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. (4, Insightful)

Yaztromo (655250) | about 8 years ago | (#16510033)

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. (1, Interesting)

Anonymous Coward | about 8 years ago | (#16510337)

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:Damnsmalllinux agrees with you. (0)

Anonymous Coward | about 8 years ago | (#16511049)

As for Reiser, he's been charged with murder and the future of the file system is somewhat in doubt.
What does that have to do with Reiser3? It's already quite stable...

Re:Damnsmalllinux agrees with you. (3, Funny)

Anonymous Coward | about 8 years ago | (#16511295)

More stable than the author, even.

Thank you, I'm here all week.

Re:Beware journaling on flash. (3, Insightful)

merreborn (853723) | about 8 years ago | (#16511005)

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:Beware journaling on flash. (2, Interesting)

notarus (216298) | about 8 years ago | (#16512057)


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 written to and synced; if you never write to the disk, what is a journal saving you from?

I personally have great experience with EXT2 on CF, so it's what I recommend.

Re:Beware journaling on flash. (1)

big daddy kane (731748) | about 8 years ago | (#16511529)

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:Beware journaling on flash. (0)

Anonymous Coward | about 8 years ago | (#16531379)

Parent said: "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."

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.

It is worth noting that there is a minor amount of extra writing to the flash (the journal). Also, you must always keep at least one or more (varys with journalling flash-file system) flash blocks free -the flash can never be completely "full" on a write-enabled journalling flash-file system.

Re:Beware journaling on flash. (1)

Ihlosi (895663) | about 8 years ago | (#16543600)

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

topham (32406) | about 8 years ago | (#16510085)


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.

Re:File system isse, or application level issue... (0)

Anonymous Coward | about 8 years ago | (#16510349)

Most journaling filesystems have options to also journal the data, so even though you don't necessarily get a completely consistent data state, at least you don't corrupt previously written data. A DBMS should ideally protect against inconsistencies after power failures. After a commit has been issued, the whole transaction is either on disk or completely lost if the power fails while the data is being written. The only thing missing from data journaling filesystems which would give them that capability is a transaction mechanism by which the application can tell the filesystem what the consistent data states are.

ReiserFS will kill you files... (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16510137)

... and your wives files too

let me guess - gaming terminal? (4, Informative)

toby (759) | about 8 years ago | (#16510145)

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

jffs was designed (2, Informative)

elhedran (768858) | about 8 years ago | (#16510173)

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:jffs was designed (1)

TheRaven64 (641858) | about 8 years ago | (#16511507)

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:jffs was designed (1)

elhedran (768858) | about 8 years ago | (#16511661)

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 choosing the file system for a flash based storage so my information may be a little out of date.

you need to revisit your design. (3, Insightful)

isaac (2852) | about 8 years ago | (#16510177)

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? (1, Interesting)

Anonymous Coward | about 8 years ago | (#16510201)

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

It's obvious. (-1, Redundant)

Anonymous Coward | about 8 years ago | (#16510279)

If you're looking for a killer filesystem, Reiser is the only way to go!

I'd recommend doing experiments (4, Informative)

davidwr (791652) | about 8 years ago | (#16510363)

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:I'd recommend doing experiments (1)

piranha(jpl) (229201) | about 8 years ago | (#16512945)

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 (2, Interesting)

slimjim8094 (941042) | about 8 years ago | (#16510375)

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? (1)

gweihir (88907) | about 8 years ago | (#16510567)

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

Too bad you can't use ZFS (2, Insightful)

Wesley Felter (138342) | about 8 years ago | (#16510735)

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:Too bad you can't use ZFS (2, Informative)

KonoWatakushi (910213) | about 8 years ago | (#16511613)

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 replicated metadata for pool and filesystem structures, making it nearly impossible to damage an entire filesystem or pool. Even if data blocks are damaged, in addition to maintaining access to all other good data, you will know exactly what has been lost.

While I'm not 100% certain, I don't think most flash uses ECC. Once blocks start going bad, other filesystems will simply fall apart.

Rediculous Suggestions (1)

feld (980784) | about 8 years ago | (#16510883)

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.

partitions as files (0)

Anonymous Coward | about 8 years ago | (#16511127)

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.

reiser4 (0)

Anonymous Coward | about 8 years ago | (#16511231)

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

Re:reiser4 (1)

brokenin2 (103006) | about 8 years ago | (#16523177)

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 that best technical solution.

Entire CF Drive should be Read Only! (3, Insightful)

Fallen Kell (165468) | about 8 years ago | (#16511615)

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 (3, Insightful)

molafish (860593) | about 8 years ago | (#16512325)

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.

Re:Entire CF Drive should be Read Only! (2, Informative)

mnmn (145599) | about 8 years ago | (#16513029)

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:Entire CF Drive should be Read Only! (1)

infolib (618234) | about 8 years ago | (#16538560)

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:Entire CF Drive should be Read Only! (1)

mnmn (145599) | about 8 years ago | (#16539236)

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. (2, Insightful)

jonadab (583620) | about 8 years ago | (#16511833)

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.

HungWeiLo (0, Offtopic)

seann (307009) | about 8 years ago | (#16512051)

Insert humour about the nickname being "hung well, low"

Oh slashdot.

Re:HungWeiLo (0)

Anonymous Coward | about 8 years ago | (#16512931)

You've found the mystery clue. You win a free year's worth of first posts.

FS specifically for Flash & embedded systems (4, Informative)

Ristretto (79399) | about 8 years ago | (#16512383)

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 (5, Insightful)

Not Invented Here (30411) | about 8 years ago | (#16514031)

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:Block Emulation in Compact Flash (1)

bgat (123664) | about 8 years ago | (#16515571)

> smartmedia and xD cards expose a raw NAND interface

Can you provide URLs that talk about that?

Re:Block Emulation in Compact Flash (2, Informative)

Not Invented Here (30411) | about 8 years ago | (#16516097)

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 (2, Interesting)

bucksontour (1016003) | about 8 years ago | (#16515093)

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.

Re:ext3 in full journaling mode (0)

Anonymous Coward | about 8 years ago | (#16528551)

Similar story here ... I'm using an old 2.4 kernel with ext3 on a 512MB CF card. The biggest problem is enabling DMA. I don't have DMA explicitly disabled; the kernel seems to be chosing the best options so far. We also used Kingston parts but they are not good choices because they change the parts without changing the part number. The best CF cards I've found are the Toshiba THNCF512MBA or THNCF512MDG. The first is commercial grade, the latter industrial. Some people think we need industrial parts but those are just temperature specs and actually reduce lifetime from what I've read. On ext3, be sure to set 'noatime'. As others have mentioned, flash file systems do not apply to CF. When Kingston started giving us Samsung parts they would fail within a month. Without DMA I've seen them fielded for almost a year for the oldest shipped part. These systems go through temperature and vibration extremes with intermittent power cycles (half a dozen a day or so) and we are seeing _regular_ lifetimes of over 2 years (they've only been deployed about 3). The better you can minimize writing to flash the better. You said that you had a 'database' ... depending on the criticality of the data, you may want to consider writing to a RAM filesystem and periodically flushing it to CF. Also be aware of hardware issues. We tried some Sandisk parts that seem to work OK in cameras, etc, but in our hardware corrupt themselves -- and not as in filesystem level corruption, but in "put this in your card reader and the operating system locks up" type corruption (Windows locks up, Linux crashes the USB subsystem). Finally, when selecting parts, research is critical - you definitely want MLC parts and not all wear leveling algorithms are created equal. If you have a huge chunk of static data many CF parts will not use these for wear leveling so you actually end up wear leveling only a tiny portion of the CF and it readily degrades. Of course, if you get to evaluate any samples of PCM/PRAM (http://hardware.slashdot.org/article.pl?sid=06/09 /29/1242219) please be sure to let us know!

NVSRAM as a journal? (1)

toybuilder (161045) | about 8 years ago | (#16515507)

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.

JFFS and UnionFS (1)

rwa2 (4391) | about 8 years ago | (#16518635)

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.

How about a RAMDISK? (1)

green pizza (159161) | about 8 years ago | (#16520147)

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.

Mildly OT (0)

Anonymous Coward | about 8 years ago | (#16524715)

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.

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 /boot and /etc on flash anyway... And we're also hitting the dma/pio CF problem :-((..

Red herrings (1)

meowsqueak (599208) | about 8 years ago | (#16532123)

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.

What I did (0)

Anonymous Coward | about 8 years ago | (#16561188)

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.

Is it really a problem? (1)

Overzeetop (214511) | about 8 years ago | (#16570692)

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.

Shutdown sequence or improved CF (1)

jbeaupre (752124) | more than 7 years ago | (#16579890)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?