I have a new embedded Linux project coming up. The hardware team has chosen an MMC Flash chip (part # MTFC64GJVDN-4M) for the system's non volatile memory; data sheet at http://www.micron.com/parts/nand-flash/managed-nand/mtfc64gjvdn-4m-it.

What would be the best Linux filesystem to use with this part? I believe it's a block type device, so the JFFS2 MTD type filesystems will not be suitable as they operate on the raw flash. I am looking for reliability first, then performance as secondary.

It is also my understanding that these MMC devices are like the "guts" of an SD card, i.e. have their own on-board controllers. I've had a pretty bad experience with SD cards failing before, I've had hardware failures where the card becomes un-readable. That was using the ext3 filesystem, so I am researching to see if there's anything better for this new project.

  • 1
    \$\begingroup\$ bunniestudios.com/blog/?page_id=1022 \$\endgroup\$
    – jippie
    Mar 7, 2013 at 19:57
  • 1
    \$\begingroup\$ Great link - thanks. Does anyone know what tool these guys are using to stress test their SD cards? \$\endgroup\$
    – SeanLabs
    Mar 9, 2013 at 0:39
  • \$\begingroup\$ Define "best" for your application. \$\endgroup\$
    – Dave Tweed
    Oct 14, 2016 at 11:28

2 Answers 2


If your filesystem is read-only, use ext2. That is proven stable for several decades, is fast, efficient, supports ownership, supports permission bits and has a huge user base as every Linux box supports it. In other words it supports everything a decent Linux system requires.

If read-only is not an option, your next best bet is ext3. Apart from all the properties that ext2 comes with, ext3 brings journaling. This means that every change on disk is only committed once it has actually been written to disk. Very stable, proven technology. A problem with ext3 is wear leveling.

Ext4 improves on performance in several use cases, but comes with more CPU overhead. Most distributions today default to ext4. Apparently it reduces unnecessary writes, which is good for an SSD. Ext4 has a TRIM extension.

Next in line it BTRFS. Don't go there. Although several distributions offer BTRFS or even default to it, it wasn't stable last time I tested it (H2 2012). You don't want to use a filesystem that hasn't proven itself under stress. Too many bugs are being fixed.

Linux offers a wealth of filesystems, but the ones I mentioned above are the most common ones.

Of course there is FAT32 (vfat), don't go there. It is old, it suffers from fragmentation and doesn't allow for ownership and file permissions.

NTFS is closed source, don't even think about it. Yes it kinda works on Linux but the implementation is fully based on reverse engineering (because Microsoft doesn't release any technical details) and the Linux implementation is just not reliable.

A JFFS2 needs to be entirely scanned on a mount, so mount time increases linearly with device size. This is caused by the fact that there is not some sort of tree structure to store files.


This seems to be an eMMC part (mind the small "e" in front). Basically this means that this is a "solderable SD-card". You might want to compare it to a SD-card and not to a NAND-Flash. Furthermore, this means that it has additional logic such as wear-logic and it also has a MMC Interface and NOT a NAND-Flash interface.

Since the card already includes Wear-Logic, the actual file system doesn't matter so much. It is more a question of praparing your partition (e.g. readonly partitions).

In case you really want to evaluate file systems, the following should be ok (no particular order): F2FS, BTRFS, EXT4.

Also understand that depending on your controller, the bootloader or similar will be placed at a very specific position outside every file system.

  • 1
    \$\begingroup\$ Hadn't heard of F2FS before, will check it out. I have tested EXT4 on an SD card before, seemed to work fine, but people seem to be concerned that the journal creates a number of extra writes. I might post another question regarding best partitioning layout to use. \$\endgroup\$
    – SeanLabs
    Mar 7, 2013 at 20:43
  • 1
    \$\begingroup\$ Regarding Journaling: Yes it does, but since wear leveling is already done by the controller I'd consider this a very minor issue. \$\endgroup\$
    – Tom L.
    Mar 7, 2013 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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