

Tux3 Report: How fast can we fsync? - webaholic
http://www.spinics.net/lists/kernel/msg1977366.html

======
simcop2387
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?

------
buster
The reply comparing with SSD is really interesting:
[http://www.spinics.net/lists/kernel/msg1978233.html](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/](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 :)

~~~
saurik
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](http://www.spinics.net/lists/kernel/msg1978216.html)

~~~
buster
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.

~~~
rdc12
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.

------
CyberShadow
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?)?

~~~
webaholic
May be a good starting point:

[http://lwn.net/Articles/531126/](http://lwn.net/Articles/531126/)

tux3.org

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

