RaspberryPi, SD cards wear, and f2fs filesytem experience

If there’s any interest, I’m sharing my experience with moving to an f2fs filesystem for my Piaware setup.

Goal: Install and test f2fs filesystem on SD card used with Raspberry PI. Based on write-ups in several places, but the one article that was the most useful to me for a Pi running Raspbian 9 (i.e. Debian Stretch version 9) is linked here: f2fs article A How-To f2fs was written up in the RaspberryPi forums back in 2013, link here. I look forward to the day when the Raspbian Team feels confident enough to distribute the Raspbian image on f2fs instead of ext4 - it “seems” stable.

There are many ways to create and copy successfully the root filesystem, I used the linked articles as a basis for doing it the way I wrote up here. If you have only one SD card and no way to attach a second to your Pi or a separate computer running Raspbian, then this exercise is probably not going to work for you. One way to improvise and adapt to that is to shrink the existing partition, create another partition, format that partition to a f2fs filesystem, copy the ext4 filesystem to the new one, and modify the boot to use the newly-created filesystem - all well beyond the scope of this writeup and only recommended for those of you that play in *nix every day.


The primary reason is the a concern for wear on the SD card in the Raspberry Pi. Writing logs is more than I had expected, I have better things to do than play “whack-a-mole” suppressing things I don’t want to see in the logs, and I do want to keep logs around that survive a reboot (planned or unplanned). I don’t want a hard-drive (SSD or spinning platters), I don’t want or expect my Pi to be a shop-floor level ruggedized process control system, but want to have reasonable levels of protection to supplement regular backups and to prolong the life of the Pi as long as possible.

Internet discussions on the robustness of SD cards range from “running my Pi from the attic located in Death Valley for years with no problems” to “OMG my Pi SD card died after a few days of running my smarthouse functions stuck in a refrigerator”. One of the biggest ‘wearpoints’ on a Pi is logging and temporary filesystems. There is enough written about how to put temporary and logging filesystems into memory instead of the SD card, or how to use utilities to buffer writes to these filesystems to happen in bigger chunks. Since f2fs has been around many years, and is baked into the Linux kernel since major release 3.something (Raspbian kernel is 4.9.something as of this document), and is used frequently in smartphones, I liked the idea of set f2fs up once and move on with other fun stuff.

It’s been running a few weeks so far, no issues that I can see. Your mileage (and my future experience) may vary.


This is what I used

  • Pi2
  • Raspbian “stretch” for Pi installation Linux pi2 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
  • Spare SD card onto which the existing card has already been cloned using rpi-clone utility, made available on the Pi using a USB SD card adapter


Pre-pend commands below with ‘sudo’ if not running as root. I tend to run as root when doing several tasks in a row, not necessarily a recommended best practice, be forewarned.

Install the f2fs toolsets

apt install f2fs-tools

Add the module to /etc/initramfs-tools/modules:

echo f2fs >> /etc/initramfs-tools/modules
update-initramfs -u


Re-format the spare SD card’s Linux partition (this wipes out existing format on partition 2):

root@pi2:~# mkfs.f2fs /dev/sdb2

        F2FS-tools: mkfs.f2fs Ver: 1.7.0 (2016-07-28)

Info: Debug level = 0
Info: Label =
Info: Trim is enabled
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 61769728 (30161 MB)
Info: zone aligned segment0 blkaddr: 512
Info: format version with
  "Linux version 4.9.59+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1047 Sun Oct 29 11:47:10 GMT 2017"
Info: Discarding device
Info: This device doesn't support BLKSECDISCARD
Info: This device doesn't support BLKDISCARD
Info: Overprovision ratio = 1.160%
Info: Overprovision segments = 351 (GC reserved = 180)
Info: format successful

This takes a few seconds, informational messages are printed as shown.

Make a copy

Feel free to use whatever tool you are comfortable with for making complete copies. I use and swear by rsync

Make sure the source is as quiet as possible -

systemctl stop piware dump1090 pfclient fr24feed

Mount the freshly-formatted f2fs partition (I also display the currently mounted filesystems)-

mount /dev/sdb2 /mnt/clone

df -hPT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       15G  1.2G   13G   8% /
devtmpfs       devtmpfs  213M     0  213M   0% /dev
tmpfs          tmpfs     218M     0  218M   0% /dev/shm
tmpfs          tmpfs     218M  5.8M  212M   3% /run
tmpfs          tmpfs     5.0M  4.0K  5.0M   1% /run/lock
tmpfs          tmpfs     218M     0  218M   0% /sys/fs/cgroup
/dev/mmcblk0p1 vfat       42M   21M   21M  51% /boot
tmpfs          tmpfs      44M     0   44M   0% /run/user/0
/dev/sdb2      f2fs       30G  206M   29G   1% /mnt/clone

and sync the local root partition to the new filesystem -

root@pi2:~# rsync -aWxh --stats / /mnt/clone/

Number of files: 44,019 (reg: 34,183, dir: 3,830, link: 6,005, special: 1)
Number of created files: 44,018 (reg: 34,183, dir: 3,829, link: 6,005, special: 1)
Number of deleted files: 0
Number of regular files transferred: 34,183
Total file size: 1.10G bytes
Total transferred file size: 1.10G bytes
Literal data: 1.10G bytes
Matched data: 0 bytes
File list size: 1.31M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 1.10G
Total bytes received: 693.79K

sent 1.10G bytes  received 693.79K bytes  4.48M bytes/sec
total size is 1.10G  speedup is 1.00

The meaning of the rsync options:

  • a: use the archive mode (several options rolled into one)
  • x: sync only the filesystem specified, do not cross boundaries
  • W: copy whole files only
  • h: print statistics in human-readable form
  • –stats: print statistics for the operation

Looks like the overhead for f2fs might be a little higher than for ext4 (the SD card I am using for the clone is 32GB, source is only 16GB).

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       15G  1.2G   13G   8% /
/dev/sdb2      f2fs       30G  1.4G   28G   5% /mnt/clone

Make it bootable

Edit the cloned device’s /etc/fstab and change the mountpoints. First, identify the mountpoints:

root@pi2:/mnt/clone# blkid
/dev/mmcblk0p1: LABEL="boot" UUID="B60A-B262" TYPE="vfat" PARTUUID="cbe5fa9a-01"
/dev/mmcblk0p2: UUID="9a7608bd-5bff-4dfc-ac1d-63a956744162" TYPE="ext4" PARTUUID="cbe5fa9a-02"
/dev/mmcblk0: PTUUID="cbe5fa9a" PTTYPE="dos"
/dev/sdb1: LABEL="boot" UUID="B60A-B262" TYPE="vfat" PARTUUID="8c3d168f-01"
/dev/sdb2: UUID="6b5744b5-0bd5-47bc-ba38-318c2f4a3ba9" TYPE="f2fs" PARTUUID="8c3d168f-02"

Need to change the cloned device to use the PARTUUID information from lines 5 and 6 above, and the Linux root partition to use f2fs format:


root@pi2:/mnt/clone/etc# cat fstab
proc            /proc           proc    defaults          0       0
PARTUUID=cbe5fa9a-01  /boot           vfat    defaults          0       2
PARTUUID=cbe5fa9a-02  /               ext4    defaults,noatime  0       1


proc            /proc           proc    defaults          0       0
PARTUUID=8c3d168f-01  /boot           vfat    defaults          0       2
PARTUUID=8c3d168f-02  /               f2fs    defaults,noatime  0       1

Mount and update the cloned /boot partition:

mount /dev/sdb1 /mnt/clone/boot
vi /mnt/clone/boot/cmdline.txt


dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=8c3d168f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=8c3d168f-02 rootfstype=f2fs elevator=deadline fsck.repair=yes rootwait

Shutdown and Use New Card

Shutdown the Pi, replace the existing SD card with the one you just created, and boot. Might be a good idea to have a monitor hooked up to see if anything goes wrong.


Excellent “How To” writeup.
Thanks for posting and sharing your experiance.

10 months along into the conversion to F2FS and the PiAware boxes have shown no issues here.

Someone (RonR) has automated the above (messy) process - this HOWTO and script was posted in the HOWTO Raspberry Pi forums back in March 2018 by putting together a wrapper script to do all the stuff above ‘automagically’.

Caution: this work is suitable if you are comfortable with Linux and mucking about the operating system and have a reliable way of getting back to where you started. There are no guarantees of outcomes or remedies here in case something goes wrong. There’s probably a good reason FlightAware boxes stay on ext4 filesystems in their kits that are sent all over the world in all kinds of conditions. I do this sort of thing ‘just because’ I like to tinker :grin:

The steps reduce to this simplicity (copied from the post, you will have to go there to get cvt2f2fs):


1. Disconnect all USB devices from the Raspberry Pi.
2. Connect a USB flash drive with sufficient capacity to hold the SD card contents
-  connect a keyboard and a monitor to watch progress


3. Log in as root (best to use a keyboard and run from console)
4. Run ./cvt2f2fs
5. Log in as root following the reboots which occur at the completion of Phases 1, 2, and 3
6. When Phase 4 completes, the SD card should be using an F2FS filesystem instead of ext4