Announcement

Collapse
No announcement yet.

Tux3 File-System Claims To Be Faster Than Tmpfs

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

  • #16
    Originally posted by Teho View Post
    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.
    If you want to be fancy, and don't want to use GRUB2, then go for rEFInd. Compared to Gummiboot, it's more advanced and supports more eye-candy.

    Comment


    • #17
      and the first reply in the email-thread was D. Chinner debunking those claims.

      Phoronix REALLY should rename to moronix.

      Comment


      • #18
        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.
        they uncovered NOTHING. They changed dbench and BROKE FSYNC.

        If that does not fill your mind with rage and your heart with fear I don't know what. fsync() must not return before the data is on the media. tux3 returns fsync() before the data is on the media.

        Basically: cheating. Read the emails yourself.

        Next time moronix posts some crap, check it for yourself. Especially with filesystems. Saying that moronix track record is spotty in that regard is an understatement.

        Comment


        • #19
          Originally posted by energyman View Post
          they uncovered NOTHING. They changed dbench and BROKE FSYNC.

          If that does not fill your mind with rage and your heart with fear I don't know what. fsync() must not return before the data is on the media. tux3 returns fsync() before the data is on the media.

          Basically: cheating. Read the emails yourself.
          Read the mails yourself, and notice the simple fact that all three filesystems ran exactly the same perfectly valid benchmark. I think you owe me an apology.

          Comment


          • #20
            I own you nothing. Benchmarking with a broken fsync() and then claim to be faster is deceptive at best.

            It is like saying that a fused automatic fuse is much better because it can tolerate a much higher current.

            T'so and Chinner said it much better than I can.

            Comment

            Working...
            X