Announcement

Collapse
No announcement yet.

Benchmarking Linux 3.16 File-Systems On An SSD

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

  • Benchmarking Linux 3.16 File-Systems On An SSD

    Phoronix: Benchmarking Linux 3.16 File-Systems On An SSD

    With the Linux 3.16 kernel coming along nicely, here's our first tests of this forthcoming major kernel upgrade when it comes to the mainline file-systems and their performance from a solid-state drive.

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

  • #2
    Nice... each new kernel version has consistently been slower than the last (for ext4, at least). Guess I'll get a huge FS performance boost by reverting to 3.10 or older

    Comment


    • #3
      Originally posted by phoronix View Post
      Phoronix: Benchmarking Linux 3.16 File-Systems On An SSD

      With the Linux 3.16 kernel coming along nicely, here's our first tests of this forthcoming major kernel upgrade when it comes to the mainline file-systems and their performance from a solid-state drive.

      http://www.phoronix.com/vr.php?view=20631
      Personally, not really sure if we need these benchmarks per kernel, unless some significant changes are made to the filesystem code or the kernel code.

      Maybe one way to make them more relevant would be to also test battery usage of the Filesystems too, unless there is a HUGE regression in performance

      Comment


      • #4
        Is F2FS a legitimate choice on a full on desktop SSD? I thought it was for SD cards and embedded memory in Android phones and the like? What's the current thinking with regards to stability?

        Comment


        • #5
          f2fs

          Originally posted by kaprikawn View Post
          Is F2FS a legitimate choice on a full on desktop SSD? I thought it was for SD cards and embedded memory in Android phones and the like? What's the current thinking with regards to stability?
          My experience is: F2FS is stable if and only if it's always (!) unmounted clearly. If not (i.e. if you unplug the flash card without unmounting first), the FS soon gets corrupted, and fsck.f2fs is mostly not capable of repairing it: In the case of a corrupted FS, it aborts with assert statements.

          Comment


          • #6
            Originally posted by Auzy View Post
            Personally, not really sure if we need these benchmarks per kernel, unless some significant changes are made to the filesystem code or the kernel code.
            The performance of some area of the kernel depends on many things. The radeon performance, for instance, boosted with changes on the CPU frequency scheduler. Thanks to these benchmarks, at least it can be noted if, after the storm of commits, the butterfly created a hurricane.

            (As for halo9en's comments: I thought the same!)

            Comment


            • #7
              Why not test Btrfs instead of F2FS?

              Why not test Btrfs instead of (or in addition to) F2FS? Btrfs is much more relevant for desktops, and dare I say more exciting in terms of features.

              Comment


              • #8
                Originally posted by stan View Post
                Why not test Btrfs instead of (or in addition to) F2FS? Btrfs is much more relevant for desktops, and dare I say more exciting in terms of features.
                The article states that Btfs was skipped this round because it is too unstable in the 3.16 snapshot that Michael used.

                Comment


                • #9
                  Originally posted by Pseus View Post
                  The article states that Btfs was skipped this round because it is too unstable in the 3.16 snapshot that Michael used.
                  Dope, my bad. Thanks for pointing out the obvious for me

                  Comment


                  • #10
                    Here's your new Linux kernel: here's a number of new regressions. We, Linux developer, love regressions ;-)

                    Comment

                    Working...
                    X