Tux3 Report: How fast can we fsync? | Hacker News Reader

Tux3 Report: How fast can we fsync?

spinics.net

73 pointswebaholic8 comments

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?

The reply comparing with SSD is really interesting: http://www.spinics.net/lists/kernel/msg1978233.html .

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).

http://www.spinics.net/lists/kernel/msg1978216.html

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.

I've never heard of this filesystem before, and the homepage and Wikipedia don't have much detail.

How does it compare to other modern filesystems in development, like BTRFS?

What is the project's goal? Is it to be a general-purpose filesystem (ext4 replacement), or is it specialized for certain tasks (which?)?

May be a good starting point:

http://lwn.net/Articles/531126/

tux3.org

tux3.org really needs to be updated, unless "Zumastor" is some interesting meeting point between NAS and online casinos.

Reply on news.ycombinator.com