Announcement

Collapse
No announcement yet.

Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

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

  • Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

    Phoronix: Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

    While we have already delivered a number of benchmarks from the Linux 2.6.39 kernel, surprisingly we have not yet published any new file-system benchmarks from this latest stable Linux kernel release. Fortunately, that has changed today with a fresh round of Btrfs, EXT4, and XFS file-system benchmarks on the Linux 2.6.39 kernel and compared to the preceding 2.6.38 and 2.6.37 kernel releases.

    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
    Normally people (like myself) complain if they are unhappy with the article.

    So, this time I'd like to say that this was a good article. You provided some useful explanations, and also linked to the optimizations at the end which was informative

    Thanks!

    Comment


    • #3
      Originally posted by yesterday View Post
      Normally people (like myself) complain if they are unhappy with the article.

      So, this time I'd like to say that this was a good article. You provided some useful explanations, and also linked to the optimizations at the end which was informative

      Thanks!
      Amazing. This is the first time I've ever seen a comment on Phoronix saying they liked an article. I'm so used to seeing nothing pure hatred in every article comment. Maybe there is hope after all.

      Comment


      • #4
        Multicore CPU Usage

        I have a hexacore now so I'm interested in a filesystem that makes good use of multiple cores. Would btrfs be much faster with compression enabled if a system had many cores? Could the compression/decompression be done by a GPU?

        Comment


        • #5
          Remember the Commodore VIC 20


          For some reason I was sitting here reading this excellent article and was reminded of the VIC 20.

          Comment


          • #6
            Originally posted by flammon View Post
            I have a hexacore now so I'm interested in a filesystem that makes good use of multiple cores. Would btrfs be much faster with compression enabled if a system had many cores? Could the compression/decompression be done by a GPU?
            It's possible that the compression could be offloaded to another core(s) or a GPU, but compression is often a fairly serial process, so depending on the algorithm, you'd probably not get much of a speedup.

            Also, for the small block sizes being compressed, you'd probably not benefit from GPU compression/decompression as the round trip to the GPU and the computation startup/finish costs would probably exceed any time benefit from the parallelism you might be able to extract.

            Offloading the compression/decompression to a separate thread on the CPU might be possible, and that's where I'd probably start poking around (if they're not already doing this).

            Comment


            • #7
              jfs

              JFS is omitted from the comparison again
              What is the reason for this? Isn't it as popular as XFS?

              Comment


              • #8
                Wow, really good and specific article. Thankks.

                Also congratulations to xfs developers for improving xfs so much

                Comment


                • #9
                  Originally posted by danny.archer View Post
                  JFS is omitted from the comparison again
                  What is the reason for this? Isn't it as popular as XFS?
                  JFS is a dieing filesystem. Even IBM isn't interested in maintaining it anymore and the one IBM employee that is more or less keeping an eye on it ("very part time") to fix bugs recommends not using it for production environments.

                  Comment


                  • #10
                    Originally posted by deanjo View Post
                    JFS is a dieing filesystem. Even IBM isn't interested in maintaining it anymore and the one IBM employee that is more or less keeping an eye on it ("very part time") to fix bugs recommends not using it for production environments.
                    damn, that's too bad, I'm quite fond of JFS. I've just switched to a new hard drive and all the partitions are JFS, previous hard drive had also XFS. I've managed to avoid EXT3&4

                    *sigh*

                    Comment

                    Working...
                    X