Tux3 File-System Works Out Faster Fsync Support

[phoronix]

Phoronix: Tux3 File-System Works Out Faster Fsync Support

Daniel Phillips has worked out faster fsync support within Tux3, the promising open-source file-system that continues to be developed outside of the mainline kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Tux3-Faster-FSync

[wikinevick]

Not very believable

Unfortunately tux3 has never passed beyond being a prototype of a bunch of concepts that no one fully understands.

Every time Daniel Philips makes some claim, around an artificial benchmark he just made up, the situation pretty much dies there simply because the filesystem is not yet a filesystem, or at least something that will work for any use case. Perhaps if the two developers working on it finish it before running claims, the benchmarks results will be more credible.

[wikinevick]

...
Every time Daniel Philips makes some claim, around an artificial benchmark he just made up, the situation pretty much dies there simply because the filesystem is not yet a filesystem, or at least something that will work for any use case.

Actually ... I'll take that back.

It runs Dbench so we should all consider reformatting our Ext4/XFS partitions and replacing them with tux3.

[arzeth]

Actually ... I'll take that back.

It runs Dbench so we should all consider reformatting our Ext4/XFS partitions and replacing them with tux3.

Only when it will be tested by at least 10 000 (?) users or you like to test. Because an FS is not a toy.
Currently there are problems like:

My "hirofumi" branch in public repo is still having the bug to leave the
empty block for inodes by repeat of create and unlink. And this bug
makes fragment of FS very fast. (This bug is what I'm fixing, now.)

[leidola]

Actually ... I'll take that back.

It runs Dbench so we should all consider reformatting our Ext4/XFS partitions and replacing them with tux3.

No, we shouldn't, as the file system has no usefull allocator. You need to run the benchmark on a fresh file system each time or soon you'll run out of space. To quote one of the critics:

> In the full disclosure department, Tux3 is still not properly
> optimized in some areas. One of them is fragmentation: it is not
> very hard to make Tux3 slow down by running long tests. Our current

Oh, that still hasn't been fixed?

Until you sort of how you are going to scale allocation to tens of
TB and not fragment free space over time, fsync performance of the
filesystem is pretty much irrelevant. Changing the allocation
algorithms will fundamentally alter the IO patterns and so all these
benchmarks are essentially meaningless.

Also, all the benchmarks of tux3 are shown on non-SSD hardware. While this is still qute common, it only shows which file system optimizes the seek time. XFS for example doesn't do this... on purpose:

In this case, ext4, btrfs and tux3 have optimal allocation filling
from the outside of the disk, while XFS is spreading the files
across (at least) 4 separate regions of the whole disk. Hence XFS is
seeing seek times on read are much larger than the other filesystems
when the filesystem is empty as it is doing full disk seeks rather
than being confined to the outer edges of spindle.

Thing is, once you've abused those filesytsems for a couple of
months, the files in ext4, btrfs and tux3 are not going to be laid
out perfectly on the outer edge of the disk. They'll be spread all
over the place and so all the filesystems will be seeing large seeks
on read. The thing is, XFS will have roughly the same performance as
when the filesystem is empty because the spreading of the allocation
allows it to maintain better locality and separation and hence
doesn't fragment free space nearly as badly as the oher filesystems.
Free space fragmentation is what leads to performance degradation in
filesystems, and all the other filesystem will have degraded to be
*much worse* than XFS.

Put simply: empty filesystem benchmarking does not show the real
performance of the filesystem under sustained production workloads.
Hence benchmarks like this - while interesting from a theoretical
point of view and are widely used for bragging about whose got the
fastest - are mostly irrelevant to determining how the filesystem
will perform in production environments.

We can also look at this algorithm in a different way: take a large
filesystem (say a few hundred TB) across a few tens of disks in a
linear concat. ext4, btrfs and tux3 will only hit the first disk in
the concat, and so go no faster because they are still bound by
physical seek times. XFS, however, will spread the load across many
(if not all) of the disks, and so effectively reduce the average
seek time by the number of disks doing concurrent IO. Then you'll
see that application level IO concurrency becomes the performance
limitation, not the physical seek time of the hardware.
[...]

(from http://www.spinics.net/lists/kernel/msg1978216.html)

[gigaplex]

EXT4 maintainer Ted Ts'o previously doubted Tux3 capabilities when it came to a fast and reliable fsync, but Phillips has managed to prove him wrong with the latest async Tux3 fsync code.

Until this has been independently verified, nobody has been proven wrong yet.

[nils_]

Benchmarking on a single disk and then on "tmpfs", through KVM. That just sounds like a badly designed experiment.

[danielbot]

No, we shouldn't, as the file system has no usefull allocator. You need to run the benchmark on a fresh file system each time or soon you'll run out of space.

Incorrect, you will get long term fragmentation and run a bit slower, but still fast most probably. It actually takes a lot of churn to age a filesystem to the point where you notice it.The real reason you should not use Tux3 unless you are a developer is, Tux3 is for developers right now. It is hard to emphasize that enough. And by the way, it is fun to develop because it does use these new ideas that work out really well, and win benchmarks for example.

Also, all the benchmarks of tux3 are shown on non-SSD hardware.

False. Benchmarks running on top of ram (tmpfs) are shown here: http://www.spinics.net/lists/kernel/msg1978483.html

While this is still qute common, it only shows which file system optimizes the seek time. XFS for example doesn't do this... on purpose:

Far be it from me to know why somebody wants their filesystem to run slowly, but if XFS devs want it that way and can convince you that slow is actually good then more power to them.

[danielbot]

Until this has been independently verified, nobody has been proven wrong yet.

Just waiting for the other shoe to drop. Our older branch, with a somewhat optimized fsync was independently tested here: http://www.spinics.net/lists/kernel/msg1977934.html

Notice that Tux3 is way ahead of XFS and Ext4 on normal dbench and swapping first place with Btrfs. That is still with every fsync being a full filesystem sync like Ext3. So you can be pretty sure what is going to happen to those numbers, especially the -s ones that test _only_ fsync when the proper, separate fsync like Ext4 lands. By all means, be a doubter if that suits your fancy, but do not forget that in polite society, one normally apologizes afterwards when proved wrong.

[gilboa]

False. Benchmarks running on top of ram (tmpfs) are shown here: http://www.spinics.net/lists/kernel/msg1978483.html

I'm no storage or FS expert, but SSD != tmpfs.
1. SSD's writes are far more complicated than tmpfs. (Write block size, wear-leveling, house-keeping/trim, etc).
2. SSD's (or any storage device) SATA interface completely changes the benchmark results. E.g. large number of small IO requests will have near-zero effect on tmpfs but will have a tremendous effect on bus based devices.

- Gilboa