Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have am embedded ARM-based system running on an SD card. It's currently Debian GNU/Linux using ext3 as filesystem. As I'm about to reinstall the system, I started wondering about changing to a more flash-friendly filesystem. I've heard about JFFS2, YAFFS2 and LogFS, and they all seem suited to the job. Which one would you recommend? Also, I've heard there have been a lot of ext4 improvements to better suit SSD disks; am I to interpret that as running ext4 should be just fine? What do I need to think especially about in that case?

I guess the usage of the system is important. But for the sake of generality, imagine it'll do standard desktop stuff (even though it is infact a small ARM-based system).

Thanks for any replies.

Edit: Wikipedia tells me (in a "citation needed" statement) that Removable flash memory cards and USB flash drives have built-in controllers to perform wear leveling and error correction so use of a specific flash file system does not add any benefit. Thus, I'm leaning towards sticking with an ext filesystem.

share|improve this question
add comment

3 Answers

up vote 8 down vote accepted

Excellent article about flash filesystems.

Important question when talking about flash filesystems is following: What is wear leveling? Wikipedia article. Basically, on flash disks you can write limited number of times until block goes bad. After that, filesystem (if there is no built-in wear leveling management on hardware, as in case of SSDs there usually is) must mark that block as invalid, and avoid using it anymore.

Typical filesystems (for example reiserfs, ntfs, ext3 and so on) are designed for hard disks, that do not have such limitations.

JFFS2

Includes compression and elegant wear leveling protection.

YAFFS2

  • Single thing that makes the difference: short mount times, after successful umount.
  • Implements write once property: once data is written to one block, there is no need to rewrite it. This is important for protecting against wear leveling.

LogFS

  • Not very mature, but already included in Linux kernel tree.
  • Supports larger filesystems than JFFS2/YAFFS2 without problems.

UBIFS

  • More mature than LogFS
  • Write caching support
  • On scalability: article. On large disks, better performance than with JFFS2

ext4

If no driver or card (for example SSD drives do have internal wear leveling, at least usually) handle wear leveling, then ext4 is not the best idea, as it is not intended for raw flash usage.

What is best one?

Of course, it depends on usage and support. From what I read from the internet, I would recommend UBIFS. Good support for large filesystems, mature development phase, adequate performance and no huge downsides.

share|improve this answer
3  
Thanks, this is very informative! However, the "big red note" from the UBIFS website says: "One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware." –  gspr Feb 20 '11 at 13:21
    
Nice answer, plus there is F2FS from Samsung, also very promising system, quite new tho. –  lzap Jun 23 '13 at 15:00
2  
@gspr is correct: SD has a flash translation layer, and JFFS2, YAFFS2, LOGFS and UBIFS are all designed for unmanaged flash. The options for SD are traditional block device filesystems, like ext2 / ext3 / ext4. –  Robert Calhoun Jan 21 at 16:12
add comment

I was facing the same problem and did some research as well. Eventually I decided to go with ext2.

It seems that some SDHC cards implement their own wear-leveling at the hardware layer. If you can get hold of SDHC cards that have wear-leveling buit-in.

Filesystems that provide wear-leveling can interfere with the Flash-level wear-leveling so it can actually be bad for the flash to use them (the IBM article cited above talks about how JFFS does it, so it's clear that that won't work with flash-level WL). I decided I didn't need ext3's journaling since I'm not storing critical data on it and I usually backup regularly anyway (cron).

I also mounted /tmp and /var as tmpfs to speed things up. If you have enough RAM you should do that (but be sure to rotate or delete your logs regularly)

HINT: Mount your ext SD cards with the "noatime" option

share|improve this answer
    
I've had problems with old SD-cards and ext2 (data corruption) that went away when switching to XFS instead. –  Alexander Jan 13 '13 at 14:01
add comment

I don't know if this fits into your system's profile, but what about using a readonly filesystem plus a read-write partition (or a usb stick that can be replaced easily)? That way you'll have a fast disk for your OS and can replace your rw storage easily when it wears out.

And then there's unionfs. As i understood it it "stacks" different filesystems (i.e. a ro fs on top of a rw fs). If there's a read access unionfs seeks through th stack until it hits the FS containing the file we search for. When writing unionfs searchs for the first writeable FS on the stack und uses it.

I also found these articles that may be interesting: http://www.linux-mag.com/id/7357/ http://www.linux-mag.com/id/7345/

And two articles with tips for using SSDs: http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a-tweakers-guide-to-solid-state-drives-ssds-and-linux/9190

share|improve this answer
1  
Note that I'm not the one who downvoted this answer. It contains useful information in general, but it's not related to what I need. Thanks anyway :) –  gspr Feb 20 '11 at 13:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.