Search the Community

Since I've been asked recently why Armbian doesn't ship with F2FS by default I thought let's have a look again what to gain from F2FS (a filesystem specially designed for use with flash media by Samsung few years ago). For a history of F2FS discussion please use the search function: https://forum.armbian.com/index.php?/search/&q=f2fs Armbian fully supports F2FS partitions for a long time now but we don't provide OS images with F2FS for a couple of reasons: F2FS still doesn't support resizing so our default installation variant (ship with a minimized rootfs that gets resized on first boot automagically to the size of SD card / eMMC) wouldn't work F2FS requires a pretty recent kernel and is therefore not an option for default images (since most of downloads use legacy kernel) Unfortunately those installations that would benefit the most from faster random IO (writes) are those using the kernels most outdated (Allwinner A20/H3 who are used by many people as 'desktop linux' where performance heavily depends on fast random writes) To use F2FS with Armbian you need to choose a SoC family that is supported by mainline kernel (or at least 4.4 LTS) and then build an image yourself using these options (choosing $FIXED_IMAGE_SIZE to be less than the capacity of the final installation media!) ROOTFS_TYPE=f2fs FIXED_IMAGE_SIZE=n In the past I tested through this many times and all my tests didn't show that great performance improvements would justify another installation variant but... let's have a look again and focus on the claims first. F2FS has been invented to solve certain problems with flash based media and promises better performance and higher longevity. At least measuring the latter is somewhat questionable but performance can be tested. So I decided to pick 3 different SD cards that represent roughly the kind of flash media people out there use: Crap: An Intenso 4GB Class 4 SD card Average: A random SanDisk 8GB card Superiour: An expensive SanDisk Extreme Plus with 16GB For the tests I used an OrangePi One with kernel 4.10 and a Debian Jessie variant to be able to use a scripted OpenMediaVault installation as some sort of a real-world benchmark (the script is roughly based on the results of our OMV PoC). The other 3 benchmarks are our usual iozone3 call, then ioping and a mixed workload measured with fio. Test script is this: https://pastebin.com/pdex14L9 First results with an average SanDisk 8 GB card (debug output with F2FS and with EXT4): F2FS EXT4 iozone 4K random write IOPS 208 196 iozone 4K random read IOPS 1806 1842 iozone 1MB sequential write KB/s 7161 10318 iozone 1MB sequential read KB/s 22429 22476 ioping k iops 1.42 1.31 fio write iops 128 132 fio read iops 384 395 OMV installation time in sec 886 943 I consider benchmark numbers that vary by less than 10% as identical and then it's easy: ext4 outperforms F2FS since all results are identical but sequential reads are +40% faster with ext4. Test results in detail: F2FS and EXT4. I'm really not impressed by any differences -- only two things are interesting: faster sequential reads with ext4 but very low random IO write performance at 16K blocksize (that's something we noticed with a lot of SD cards already, see first post in 'SD card performance' thread). At the moment I'm not that impressed by performance gains (but that might change later when the crappy 4GB card has finished) and just want to point out that there are other criteria too for choosing a filesystem for systems that are running with a high potential for bit flips (due to users using crappy chargers, bad DRAM clock settings when not using Armbian and so on). Just to give an idea please read through the PDF link here: https://news.ycombinator.com/item?id=11469535 (ext4 more than 1,000 times more reliable than F2FS when running the AFL test against) BTW: mkfs.f2fs info at image creation time (no idea whether something could be 'tuned' here): Info: Debug level = 0 Info: Label = Info: Segments per section = 1 Info: Sections per zone = 1 Info: Trim is enabled Info: sector size = 512 Info: total sectors = 7649280 (3735 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 4.4.0-72-generic (buildd@lcy01-17) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017" Info: Discarding device Info: Discarded 7649280 sectors Info: Overprovision ratio = 3.300% Info: Overprovision segments = 126 (GC reserved = 68) Info: format successful

Hello, i've preordered an Helios64 and would like to install the main os on a f2fs formatted sd-card. your documentation says that this is not possible, and i would love to see this possibility. i guess most eMMC devices would also benefit

Sorry for a newbie question. I am setting up a raid system based on flash drives on a Orange Pi One and every thing is working fine. I am now thinking of moving from ext4 for F2FS but I can't figure out how to get it to work. I have installed f2fs-tools and managed to format the drive but I can't seem to mount it. I can't seem to run "modprobe f2fs". Does this mean that I need to recombile the kernel or what? I am not intending to boot from f2fs. Just mount the raid system for storage.

What to do to switch from ext4 to F2FS (one big caveat: Partition/filesystem resizing doesn't work with F2FS so this is only for you if you know the size of your SD card prior to building the image)? I tried the following so far: apt-get install f2fs-tools define size of f2fs partition in compile.sh (eg. for a 4 GB SD card use »SDSIZE="3600"«) adjust »BOOTSIZE=16« in lib/configuration.sh (line 26) replace »mkfs.vfat -n "$IMAGEVOLUME"« with »mkfs.ext4 -q« in lib/deboostrap.sh (line 66) replace »mkfs.ext4 -q« with »mkfs.f2fs« in lib/deboostrap.sh (line 67) add »-tf2fs« to mount option in lib/deboostrap.sh (line 68) comment »shrinking_raw_image "$DEST/output/$VERSION.raw"« out in lib/common.sh (line 463) change fstab entry to »echo "/dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime,errors=remount-ro 0 0" >> $DEST/output/sdcard/etc/fstab« in lib/distributions.sh (line 105) comment »install -m 755 $SRC/lib/scripts/resize2fs $DEST/output/rootfs/$CHOOSEN_ROOTFS/etc/init.d« out in lib/distributions.sh (line 138) avoid partition resizing on first run by removing lines 89-101 in lib/scripts/firstrun But the Banana Pro I test with doesn't boot. I would assume that I have to modify boot.cmd (and exchange /boot/ with /)? Thx

Hi, just a question to be discussed: Would it... 1. ...be possible to use F2FS as default filesystem for images using the vanilla kernel? 2. ...make sense to use it? benchmarks show that write operations could get a huge boost in comparison to ext4. i believe write operations are quite slow right now (using cubietruck with sd-card) What do you think?