Page 1 of 2 12 LastLast
Results 1 to 10 of 20

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,369

    Default Tux3 File-System Claims To Be Faster Than Tmpfs

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

    http://www.phoronix.com/vr.php?view=MTM2NzU

  2. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    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

  3. #3
    Join Date
    Oct 2008
    Posts
    3,038

    Default

    Quote Originally Posted by Ericg View Post
    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.

  4. #4
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,525

    Default

    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.

  5. #5
    Join Date
    Jan 2013
    Posts
    20

    Default

    Quote Originally Posted by GreatEmerald View Post
    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.

    Daniel

  6. #6
    Join Date
    Nov 2008
    Posts
    762

    Default

    Quote Originally Posted by Ericg View Post
    If you need [..] good data integrity you go BTRFS
    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.

    Of course you can handwave that away with "backups", and handwave any performance differences away with "ssd" and then stop caring about filesystems altogether.

  7. #7

    Default

    Quote Originally Posted by danielbot View Post
    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.

  8. #8
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote Originally Posted by ssam View Post
    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.

  9. #9
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote Originally Posted by rohcQaH View Post
    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.

  10. #10
    Join Date
    Aug 2012
    Posts
    122

    Default

    And how about real life usability ? As i remember, when you install ubuntu, you cant choose most of the files systems because ubuntu cant even boot from those fs, how about other distros / fs ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •