Choice of filesystem for GNU/Linux on an SD card

Question

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.

Solution 1

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, as it reduces wear.

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.

Which one is the best?

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

Solution 2

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

Solution 3

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!

Solution 4

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

View more solutions

Comments

[gspr]

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]

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

[Alexander]

I've had problems with old SD-cards and ext2 (data corruption) that went away when switching to XFS instead.

[lzap]

Nice answer, plus there is F2FS from Samsung, also very promising system, quite new tho.

[Nick]

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

[suspectus]

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.

[arch-abit]

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.

[Hi-Angel]

Why is Any file system which invites the host OS to write randomly to it (NTFS, Recycle Bin) is bad news for an SD.? It doesn't consist of rotating disks, so wherever you read/write shouldn't matter, I think. And btw, NTFS writes contiguously — which leads to fragmentation. «Random stores of files» is, e.g., about EXTα.

[Hi-Angel]

The comparison is unfair. You compared non-journaling FAT with journaling EXT3/4. You ought to compare FAT vs EXT2. And just FYI, the file system that came preformatted by manufacturer usually have the most optimal block sizes/offsets. I.e. after you reformatted the file system, there's a possibility that IO would take longer than with the original one.

[SebMa]

@Olli Is NILFS2 a good choice for a SSD drive ?

[Brian Chrisman]

This is completely unrelated to the question of SD Cards and flash which may or may not require wear leveling.