If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Tux3 File-System Claims To Be Faster Than Tmpfs

05-07-2013, 11:00 PM

Phoronix: Tux3 File-System Claims To Be Faster Than Tmpfs

The experimental Tux3 file-system has already made claims of being faster than EXT4. The latest claims out of the open-source file-system is that it's faster than Tmpfs, which is quite a feat given its very thin layer between VFS and SWAP...

So does anyone else see this as becoming... If you need multiple disk support, or good data integrity you go BTRFS, but if you just need speed and 'general' data integrity you got Tux3 (replacing EXT4)? I mean, EXT4's general architecture is like 20years old at this point, its EXT1 with boilerplate extensions ontop of it

Comment

So does anyone else see this as becoming... If you need multiple disk support, or good data integrity you go BTRFS, but if you just need speed and 'general' data integrity you got Tux3 (replacing EXT4)? I mean, EXT4's general architecture is like 20years old at this point, its EXT1 with boilerplate extensions ontop of it

Tux3 has a long, long way to go before it's there, but if the FS takes off and actually gains more developer support then yes.

It's looked promising before, too, though, and then the main developer left for 3 years and nothing happened. He's got a history of starting out cool projects and then abandoning them before completion.

Comment

What. It can't be faster than tmpfs, because tmpfs doesn't use the disk to begin with, unless the RAM is so used it it has to start swapping things out. In which case yes, it becomes slow, but that's something that should not happen in the first place.

Comment

What. It can't be faster than tmpfs, because tmpfs doesn't use the disk to begin with, unless the RAM is so used it it has to start swapping things out. In which case yes, it becomes slow, but that's something that should not happen in the first place.

The reason why Tux3 beats Tmpfs in this particular benchmark (dbench) is explained in the post. It is because Tux3 is able to offload some of the delete work to a second CPU so that the dbench task can continue as soon as Tux3 sets the "deleted" bit in the inode. Tmpfs does not know how to do this trick, but if somebody cared enough, it could be programmed. In my opinion the additional complexity would not be worth it for Tmpfs, but if you feel differently then by all means code ahead and code it up.

Comment

The reason why Tux3 beats Tmpfs in this particular benchmark (dbench) is explained in the post. It is because Tux3 is able to offload some of the delete work to a second CPU so that the dbench task can continue as soon as Tux3 sets the "deleted" bit in the inode. Tmpfs does not know how to do this trick, but if somebody cared enough, it could be programmed. In my opinion the additional complexity would not be worth it for Tmpfs, but if you feel differently then by all means code ahead and code it up.

That's a good way to look at it. basically this has uncovered a bottle neck in tmpfs.

tmpfs should always be fastest because there are lots of things that it does not need to worry about (eg unexpected shutdown safety). but there are probably bits in it that are slower then they could be, and nobody notices until they try to benchmark against a competing implementation.

Comment

That's a good way to look at it. basically this has uncovered a bottle neck in tmpfs.

tmpfs should always be fastest because there are lots of things that it does not need to worry about (eg unexpected shutdown safety). but there are probably bits in it that are slower then they could be, and nobody notices until they try to benchmark against a competing implementation.

Not just tmpfs, from the way the tux3 wikipedia entry, and some mailing lists entries are describing it... Tux3 is one of the very few filesystems on linux to take advantage of async-CPU operations. Its multi-core aware and is actually using them.

Comment

Given the track record of btrfs, I still consider ext4 to be more trustworthy than btrfs. When it comes to reliability, a 20 year old architecture can be a good thing.

Those are bugs, not architecture problems. Ext4 cant get snapshotting, checksumming, COW, or any of the other "Data integrity" features of its design, You can fix bugs, but if you're "fixing" the entire architecture of a project, youre basically just creating a new project.