F2FS Low-Memory Mode, Atomic Write Improvements For Linux 6.0

[asim75]

So it should be used in Usb memory stick.

I have been using my system(not live, persistent installation like hard drive) on plain USB stick (not SSD) for a long time; tried XFS, F2FS, BTRFS, EXT4(with and without journal). Never made a synthetic test but i am having way better daily usage performance(boot time, system responsiveness) with XFS comparing to the others.
You wont experience any difference on daily usage until you use a slow USB drive like i do.

[archerallstars]

I use F2FS on my Corsair MP600 to make a lot of Chia (XCH) plots. I can say that, in terms of performance, nothing beat F2FS, ever!

[skeevy420]

PopOS and CL do use ext4 as their default fs for root. Installation also works with xfs but breaks when using f2fs. I have btrfs on my nas - I'm also creating scheduled snapshots for potential need of rolling back. Nice feature but I'm not very experienced. So using it always means I need to read all the how tos again ...until next time when my brain has lost again all Info's

AFAIK only fedora is extensively using btrfs with its subvolume features even in there PKG manager?

OpenSUSE takes full advantage of subvolumes. In my experiences and opinion they have the best default BTRFS setup in regards to utilizing subvolumes. This page has a great write up on how they do it.

[Weasel]

That's why it was made. From their own documentation:

That's not what I asked for. It's cool it was made for portable flash media, but that doesn't imply it's not good (or as good as other "general purpose" filesystems) for SSDs. In fact, I can't see it be any worse than "simple" filesystems like ext4, so...

That said, a general purpose file system using the noop or none IO scheduler works just as well on SDDs. Anecdotally, most consumer-grade 2.5 SSD drives are designed with Windows or macOS with NTFS, exFat, HFS, and APFS in mind...general purpose file systems.

"works just as well" does not equal "better off with" which is what you stated originally.

So let me re-ask the question: Why is ext4 better off for a SSD than f2fs? (or the other simple general purpose filesystems you listed)

Only for better throughput; you can't utilize the space it saves. Most every other file system can utilize the free space while achieving better throughput via compression.

I see, thanks for the tip. But unfortunately the filesystems that do support compression are the extreme overhead copy-on-write ones like btrfs, which needless to say are slow and have insane fragmentation.

[skeevy420]

That's not what I asked for. It's cool it was made for portable flash media, but that doesn't imply it's not good (or as good as other "general purpose" filesystems) for SSDs. In fact, I can't see it be any worse than "simple" filesystems like ext4, so...

"works just as well" does not equal "better off with" which is what you stated originally.

So let me re-ask the question: Why is ext4 better off for a SSD than f2fs? (or the other simple general purpose filesystems you listed)

I see, thanks for the tip. But unfortunately the filesystems that do support compression are the extreme overhead copy-on-write ones like btrfs, which needless to say are slow and have insane fragmentation.

With SSDs on desktop distributions, ext4 is better simply for the fact that it's more universal and supported. That said, Ext4 wouldn't be what I'd pick. The reason being is that F2FS is faster than Ext4 on Flash media and, IIRC, the only extra feature it brings is case sensitivity. The higher overhead file systems bring in a heck of a lot more features, stuff that you'll have to use both LUKS and LVM to be close to equivalent.

Basically, unless you need pure, raw throughput, you're better off with some other file system on your desktop. The average person playing games or watching YouTube on a desktop will never notice the difference between Ext4 or F2FS or BTRFS so it's better to go with BTRFS where you have more redundancy and abilities.

I'm assuming that we're discussing root volumes on a desktop here. If not then the F2FS 16TB limit needs to be brought up. A lot of us ZFS users have pools that are nearing that size or are larger thanks to how big and cheap consumer drives cost. My current setup is 3X4TB in an 8TB usable Zpool (12TB w/o redundancy). Whenever my disks start to go bad (or I come across a very good sale) I will more than likely surpass that 16TB limit. My point is that F2FS isn't a good format for long-term storage.

Mid-post my cat brought me a loud, chirping, baby present.

[guglovich]

You understand it well enough. Users don't reap the benefits of the extra freed up space. The compression with F2FS is used to send less data over the bus and for smaller read/write operations. For end users wanting more space, there are better choices like BTRFS, ZFS, and BcacheFS or slightly better choices like Reiser4/5, JFS, and NTFS.

It's not that much more difficult to use than any other file system. It has the extra step of needing a flag passed to mkfs, but after that it's the same as any other Linux FS -- set the appropriate mount flags or with chattr. Ext4 needs the same extra steps for case sensitivity.

While it's a nice file system, F2FS really isn't something the average desktop or server user should be using. It's a file system for embedded and portable flash drives that don't need to be universal (exFat). IMHO, unless you're setting up an embedded device, phone, Pi, SBC, etc on an EMMC, SD, USB it really isn't a file system you probably need to be using.

I have options in fstab, but no effect. There is even a command to free block memory after compression, but the system does not accept it.