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

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

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

    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.

                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.

                  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


                    • #11
                      Originally posted by startzz View Post
                      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 ?
                      that's not an Ubuntu issue, that's a grub issue, and grub2 should be able to boot from every FS the community uses now, including btrfs. tux3 will come once its mainlined

                      Comment


                      • #12
                        Originally posted by Ericg View Post
                        that's not an Ubuntu issue, that's a grub issue, and grub2 should be able to boot from every FS the community uses now, including btrfs. tux3 will come once its mainlined
                        GRUB2 will become quite irrelevant in not so distant future as nearly all machines will ship with UEFI. Then it's better to put the /boot folder under EFI partition and use Gummiboot (or something similar) as loader. This way you can use any file system Linux kernel supports for everything else.

                        Comment


                        • #13
                          Originally posted by Teho View Post
                          GRUB2 will become quite irrelevant in not so distant future as nearly all machines will ship with UEFI. Then it's better to put the /boot folder under EFI partition and use Gummiboot (or something similar) as loader. This way you can use any file system Linux kernel supports for everything else.
                          Trust me, I know, im looking forward to it. Been looking forward to it since the kernel first started getting the ability to be its own bootloader.

                          Comment


                          • #14
                            Originally posted by Teho View Post
                            GRUB2 will become quite irrelevant in not so distant future as nearly all machines will ship with UEFI. Then it's better to put the /boot folder under EFI partition and use Gummiboot (or something similar) as loader. This way you can use any file system Linux kernel supports for everything else.
                            If you really want to get down to that, you should use EFISTUB with efibootmgr directly :P

                            Though honestly, if dual-booting, I still use GRUB2. The GRUB shell is always a good thing to have, and GRUB2 doesn't have any problems with being an UEFI program, either.

                            Comment


                            • #15
                              Originally posted by GreatEmerald View Post
                              If you really want to get down to that, you should use EFISTUB with efibootmgr directly :P
                              Gummiboot looks like a better choise to me. It uses EFISTUB and provides simple menu for choosing the kernel. It also support Boot loader Interface which is cool if you use systemd (systemd-analyze shows how much time the firmware and loader took to load and bootctl shows some other information). It also follows the Boot Loader Specification and is ridiculously easy to use; not to mention it automatically detects Windows and OS X installs.
                              Last edited by Teho; 05-08-2013, 02:45 PM.

                              Comment

                              Working...
                              X