The Pi is using a EXT4 or EXT3 or FAT file systems which are not meant for low level flash devices. It might work very well on flash devices that uses internal (and hidden) wear leveling techniques (such as nowadays SSD), but not on basic flash device that does not embeds any advance wear leveling techniques.

For basic flash devices, file systems such as JFFS2 or UBIFS are designed to do the wear leveling at the file system level and makes sure that the wear leveling is applied and somewhat effective. Theses file systems are commonly used on embedded platforms, where the flash drive is a flash chip mounted on the PCB of the system. Such flash chips embedded nothing: the address you give is the address of the cell. No magic! JFFS2 does the job of wear leveling and delaying the writes, etc... But more than that: It is not lying to the system. When JFFS2 says that the data is written and flushed on the medium, it is the case!

My question is: Is it possible to have a root partition that is using JFFS2 or UBIFS instead of the EXT4 that is not working very well here?

I know that the boot partition has to be in FAT, but that's not a problem because it is read only. But where is problem to have the root partition in JFFS2 or UBIFS?

There is a lot of people complaining about the data corruption and that the wearing of the SD card is not under control, but a part of the solution exists: It's about choosing the right file system for the right medium.

What is the problem with this? I haven't seen people using an appropriate file system. Is there a restriction somewhere?

  • 4
    Top brand SD cards have inbuilt wear leveling.
    – Gerben
    Nov 26 '13 at 15:20
  • 1
    @Gerben I see, but what about the approach of using low cost SD cards and having the wear leveling in software? I have seen a lot of posts about people complaining about corruptions and I don't think they all were using low cost card, some were using high end one. But they still have to do some tricks such as "TRIM" command at regular interval, etc. A FS should be autonomous enough that you don't have to manage such low level tasks yourself in a cron job. That would never occur if we were using a FS designed for flash memories.
    – Blup1980
    Nov 27 '13 at 6:34
  • Not sure how many corruptions were due to power outage/incorrect shutdown. It seems that running from an external usb memory stick, is a bit more robust. I can't really help you with J2FS and the likes. Thought I'd guess you have to recompile the kernel, as J2FS is not supported by it (without mods).
    – Gerben
    Nov 27 '13 at 14:13
  • 1
    Sorry, no. The Pi is still corrupting SD cards when a server such as MySQL is hosted.
    – Blup1980
    Apr 7 '14 at 17:26

It is possible. And I am running my pi with it.

[root@rasp-rodhome ~]# grep jffs2 /proc/mounts 
/dev/root / jffs2 rw,noatime 0 0
[root@rasp-rodhome ~]# cat /proc/version 
Linux version 3.19.0-rc7.17.rf (rfreire@rf.usersys) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #3 Sun Feb 8 21:14:52 BRST 2015

However, first, a big fat red note: Please ensure to read thorougly the JFFS2 FAQ. After reading and fully understanding it, and you still think that it fit your needs, keep reading.

  1. You will need to recompile your kernel. The JFFS2 support is compiled as a module in Raspbian; we need it compiled built-in the kernel. You might want to recompile Raspbian's kernel or use a upstream kernel. For upstream kernel, refer to this eLinux article. As a FYI, I have used the upstream kernel.

  2. In order to make JFFS2 run atop a SD card, you will need to use a kernel trick, named block2mtd. block2mtd will emulate a mtd device, based on a block device (regular block device partition).

    • IMPORTANT NOTICE: block2mtd won't play ball nicely on kernel until version 4.0 on Raspberry Pi during boot time. If you are trying to compile a kernel equal or less than 4.0, you will need to apply this patch. If you want to know the gory details, check the lenghty discussion at lkml.
  3. Now that you have sucessfully built and booted your new kernel, you will need to create your JFFS2 data. Create your image and ensure to add the EBS (Erase Block Summary; speeds up the mount). Use 64 kb erase block size. How to create the JFFS2 image: Please read this. I strongly suggest to run this step on a PC.

  4. To write the image, just run dd if=<jffs2 image> of=/dev/mmcblk0p<JFFS partition number> Pro tip: Keep partition 1 to boot, 2 to ext4 (fallback) and 3 to JFFS2.

  5. Now that your SD card is good to go, edit your boot.scr (assuming that you are using a upstream kernel, and thus, u-boot) and define your boot cmdline to:

    setenv bootargs earlyprintk block2mtd.block2mtd=/dev/mmcblk0p3,65536 root=/dev/mtdblock0 rootfstype=jffs2
  6. Rebuild your boot.scr (check the Building your Bootloader).

  7. And finally, reboot your Pi.

Side notes:

Q: For how long are you running such a setup? A: 7 months; working like a charm.

Q: What about the speed? A: If you need speed, JFFS2 is not your solution. Attach a HDD, use the SD card as a bootloader and boot from the HDD instead.

Q: My image takes forever to mount! A: Have you added the EBS option? Also, for a ballpark; a 2 GB partition takes approx. 110 seconds to mount on my pi.

Good luck!


From Wikipedia:

In practice, flash file systems are only used for memory technology devices (MTDs), which are embedded flash memories that do not have a controller. 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.

Source: http://en.wikipedia.org/wiki/Flash_memory#Flash_file_systems

USB sticks, MMCs, SDs, CompactFlashes and other popular removable devices should not be confused with MTDs. Although they contain flash memory, this is hidden behind a block device interface using a Flash Translation Layer.

Source: http://en.wikipedia.org/wiki/Memory_technology_device

So no, there's no use case for JFFS2 or UBIFS on the SD card you put in the Pi.

There are other solutions for reducing the wearing of the SD card, like mounting it with option relatime or noatime.

  • Would your answer apply if using the RPi Compute Module with 4GB on-board eMMC or no? Oct 20 '16 at 20:57
  • 2
    You'd have to look up the technical specs of the on-board eMMC: is it an MTD device? Then you have your answer. Oct 21 '16 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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