I'd be very cautious about the benchmarks. For example, betrfs was measured performing 1000 4-byte writes into a 1GB file. It isn't clear whether there were any

I'd be very cautious about the benchmarks. For example, betrfs was measured performing 1000 4-byte writes into a 1GB file. It isn't clear whether there were any sync operations - there certainly wasn't a sync after each write, although there might have been a sync after the whole set of 1000. That speed up is a simple characteristic of a filesystem that is log-structured (so it is writing those 1000 events as a single sequential disc access) and doesn't store data in 4kB blocks (so it doesn't have to load the other 4092 bytes in the block before writing it). The filesystem I wrote in 1999 for my undergrad project would have done the same thing. One of the benchmarks I wrote for my system showed exactly the same amazing performance benefit. (My benchmark had me generate a tree of a thousand small files in a ridiculously short time - ext2 thrashed all over the disc doing the same thing.) Unfortunately it is unrealistically optimistic because that isn't a write pattern that is going to happen very often. Usually each small write will have an fsync after it. Unless you actually have a thousand writes without a separating sync, then this speedup isn't going to be realised. I'm struggling to see how the find/grep benchmark could possibly have such a fantastic performance benefit for betrfs, given the fact that all those filesystems are effectively reading a tree or known-location structure. The only conclusion I can reach is that maybe the betrfs test had a hot cache and the others didn't. I could possibly be persuaded if betrfs keeps all its metadata in a small easily-cached part of the disc, but there are disadvantages to that too. I don't think this test is valid.