This really makes me hopeful for when they get things further along. From the responses it looks like it even does better right now than the existing FS for building lots of small files, even before they've got the optimizations to store them in their idata structure. BtrFS reaches similar performance by storing the files in the btree that they use it sounds like. This is the same kind of optimization done years ago by ReiserFS storing small files (<4k I think it was?) in the B+ tree they used for storing the file index. Great things ahead it looks like for the Tux3 FS. I wonder how long before they get a better allocator to avoid the fragmentation problems they have.
EDIT: I wonder how much the asyncronous design is affected by devices that support NCQ and/or NVMe? Anybody have anything to test that?
But i find the answer too negative with regards to tux3 and how all is better when you just use SSD. Most data is still put on HDD and will be for a while. Testing and showing a superior performance with spinning rust is totally valid, imo.
I find it interesting that some "hobby" guys (at least that's my understanding from https://lwn.net/Articles/531126/) are programming and reviewing a file system and getting feedback. Overall i find the answer on the LKML just too unfriendly and rejecting a totally fine test with the nowadays standard answer "but if you just use faster hardware it's different!".
Now it would be interesting to do the Tux3 test with SSD and if that also shows performance improvements or at least the same performance as ext4, that'd be fun :)
If you haven't gotten to the much later comment by the same person (Dave Chinner, one of the developers working on XFS), I recommend reading it: he goes into much more depth on the issues involved with seek latency, expains why XFS is slower, and points out that as fragmentation increases (which he points out in the post you link is still entirely ignored by Tux3) the performance of the filesystem will first decrease to that of XFS and then continue past (so you can't say that Tux3 is optimized for usage on spindles vs XFS: it is simply benchmarking really really well on a "new" filesystem).
Well, he says himself "IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and
the problem goes away. :)".
That's the wrong attitude. It's saying "yes, it's a slow car, but why don't you just buy a ferrari and it's fast again".
I got that Tux3 is not mature and has problems with fragmentation.
You should keep in mind that XFS is primarily intended (it does get used in other places thou) for big systems/large raid arrays, with high IO loads etc.
A kernel build is really a bad workload to benchmark a FS anyway.
EDIT: I wonder how much the asyncronous design is affected by devices that support NCQ and/or NVMe? Anybody have anything to test that?