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

5 Answers 5

up vote 9 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
7  
@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

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

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

Selecting (and sizing) the correct file system is more important than anything else, not only for security but for tons of other reasons people do not usually recognize. Without a file system all processing would go to null.

Very well put response by Olli, and the OP is much dated, but file systems are my pet peeve I could not stay away. superuser.com is not something I visited before, I am not an admin, but I signed up and I am going to visit more.

Things changed a lot since 2011, but even back then I formatted USB cards FAT, and used USB drives to carry 4Gb+ files around. The reason of course was compatibility not security (so much for S in SD, but I use passwords on my 7z's), and I never really carried anything bigger than a CD ISO, they were mostly for SQL scripts and daily-hourly diffs of already encrypted database snapshots squeezed to near death by 7-Zip.

These days I wear any SD out faster than anyone I know. I have a USB stick in some production machines at my employer for hourly automated backup, formatted FAT. I keep an eye on them every day though and - you guessed - back them up religiously by hand (they are off-line secured building ITAR stuff). SSD leveled some of the playing field but I still do not trust them as much as regular HD, and SD is worse than optical. They go bad in an instant and the loss is total.

Any file system which invites the host OS to write randomly to it (NTFS, Recycle Bin) is bad news for an SD. Also, unmounting it helps a lot, no OS is going try accessing unmounted storage, so any file system will do as long as the SD includes a script to unmout itself (one of the standard files on every SD on mine).

Reading an SD is still slow today, so I would recommend something like disk dump (dd) to grab the entire image when mirroring instead of file-by file. dd also let you know when there is something wrong, so your file manager won't go kaboom.

Of course, if your primary purpose is to extend the life of some penny-stock you are going about your business the wrong way. I do what I do not for extending the life of an SD but to keep it from going bad when I am not watching, and there is the difference.

I avoid ext4 or any journaling FS on SD because I do not care when they go bad writing to them, but it sure hurts when a day or so later I cannot read them!

share|improve this answer
    
Sorry but this does not really answer the question. It's an interesting essay on use of removable media but not about choice of filesystem. –  suspectus May 18 at 9:59
    
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. –  Dave M May 18 at 11:18
    
I wanted to comment but I could not. The post is a bit verbose, what I recommended was neither the OP was considering, I instead recommended FAT. I should have composed with more focus and clarity for sure. –  arch-abit May 18 at 14:38

As response to recommendation to use fat (32?): I have done some performance tests and find out that fat32 has a very predictable time to write a file (2 GB needs two times of 1 GB + offset, 3 GB needs tree times of 1GB + offset). Performance of ext4 is slightly better than ext3. Both ext3 and ext4 are sometimes fast but need sometimes some extra time to write the journal files to disk (no linear write time behaviour). All test were done with fsync() to be sure that file is really written to disk. I performed some tests with sync(). They result in very bad write performance. So I went back to fsync(). I did some check whether fsync() is sufficient. Therefore I powered of the device without system shutdown or removed the SD Card without unmount. In no case the written files or the directory structure were damaged. So we decided to use ext4 and only fsync().

Regards, Thomas

share|improve this answer

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.