Announcement

Collapse
No announcement yet.

Benchmarks Of The Btrfs Space Cache Option

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

  • Benchmarks Of The Btrfs Space Cache Option

    Phoronix: Benchmarks Of The Btrfs Space Cache Option

    In early November we delivered benchmarks of EXT4 vs. Btrfs on an early Linux 2.6.37 kernel as our latest round of tests comparing these two leading Linux file-systems. There were some changes in the Linux disk performance with these file-systems using the latest Linux kernel code, but overall it was not too interesting. However, as the Linux 2.6.37 kernel does introduce a new mount option for Btrfs, the space_cache option, we decided to explore its performance in today's article.

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

  • #2
    Have you done any long term analysis of the compress option?

    I used it on both my root and home partitions for a while, at the start the speed was amazing, but slowly over the course of a few months it became slower and slower

    It even started to effect the way Chrome and FireFox worked as it was taking so long to open their cache / database

    Has anyone else noticed this?

    I'm just worried that your praising the compress option because it's only been tested on clean installs and it's not being used for prolonged periods of time

    Comment


    • #3
      Originally posted by FireBurn View Post
      Have you done any long term analysis of the compress option?

      I used it on both my root and home partitions for a while, at the start the speed was amazing, but slowly over the course of a few months it became slower and slower

      It even started to effect the way Chrome and FireFox worked as it was taking so long to open their cache / database

      Has anyone else noticed this?

      I'm just worried that your praising the compress option because it's only been tested on clean installs and it's not being used for prolonged periods of time
      Nope I also have the compress option enabled and everything is very speedy.

      Comment


      • #4
        Originally posted by Ragas View Post
        Nope I also have the compress option enabled and everything is very speedy.
        How long for?

        I remember using reiser4 with compression and it used heuristics to determine what should and shouldn't be compressed

        Comment


        • #5
          Could you compare the results with same configurations but a magnetic hard disk instead of ssd?

          Comment


          • #6
            Originally posted by FireBurn View Post
            How long for?

            I remember using reiser4 with compression and it used heuristics to determine what should and shouldn't be compressed
            Since about 2-3 Month

            Comment


            • #7
              I don't know what kind of data the benchmarks use, but I'd like to see how btrfs performs when dealing with movies, audio or other already compressed data or mixed sets of data.

              Benchmarks are fine but we are not all using just databases and as FireBurn suggests, it would be nice to see how a filesystem performs after having data written it enough to fill the partition 2x or 3x.

              Comment


              • #8
                OCZ Agility EX vs. OCZ Agility II EX

                Originally posted by ChrisXY View Post
                Could you compare the results with same configurations but a magnetic hard disk instead of ssd?
                In this test is used OCZ 64GB Agility EX SSD. I believe it uses older Indilinx controller. The new Agility II uses SandForce SF-1200 controller. By default SF-1200 compresses the data before its written to the flash memory. So during the test suggested by ChrisXY I would love to see inclusion of SandForce based SSD. It will demonstrate how effective the compression option is when compression is done by SSD's controller.

                Comment


                • #9
                  My only problem with btrfs is the lack of a fsck tool that actually corrects errors, otherwise btrfs was working great until something went wrong and I couldn't correct errors in it. However, does space_cache deal with the huge about of "wasted space" that a btrfs system has?

                  Comment


                  • #10
                    Testing compression with these benchmarks is absolutely pointless, as they usually only write zeros, which can be compressed very efficently. I think you should mention that in the summary!

                    Comment


                    • #11
                      so how long you guys think will take for btrfs to become default in most distros?

                      and did the fedora guys (or whom was working on it) finish the grub integration for the snapshots?

                      Comment


                      • #12
                        Originally posted by madjr View Post
                        so how long you guys think will take for btrfs to become default in most distros?

                        and did the fedora guys (or whom was working on it) finish the grub integration for the snapshots?
                        My guess is 2 to 3 years for most of the mainstream distros. Wouldn't be surprised if *buntu jumped on it sooner though, the tend to jump on green solutions before they are ready for primetime.

                        Comment


                        • #13
                          What about the cpu usage differences ?

                          Comment


                          • #14
                            Originally posted by FireBurn View Post
                            Have you done any long term analysis of the compress option?

                            I used it on both my root and home partitions for a while, at the start the speed was amazing, but slowly over the course of a few months it became slower and slower

                            It even started to effect the way Chrome and FireFox worked as it was taking so long to open their cache / database

                            Has anyone else noticed this?

                            I'm just worried that your praising the compress option because it's only been tested on clean installs and it's not being used for prolonged periods of time
                            Chrome does that for me even on my ext4 machine. I had to symlink Chrome's cache to /dev/null because it gets ridiculously huge like 1.5gb and then Chrome locks up my machine for a good 3 minutes when it starts up.

                            After reading this article, I should start using compress on Btrfs. Can I just enable it now, or should I reformat and start fresh. I don't know if it's good to have a mix of compressed and uncompressed.

                            Comment


                            • #15
                              Originally posted by ChrisXY View Post
                              Could you compare the results with same configurations but a magnetic hard disk instead of ssd?
                              This may be more useful than one may think.

                              If one examines the "drive ready time" timings for different hard drives, this may be a major factor. Looking at http://www.google.com/search?q=hard+...dy+time%22+sec one may see that the "drive ready time" timings may vary from 5 to 25 seconds! The Western Digital Caviar Black 2TB 6GB/sec has 21 seconds, which is not good.

                              I can imagine that there is some relevance to how well the Space Cache Option performs at either end of that interval.

                              Comment

                              Working...
                              X