compact flash as read/write file system

F

feh

n00b
Joined
Sep 7, 2010
Messages
11
Hi folks.

I'm developing an appliance based on a single board computer, that will run linux. The storage medium on the SBC is compact flash.

The SBC does not have sufficient memory to keep the file system(s) in memory, so I will need to have a read/write file system on the flash. I've done this in the lab; everything is working just fine.

My concern is the reliability of the CF card. I've done some research; I realize they aren't meant to be rewritten indefinitely. I've read comments across the spectrum, from "never use CF for a read/write file system" to "don't worry about it; the CF won't wear out for 20 years".

So, a couple questions:

  1. Is this something to be concerned about, or are CFs made today durable enough use as general purpose read/write devices?
  2. Does the specific type of CF matter? Am I ok if I use SLC flash? Is MLC flash acceptable?
  3. What file system should be used? UBIFS? JFFS2? EXT3?

Thanks!
 
There's a difference in writes:

large writes for large files like JPEG, AVI, on simple FAT filesystem
small writes for OS accesses, metadata updates, etc.

To write a 4MB file your flash has to write... 4MB. Not much news here. But to write 512 bytes; depending on the NAND in the compactflash you may have to read 127.5KiB, erase 128KiB + write 128KiB. That is called write amplification and it is especially severe on controller-less NAND or very rudimentary controllers who do no write remapping.

Modern SSDs ARE good at small writes; by writing that data elsewhere instead without the hassle of reading a whole erase block, erasing the block and writing the whole block; that's alot of write cycles and very slow as well.

In short, you can wreck a CF card within a month of normal usage because of all the small writes burning holes in your NAND write cycles.

How much RAM are we talking about? You can tune the system heavily for only minimal writing, but compactflash might still wear out before its economical lifespan.
 
sub.mesa said:
There's a difference in writes:

large writes for large files like JPEG, AVI, on simple FAT filesystem
small writes for OS accesses, metadata updates, etc.

To write a 4MB file your flash has to write... 4MB. Not much news here. But to write 512 bytes; depending on the NAND in the compactflash you may have to read 127.5KiB, erase 128KiB + write 128KiB. That is called write amplification and it is especially severe on controller-less NAND or very rudimentary controllers who do no write remapping.

Modern SSDs ARE good at small writes; by writing that data elsewhere instead without the hassle of reading a whole erase block, erasing the block and writing the whole block; that's alot of write cycles and very slow as well.

In short, you can wreck a CF card within a month of normal usage because of all the small writes burning holes in your NAND write cycles.

How much RAM are we talking about? You can tune the system heavily for only minimal writing, but compactflash might still wear out before its economical lifespan.
Click to expand...

The device has 256MB of RAM. I need probably half of that just for the primary application, so sticking a file system in RAM is not an option.

Thanks.
 
i used a CF to IDE bridge to power a linux router. the CF card died after a few months from the read write cycle.

i use m0n0wall now and it has a flash memory option to prevent necessary disk writes.
 
Well, what sort of writing will you be doing? And I take it you don't need swap, at least?
 
dandragonrage said:
Well, what sort of writing will you be doing? And I take it you don't need swap, at least?
Click to expand...

Yeah, I wouldn't even attempt swap.

Most of the writing would be logging, so, frequent, small writes. At least, I think that's the case; I haven't actually profiled disk usage.
 
Forget CF then, either use NAND SSDs with proper wear leveling like small PATA/SATA SSDs which plug directly into the PATA/SATA port; Transcend comes to mind here. Or a small real SSD, or a small HDD instead.

Bare NAND will be ripped apart by small writes happening to the same locations. You need wear leveling + write remapping for decent write endurance on NAND when using it as OS/small writes.
 
Industrial CF is available that can sustain quite a lot of writing; it's designed for this sort of thing, though it's obviously still flash-based and has the problems sub.mesa describes, they are dealt with the same way they are in SSDs with intelligent wear leveling and higher-quality memory. I've had systems running on Industrial CF for a couple years now doing not-so-intensive-but-still-constant logging and haven't had any trouble.

Though if all you're doing is logging, I don't see why having 128MB free RAM is insufficient. Log to RAM, periodically rotate off to CF (or when the log hits 10MB or whatever), keep everything else read-only (except for a small working filesystem for your lockfiles and whatever else your application needs). Also if you're not doing much writing and rotate your logs off, a copy-on-write RAM filesystem would probably work fine as well, but it's a bit less predictable than managing the RAM-based storage specifically, so may not be suitable.

Or there's the log filesystem option (JFFS2, LogFS, etc.), though I'm not really sure how this impacts flash lifetime when the OS doesn't have direct access to the flash cells.
 
keenan said:
Industrial CF is available that can sustain quite a lot of writing; it's designed for this sort of thing, though it's obviously still flash-based and has the problems sub.mesa describes, they are dealt with the same way they are in SSDs with intelligent wear leveling and higher-quality memory. I've had systems running on Industrial CF for a couple years now doing not-so-intensive-but-still-constant logging and haven't had any trouble.
Click to expand...

Right; my term for "industrial" CF was SLC in my original post. Would that suffice?

Though if all you're doing is logging, I don't see why having 128MB free RAM is insufficient. Log to RAM, periodically rotate off to CF (or when the log hits 10MB or whatever), keep everything else read-only (except for a small working filesystem for your lockfiles and whatever else your application needs).
Click to expand...

We have considered doing this, if necessary. However, we'd like to avoid it if at all possible.
 
sub.mesa said:
Forget CF then, either use NAND SSDs with proper wear leveling like small PATA/SATA SSDs which plug directly into the PATA/SATA port; Transcend comes to mind here. Or a small real SSD, or a small HDD instead.

Bare NAND will be ripped apart by small writes happening to the same locations. You need wear leveling + write remapping for decent write endurance on NAND when using it as OS/small writes.
Click to expand...

Don't all CFs made today include wear leveling? Would the proper choice of FS (UBIFS?) alleviate or solve these issues?
 
Ive seen small Mini-PCIe SSDs of just a few GIGs around 40 dollars or so; perhaps some Mini-PCI SSDs also exist? That might be your best option.

You can also use Mini-PCI -> SATA or PATA controller and use a normal device (SSD/HDD). But make sure it supports booting else it wouldn't be much good to you. ;-)
 
feh said:
Right; my term for "industrial" CF was SLC in my original post. Would that suffice?
Click to expand...
I think so. It's what it's designed to do, and I've seen commercial products do just that. I'd still take care to avoid writing, or at least do it in buffered batches if possible. For the average appliance I think it's fine as long as you take some care to make sure there's not stuff left enabled that's doing 5 writes/second and that kind of thing.

We have considered doing this, if necessary. However, we'd like to avoid it if at all possible.
Click to expand...

Well you can certainly avoid it, decent flash should sustain a modest write load for a long time, but I don't see why you wouldn't set aside a few MB of RAM when you expect to have 100+MB available to reduce writes to essentially nil, as long as you can tolerate losing some logs on an unclean shutdown. Almost all embedded systems do this, and there's a reason for it. Less writes makes for a more reliable system; less chance of corrupting the filesystem and less write load on the storage media. One thing about embedded systems is that if the OS image gets screwed up because it's read/write, it's a hell of a lot more of a pain in the ass to fix than on a standard machine. Not to mention that flash is fscking slow.
 
feh said:
I don't know; the only storage interfaces on the board are a CF socket and miniPCI. Cost is a concern also; how much does a 4GB SSD cost?
Click to expand...

I got one I'll sell for $20, came from my brothers Mini 9. I gave him my 8GB one so I have his 4GB one in my drawer.
 
Zepher said:
I got one I'll sell for $20, came from my brothers Mini 9. I gave him my 8GB one so I have his 4GB one in my drawer.
Click to expand...

Well, we'll be producing hundreds/thousands of these devices, so I would need to find a vendor.
 
Followup question - can somebody please explain how an SSD is different from a CF card, in that the SSD can be used as a read/write device without fear of wearing out?

Thanks.
 
From my understanding SSDs use various technologies to try to slow down the wearing out process by spreading data more evenly across all "sectors", but they still do wear out, so I would not use one for an intensive read/write setup.
 
Red Squirrel said:
From my understanding SSDs use various technologies to try to slow down the wearing out process by spreading data more evenly across all "sectors", but they still do wear out, so I would not use one for an intensive read/write setup.
Click to expand...

I was under the impression (somebody please tell me if I'm wrong) that the controllers in CF cards do wear leveling. Throw in the option to use a file system specifically designed for the physical medium, such as UBIFS, and I wonder if a CF card couldn't be as reliable as an SSD.
 
feh said:
I was under the impression (somebody please tell me if I'm wrong) that the controllers in CF cards do wear leveling. Throw in the option to use a file system specifically designed for the physical medium, such as UBIFS, and I wonder if a CF card couldn't be as reliable as an SSD.
Click to expand...

I think you're right, most cards probably do. However, most are not well specified for write endurance or whether they have wear leveling, or even performance. I think if you're planning on developing the relatively large-scale installation you're talking about it's worth paying the extra few dollars a unit for clear specifications that you can base your design around.

IMO industrial CF is your best solution. It will integrate well with your embedded boards, is well specified and generally includes hardware error checking/correction, and is widely available at a pretty low price point. Performance isn't fantastic, but I doubt that's critical. Still, even though these are highly reliable, I wouldn't treat them like a hard disk; try to avoid writing as much as possible.
 
keenan said:
I think you're right, most cards probably do. However, most are not well specified for write endurance or whether they have wear leveling, or even performance. I think if you're planning on developing the relatively large-scale installation you're talking about it's worth paying the extra few dollars a unit for clear specifications that you can base your design around.

IMO industrial CF is your best solution. It will integrate well with your embedded boards, is well specified and generally includes hardware error checking/correction, and is widely available at a pretty low price point. Performance isn't fantastic, but I doubt that's critical. Still, even though these are highly reliable, I wouldn't treat them like a hard disk; try to avoid writing as much as possible.
Click to expand...

Thanks. I'm also starting to think SLC flash might be the best solution.

Does anybody know if UBIFS is a good choice for a file system on a CF card, or should UBIFS only be used on raw MTD devices?
 
feh said:
Thanks. I'm also starting to think SLC flash might be the best solution.

Does anybody know if UBIFS is a good choice for a file system on a CF card, or should UBIFS only be used on raw MTD devices?
Click to expand...

After a little experimenting, I've answered my own question - CF cards are seen as block devices, therefor UBIFS cannot be used on them.
 
You must log in or register to reply here.
Back
Top