Any special reason why F2FS filesystem is not supported?

[kosi2801]

I have recently switched my root filesystem to F2FS to reduce SD card strain (I had several losses recently because SD cards failed likely because of consistently writing ext4 journal to the same location over and over again, although the card had plenty of space left).

Just today I realized that since that switch I have no recent backups of my Raspis anymore. Upon manual inspection I found the error "??? RBK0109E: Nicht unterstütztes Filesystem f2fs auf Partition mmcblk0p3." ("RBK0109E: Unsupported filesystem %s detected on partition %s." in EN; and yes, my / is on 3rd partition, please don't ask 😑).

As the error messages page (https://linux-tips-and-tricks.de/en/raspibackupmessagese/) didn't list this specific error, I had to dive into the source where I found that at https://github.com/framps/raspiBackup/blob/master/raspiBackup.sh#L6559 the F2FS filesystem is not contained as a supported one.

Is there a specific reason for this or am I just the first person to hit this?

From my perspective, F2FS should be comparable to BTRFS at least as long as the backup option is file-based (tar, rsync), not block based (dd). And a block-based backup would also carry risk for data-loss or -corruption with the other filesystems (although the other ones may be more resilient during recovery, but I can't find any recent reports or papers on F2FS for that, only several-year old ones).

[framps]

Not sure you know the history of raspiBackup.

raspiBackup initially held features I need only for my Raspberries. I don't use f2fs. All additional features were asked for by raspiBackup users 😉

am I just the first person to hit this?

Yes. 😄 That's why you didn't find any error message description.

As far as I can see it's not a big issue to add f2fs support in raspiBackup. If you commit to test f2fs support carefully I'll create a branch for you and finally will add f2fs in next release.

[framps]

I just created a branch which includes f2fs support. But please note: It's untested code. You have to verify whether the fix is OK.

Please use

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- f2fs

to download the code.

[kosi2801]

Wow, what a quick turnaround 😮 Thanks for pointing to the exact location of the background. Looks your reason to create raspiBackup was caused by similar problems that I experienced with the failing SD cards.

Thank you very much for the instructions.
I'm currently testing the backup. Two things I can already report:

• you almost got me with executing that "raspiBackupDownloadFromGit.sh" script 😉 On the first run it just installed missing packages, I had to execute it a second time to actually download the dev-version of raspiBackup.sh.
• in your commit in the f2fs branch you named the new commands-check array "REQUIRED_COMMANDS_E2FS". Is that a typo or intentional?

[framps]

Is that a typo or intentional?

Good catch. That's a typo. But this shouldn't have any effect on the result. It's just to check whether the f2fs tools are installed which fails but which should be installed already on your system 😉

[framps]

I'm just interested to know why you use f2fs. According tests in the net f2fs has serious issues when there is a power failure 😢 Even RaspbianOS uses ext4 instead of f2fs.

[kosi2801]

Switching away from ext4 was mainly because I wanted to switch to a filesystem that uses the SD card memory cells evenly, unlike ext4+journal that always overwrites the same cell and wears them out while the remaining card memory is almost virgin. I have lost several Raspi installations to broken SD-cards that show block errors only in specific regions (I guess where the ext4 journal resided) and since I recently upgraded one of my Raspis to hold more critical data (Docker with HASS, paperless-ngx, ...) I wanted to reduce the likelihood of SD card issues as much as possible. One of my starting points for this was https://www.reddit.com/r/linuxhardware/comments/umk511/comment/i8eysg2/

My motivations to use f2fs specifically were:

• all reports and tests (also the one reg. issues w. power-outages, https://www.usenix.org/system/files/atc19-jaffer.pdf I guess?) that I could find relating to issues with f2fs were several years old.
  There has been constant development to the FS since then but there seems to be only little recent documentation (if you don't go down the path reading commit-messages in the kernel git repos at https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/) and no comparable tests on reliability. But I assume it's more resilient to those issues in the meantime.
• multiple Android phones run f2fs as their filesystem, so I assume that it's at least "stable" enough as daily driver for devices with a higher probability of outages than a RaspberryPi
• btrfs seems to offer similiar capabilities, but I had attempted to use it several years ago but at that time it was not stable enough to use it without keeping its presence in mind, as it required regular maintenance/cleanups and also offered much more features/complexity than I needed. This may have changed too until today and I haven't worked through much of recent docs/tests, but my bias is still there.
• btrfs requires special care when updating Raspi OSs, as the initram-fs doesn't have it included by default. If I were update the systems after months and forget about it, I could end up with an unbootable system that would require emergency-efforts to get it up again.

But yes, I also don't trust f2fs completely too, that's where raspiBackup comes into play 🙃

I'm not sure why RaspbianOS uses ext4 specifically, despite its drawbacks with flash-based storage. My guess is that it's a combination of I/O speed, the availability of documentation for it and the maturity of the FS tools.

TBH, if btrfs would have been available OOTB with Raspbian (and safe to update without keeping it in mind), I would probably have chosen that one.