Announcement

Collapse
No announcement yet.

Tux3 File-System Claims To Be Faster Than Tmpfs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #3
      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.

      Comment


      • #4
        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


        • #5
          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

          Comment


          • #6
            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.

            Comment


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

              Comment


              • #8
                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.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #9
                  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.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #10
                    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 ?

                    Comment

                    Working...
                    X