F2FS Enhancements Land In Linux 5.19

[phoronix]

Phoronix: F2FS Enhancements Land In Linux 5.19

New feature code for the Flash-Friendly File-System (F2FS) has landed for the in-development Linux 5.19 kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-F2FS

[skeevy420]

Not to detract from the F2FS news, but, relating to newer kernels and file systems, a bunch of 5.18 and 5.19 compat commits landed for OpenZFS yesterday and the META file was bumped up to show 5.18 support. Hopefully that means an OpenZFS release for up to 5.18 is coming soon. If you're not a file system nerd, ignore this comment because it isn't meant for you.

Y'all have a good day.

[NobodyXu]

allow compression for mmap files in compress_mode=user

I am confused at this feature,
What does it mean that compression for mmap files?

Does it mean that when mmaping a file that is transparently compressed by F2FS, I can access the compressed content when mmaped?

[CochainComplex]

I'm still wondering why a lot of distros do not support f2fs in their installation routine. Yes its possible to change the root fs afterwards but its not quickly done.

[staalmannen]

Does anyone know if it ever will be possible to add features to an existing F2FS partition? I missed to add a few options (extra_attr,inode_checksum,sb_checksum,compression ) when I created my partitions when I installed my system. Now I just wonder if it would make sense to move all data (including root) to a back up, recreate the partitions and move it back. It would be far easier/nicer if it would be possible to just "upgrade" an existing partition though.

[scottishduck]

F2FS is certainly a first tier FS now, I’d say on par with ext4 and btrfs at a minimum.

[skeevy420]

I'm still wondering why a lot of distros do not support f2fs in their installation routine. Yes its possible to change the root fs afterwards but its not quickly done.

I assume because it primarily benefits embedded NAND and SD cards more than it does SSD or NVME. Even the compression is "flash friendly" in that it doesn't actually save space for the user; only tries for less writes/blocks used on the storage. Most people doing NAND or embedded setups probably have their own custom installer and plug-and-play flash card users don't need installer support.

NobodyXu

In this round, we've refactored the existing atomic write support implemented by in-memory operations to have storing data in disk temporarily, which can give us a benefit to accept more atomic writes. At the same time, we removed the existing volatile write support. We've also revisited the file pinning and GC flows and found some corner cases which contributeed abnormal system behaviours. As usual, there're several minor code refactoring for readability, sanity check, and clean ups.

It just saves writes while you're getting stuff done. I had to go visit my Mom in the hospital or I'd have posted that earlier.

[brucethemoose]

I'm still wondering why a lot of distros do not support f2fs in their installation routine. Yes its possible to change the root fs afterwards but its not quickly done.

Probably because its somewhat poorly documented and seems to have a development focus on server + android usage.


It also has some restrictions and quirks that could trip unaware desktop users up, like being unable to shrink partitions or change certain attributes after creation, some questionable default parameters, and some very unhelpful error messages when you do set non default parameters. For instance, I had to dig into the kernel source code to figure out the compression filetype blacklist/whitelist has a relatively low limit.


It also has a poor historical reputation, going by its entry in the Arch wiki.


There also seems to be less demand for it. Users who want a low overhead, trouble free filesystem seem to be content with ext4, while users who want lots of features don't seem to mind the performance hit and complexity of stuff like zfs or btrfs.

[CochainComplex]

Thanks for the replies. IIRC most benchmarks done by Michael have proven that f2fs is quite uplifting the performance on NVMe too. One might argue why is it necessary to have the last few percentage gains over e.g. ext4. AFAIK startup time for some application went down from second to a few ms. That's sounds not much but contributes heavily to the snappiness experience.
Argueable BTRFS and its future set is great I love it for my NAS. But my work rig has separated root and home portions. So if anything on root breaks it is quite easily reinstalled in such a case I prefer performance over safety. At the moment I'm using xfs which is almost on paar with f2fs performance wise. But application start time is still way better on f2fs.


Besides xfs is also not shrinkable.

[kcrudup]

I've got an old (ca. 2011) 64GB USB 1.1 flash drive I got back before I'd realized so many large USB flash drives were utter shit back then. I once tried to format it EXT4 and it took an hour, and writing files on it- by this point mostly for the academic/amusement value- were in the KB/sec range.

I found it in a bin recently and just for shits and giggles reformatted it F2FS. While it's still not going to set any speed records, it's actually usable now. I used to have a first-gen Android tablet (Moto Xoom) that was laggy AF once you'd started using it for any length of time, 90% of that was due to poor random 4K write performance on the Toshiba EMMC used (when it would lag for seconds at a time the kernel would spin in "mmcqd" and IOWAITs were in the 10+ range), and i wish I could have seen how it would have done with F2FS.