F2FS With Linux 5.16 Will Let You Intentionally Fragment The Disk

[phoronix]

Phoronix: F2FS With Linux 5.16 Will Let You Intentionally Fragment The Disk

Jaegeuk Kim submitted the Flash-Friendly File-System (F2FS) updates on Wednesday for the nearly over Linux 5.16 merge window...

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

[Alex/AT]

"create a new segment in a random position"
"scatter block allocation"

"real-world fragmentation"
ORLY?

[jntesteves]

Added two options into "mode=" mount option to make it possible for developers to simulate filesystem fragmentation/after-GC situation itself. The developers use these modes to understand filesystem fragmentation/after-GC condition well, and eventually get some insights to handle them better.

Maybe I missed something, but on the commit I don't see defines to hide this "feature" behind a compile-time flag. I don't think it's a good idea to ship potentially quality degrading options to final users.

Just my 2 cents, I haven't done any Kernel development, so I can't claim to know how it works.

[Developer12]

Why does it matter if a flash-only filesystem is fragmented? Isn't the defining feature of solid state storage that you can put a block just "anywhere" and it will be equally fast to read? In that scenario it seems like you shouldn't need to care about contiguous free space at all. Just scatter the blocks to whatever regions happen to be free.

[polarathene]

Isn't the defining feature of solid state storage that you can put a block just "anywhere" and it will be equally fast to read?

IIRC, IOPS degrades with fragmentation even on SSD. The hardware side is fine, but the filesystem layer on top usually abstracts that where the higher the fragmentation at the filesystem layer the more I/O requests made to the disk controller to handle.

Compared to an HDD the latency is much lower however, so you as a user aren't likely to notice much if you're not doing anything throughput critical that expects to maintain that level of throughput over time. An old Crucial MX500 SSD can do about 560MB/sec sequential over SATA3 or 95k IOPS, while a PCIe 4.0 NVMe disk these days such as Samsung 980 Pro can handle around 1M IOPS or so and 7GB/sec read.

In either case, you probably aren't doing much work where you'd notice a difference of half that, but I have seen reports of heavily fragmented files reaching around 50% perf loss (a 6MB file with 1k fragments, 30ms read time became 60ms). Beyond that, I think it can also affect the maximum capacity of the disk. If you set a large block size, and have many small files (or somehow many blocks with only a small amount used for that file), it wastes away space (some filesystems like BTRFS can pack those blocks with other file data though). Which likewise means more data to fetch than necessary.

You'd also have the cache layer on hardware that probably takes a hit from such too.

[brucethemoose]

Maybe I missed something, but on the commit I don't see defines to hide this "feature" behind a compile-time flag. I don't think it's a good idea to ship potentially quality degrading options to final users.

Just my 2 cents, I haven't done any Kernel development, so I can't claim to know how it works.

F2FS already had plenty of potentially harmful knobs to turn, just like many other filesystems. This one is just a mount option that can always be changed back.

However, the defaults encourage tweaking, as some of the most useful features are (somewhat annoyingly) not enabled by default.

[gfunk]

would this be considered healthy in a way, to stop machines writing to the same set of blocks?

[4BvFCHGlspF4]

[sarcasm]How far we've come... from combatting fragmentation for literally decades to now inviting it.[/sarcasm]

[phuclv]

Why does it matter if a flash-only filesystem is fragmented? Isn't the defining feature of solid state storage that you can put a block just "anywhere" and it will be equally fast to read? In that scenario it seems like you shouldn't need to care about contiguous free space at all. Just scatter the blocks to whatever regions happen to be free.

but it still takes multiple reads to read those scattered blocks. A single command to read 50 blocks at address 3 is definitely much better than 30 different read commands if they're separated into 30 different fragments. Besides the more fragments, the more metadata are needed for storing information about those fragments, and more time is needed to parse the address of an offset in a file to seek into it