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. 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.
I was under the impression that CF cards, which present a traditional 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.
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?
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.
Ext2 is thus a good choice, as may be Reiser3 with journaling disabled. 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. 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. There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Our business in life is not to succeed but to continue to fail in high spirits. Follow Slashdot stories on Twitter. Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and take advantage of SourceForge's massive reach.
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. Does anyone have any experience using filesystems in this situation? Which one should I look into for this type of application? This discussion has been archived. No new comments can be posted. Which Filesystem is Best for CompactFlash?
More Login. Archived Discussion Load All Comments. Full Abbreviated Hidden. So if you can wait a bit, then JFFS2 is probably the right answer. Share twitter facebook. YAFFS [aleph1. 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.
Parent Share twitter facebook. 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.
Wondering how comes that Logfs from Jorn Engel didn't come up in the discussion yet. A solution in search of a problem. Score: 4 , Insightful. Once you've already chosen the wrong hardware - no amount of software will fix the problem. Re:A solution in search of a problem. Score: 5 , Insightful.
So what do you know about this guy's project that the rest of us don't? Re: Score: 3 , Insightful. Re: Score: 1. 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. 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. Re: Score: 3 , Interesting. Re: Score: 2. Score: 2. 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.
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. 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. 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 Score: 5 , Informative. 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: Score: 1 , Informative. 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 Score: 5 , Funny. I don't have any mod points Re: Score: 2 , Insightful. 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: Score: 3. She's dead and feels nothing. The type II slot is used by miniature hard drives and in some specialty cameras, but is not as common. We now have CF 6. This mode is entered when the card has pin 9 grounded on the 50 pin connector when power is applied. The passive adapter takes care of grounding pin 9. CF devices must operate at 3. CF cards with flash memory are able to cope with extremely rapid changes in temperature. Ultra DMA capable, these cards are capable of very high data transfer rates, provided the controller mapping is efficient.
Usually page based mapping is used in the higher end cards. For example, x rating means transfer speed of: x. Manufacturers are now placing the speed ratings on cards.
These are manufacturer speed ratings. Actual transfer speed may be higher, or lower, than shown on the card depending on several factors. The speed rating quoted is almost always the sequential read speed, while write speeds are often slower. As a note, the USB 2.
USB 3. These generally use a bridge chip which is capable of Ultra DMA modes. This is when the true card capability can be seen. CF card us in embedded systems, such as routers has been very popular even in the present. Legacy routers almost always contain CF cards. Direct connection of the 50 pin parallel bus to a CPU is not practical, although it was done in the old legacy systems, at a time when PATA drives were common.
This should allow full potential of the CF card to be realized. On a standard CF type 1, there is a physical limitation on the number of Flash packages that can be placed on the PCB.
Therefore, card capacity is limited by this and the density of each Flash package. Another way to increase capacity is by using bonded die on a substrate. This is expensive and only makes sense in high end applications, not consumer products. Capacities of GB and GB are common. A factory preformatted CF card is file system agnostic.
At that point, the card can be high level formatted with any file system. By far the most popular file systems used are from the Windows OS. This is typical in embedded systems such as routers. These features are there to support Industrial and critical applications.
It is important to select a CF card vendor for critical applications that can support the addition of customer specific functions, as well as having support for solving compatibility issues should they arise.
Very similar in electrical operation and form factor. Popular for use in embedded systems. Operating voltages are 3. Mode is determined at power up, by the host device driver, sending a special command into the card. SPI mode is a 1 bit mode, which is speed limited, but popular in micro-controller applications. SPI interfaces are common in the micro-controllers. This is with a 25 MHz Host Clock. The DupliCFast series is a standalone, highly efficient professional grade duplicating unit, specifically designed for CFast flash memory card duplication.
These professional CFast flash cloning devices are standalone, requiring no computer hardware or The DupliCF series is a standalone, highly efficient professional grade duplicating unit, specifically designed for CF flash memory card duplication. These professional CF cloning devices are standalone, requiring no computer hardware or software to The EconoCF series is a standalone, highly efficient professional grade duplicating unit, specifically designed for any CF flash memory drive duplication.
0コメント