EXT4 vs F2FS

Here's a simple TuplDB performance comparison between EXT4 and F2FS. The test inserted random keys into a new database, as quickly as possible, with no transactions. The file wasn't striped, and the file system was freshly formatted before each test.

• Threads: 16
• Key: 8 bytes
• Value: 0 bytes
• RAM: 16GB
• Storage: Samsung 960 Pro 512GB
• CPU: Ryzen 7 1700
• Kernel: 4.10.0-33

The first kink in the graph at about 1 billion records is when RAM was exhausted. For several hours F2FS outpaced EXT4, but something odd happens at 2.75 billion records. F2FS performance drops quite a bit and never recovers. Perhaps the file system needed to do aggressive cleanup that wasn't necessary when it was freshly created? It should also be noted that by the end of the F2FS test, the drive was less than 10% full.

The next picture compares EXT4 performance to three tests runs against a raw block device. It looks like EXT4 outperforms a raw block device, but the first block device test started out much faster. The second and third block device test runs perform nearly the same, and both are slower than the first block device test run. The likely cause of the slowdown is SSD trim command, which wasn't run before any of the block device test runs. So the SSD got slower over time as it had to perform more cleanup tasks, but it stabilized.

Note that the third block device test run stops sooner, which was intentional. It makes it easier to see the performance overlap with the second test run.