F2FS vs. EXT4 File-System Performance With Intel's Clear Linux

[coder]

Unless it's an old OCZ, then it will always been 0%.

Not true. I've personally seen drives of other makes with nonzero wear numbers.

Usually modification of a file will suffer from write amplification, especially using btrfs.

Yes, because most filesystems don't support mid-file insertions.

As for btrfs, I think you only get a CoW penalty if there's some other reference to it (e.g. from a snapshot) and CoW is enabled. For things like databases and VM images, you can selectively disable CoW.

Untarring should be a straight stream and should never result in amplification.

No, I don't think filesystems allow a single block to include data from multiple files. So, if you write small files (i.e. relative to the block size), you should tend to get write amplification.

The issue is very big because at the end that determines if your Tesla borks after a few years of writing logs (and slowly writing logs can suffer from amplification). Maybe, just maybe if they used f2fs instead of ext4?

AFAIK, the only way a filesystem could solve that problem would be to pack writes of different files together (probably with some additional buffering, too). Otherwise, if you write a couple lines and call fsync(), then any filesystem should do a read-mod-write on the last couple blocks of that file and you get the same amplification no matter what.

In something like a car, you can't afford to just buffer stuff for a while, to reduce the write frequency, because a crash could mean incredibly valuable data pertaining to it never gets written. So, the problem should be solved at a hardware level, by writing to a high-endurance pseudo-SLC buffer. Later, when the car is not in operation, you can migrate that data to a TLC region, or just upload it to the cloud.

've never ever seen a fragmented filesystem on linux.

It can happen, if you sustain a high degree of turnover, when the filesystem is very nearly full. The solution to that case is to ensure it never gets (or stays) so full. I think we found that about 5% free space was enough.

[Ardje]

Not true. I've personally seen drives of other makes with nonzero wear numbers.

That's what I said... On old OCZ that number is always perfect. Even after years of 10MB/s write.

No, I don't think filesystems allow a single block to include data from multiple files. So, if you write small files (i.e. relative to the block size), you should tend to get write amplification.

There is reiser3.6, reiser4 and I think btrfs ;-). But that's not the issue. There is a big difference between how filesystems manage their data, some just log the changes, and some copy or split the extent. And afaik, I would use btrfs on rust over f2fs, and f2fs or ext4 over any other filesystem on emmc.

About the fragmentation: this is not a disk full issue, it's because ocfs2 reserves space per node for allocation on write, in this case the allocation was way too small. If that's too small you need to wait for free blocks, which in my case could take up to 1.5 minutes for a 64MB file. Also due to fragmentation, increasing the allocation to cover the 95 percentile size of an e-mail was not possible anymore. I mean, fragmentation should go away on an most filesystem if you just copy the tree and move it back (so files become single large contiguous extents).

But never mind all that: I want to see the difference in total blocks written for each filesystem so we can think about that. And if possible the amount of I/O.