RPi | Support for + provide F2FS images

[trajano]

Is it possible to set it up so the boot disk is formatted as F2FS rather than ext4?

https://en.wikipedia.org/wiki/F2FS

I am checking this out to see if I can just convert my existing one.
http://whitehorseplanet.org/gate/topics/documentation/public/howto_ext4_to_f2fs_root_partition_raspi.html

[Fourdee]

@trajano

Not tried it personally, but tutorial looks good.
You may run into issues if F2FS doesn't support permissions and symlinks. DietPi (and the majority of software in dietpi-software) needs those to function correctly.

[trajano]

Just asked stackexchange before I go on now ^_^

http://unix.stackexchange.com/questions/323155/does-f2fs-support-permissions-and-symlinks/323156#323156

[trajano]

Using f2fs on my box right now. No noticeable change except for a periodic f2fs GC.

[trajano]

This is probably best done on dietpi.txt perhaps we should have an option to specify what file system we want there.

[trajano]

I would hold off on using F2FS due to https://github.com/Fourdee/DietPi/issues/765 power fluctuations can kill a raspberry pi installation especially for a writable file system. The forcefsck recovery does not fix the file system errors as I would expect.

[Fourdee]

Marking as closed. Please reopen if required.

[trajano]

Yup we have to hold off on this until we get get a proper Fsck to work #765

[Cjkeenan]

What is the current state of F2FS and dietpi? I am upgrading to a Pi 4 with a USB SSD and was hoping to use a more modern file system. It also seems that the issue with fsck was resolved. Is there an official way to go about using F2FS or is the guide in the OP still good?

[MichaIng]

Yes the guide will still work.

In case it's okay to still boot from SD card but only have the rootfs on USB SSD you can also use dietpi-drive_manager to move it to an external drive which supports formatting it as F2FS and Btrfs already.

Btw as I was never really experimenting with it: What is the practical benefit of F2FS and Btrfs over ext4? Probably we can create a testing image with the one or the other to allow more wide-spread testing an identifying possible issues with our or 3rd party tools expecting a different one.

[Cjkeenan]

I was under the impression that it was simply a filesystem designed around flash/nand memory, and as such has optimizations for them such as reducing unnecessary writes, associated with journaling filesystems I think, given that flash has a limited amount of those. I do not know the specifics but I read that for any flash memory in some cases it improves performance, but in most cases it improves longevity of the drive. It also has improved power-loss characteristics I believe through its checkpoint system.

I am debating using dietpi or raspios, but since there is a test image for raspios/I found a image builder that supports f2fs, I think I'll be heading down that route, however if you make an image I will be more than happy to test it for you.

For reference, I use my pi headless for Node-RED, a Network UPS Tools server, PiVPN, PiHole, and maybe Home Assistant soon. It's really a just supplement currently to my smart home powered by Hubitat. Any thoughts on if DietPi has any real advantages for that use case?

I just found this reddit post, interesting comments in the about f2fs. It also links to a paper that has an overview.

[MichaIng]

Some benchmark on Linux 5.0: https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=1
It's on SSD but we would expect similar comparisons on SD cards. Yes I think it makes sense to provide an F2FS testing image. Probably we can add an option to change the rootfs type to our image creation script: https://github.com/MichaIng/DietPi/blob/master/.meta/dietpi-imager
But this can only work with direct cmdline access to change rootfstype of course and support by kernel/firmware (RPi).

[Cjkeenan]

OK, sounds good, is there anything you need from me besides a tester? Also do you have any idea how long it would take to modify the image creation script? My current Rpi install has a corrupted gcc compiler so it is in a static state right now without the ability for me to make any changes, so I was hoping to fix it, but I am willing to wait if you think it is relatively easy to get a test image.

I think the only prerequisite software for f2fs support is f2fs-tools.

[MichaIng]

Probably I can do that today (not rewrite DietPi-Imager but creating an RPi F2FS image manually), but have two other tasks in the pipeline.

[Cjkeenan]

Yeah no biggie and not going to hold you to that, just wanted to get a sense was all. Love the work you and I appreciate you.

[MichaIng]

Image for testing up (I didn't find time to test it myself): EDIT: REMOVED INVALID LINK

There is some more work to do to add full support, as well to our build tools:

• We use resize2fs -M to shrink the images root file system to the minimal possible size. There is resize.f2fs but this currently only supports increasing the size, not shrinking it. So the only way to create an image is either creating an ext4 image first, shrink it and do conversion, or create a new partitioning with a moreless guessed min fs size so that all files fit. "Apparent" size + file count times block size should be failsafe? Testing required...
• Then f2fs-tools needs to be installed for resize.f2fs, fsck.f2fs etc. This cannot be done nicely during DietPi-Imager step but is better done during DietPi-PREP already.
• First boot expansion script requires this support as well: https://github.com/MichaIng/DietPi/blob/dev/rootfs/var/lib/dietpi/services/fs_partition_resize.sh#L53 (I hacked resize.f2fs into the image above)

I'll step by step add rootfs type detection (inkl. Btrfs) and using the correct tools to DietPi-FS_partition_resize, DietPi-PREP and DietPi-Imager first and then we need to think about a good concept where and how to add type selection and create or transform the partitions without leaving plenty of free space.

[Cjkeenan]

Sounds amazing, anything special I have to do or just flash via Raspberry Pi Imager? Also any specific tests do you want run or just give day to day feedback?

Also is there a reason the image says "ARMv6" versus the other images for the RPi being "ARMv7" and the RPi 3B/3B+/4 being "ARMv8" as far as I know and I am genuinely curious, are the architectures backwards compatible or does it not really matter?

[MichaIng]

Just flash it with any method you usually do, dd or Rufus or Etcher or RPi Imager (which I never used so far, but plan to suggest/commit 7z support to it 🙂). For now I simply hope it boots and automated file system expansion on first boot works fine.

If you have some benchmark result with ext4, would be interesting to see possible differences with F2FS. Else, as you anyway wanted to setup a new production system, simply use it as normal and report if you face any issue. Since ext4 is so widely used as rootfs default, some 3rd party software might expect it or behave unexpected, however from Linux-side what I read it should be pretty stable and supported and for our scripts I should be able to quickly provide solutions, if required (if there is more than I listed above already).

I hope I find some time next week to do own tests and as well try it on my NanoPi NEO3 which should moreless be a proof of concept to add support for all (Linux 5.X) Armbian-based images (FriendlyARM + PINE64).

[Joulinar]

@MichaIng
doesn't looks like fs get extended on first boot. Initial setup failed with

[FAILED] DietPi-Software | Free space check: path=/ | available=86 MiB | required=500 MiB
[FAILED] DietPi-Software | Install aborted due to insufficient free space

[MichaIng]

Does running resize.f2fs /dev/mmcblk0p2 manually work?
What does the log say?

cat /var/tmp/dietpi/logs/fs_partition_resize.log

[Joulinar]

root@DietPi:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log
Removed /etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service.
Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x907af7d0

Old situation:

Device         Boot  Start     End Sectors   Size Id Type
/dev/mmcblk0p1        8192  532479  524288   256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 2274095 1741616 850.4M 83 Linux

/dev/mmcblk0p2:
New situation:
Disklabel type: dos
Disk identifier: 0x907af7d0

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 62333951 61801472 29.5G 83 Linux

The partition table has been altered.
Info: Mounted device!
        Error: Not available on mounted device!
root@DietPi:~#

EDIT

root@DietPi:~# resize.f2fs /dev/mmcblk0p2
Info: Mounted device!
        Error: Not available on mounted device!
root@DietPi:~#