Announcement

Collapse
No announcement yet.

Btrfs LZO Compression Performance

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

  • Btrfs LZO Compression Performance

    Phoronix: Btrfs LZO Compression Performance

    While the performance of the Btrfs file-system with its default mount options didn't change much with the just-released Linux 2.6.38 kernel as shown by our large HDD and SSD file-system comparison, this new kernel does bring LZO file-system compression support to Btrfs. This Oracle-sponsored file-system has supported Gzip compression for months as a means to boost performance and preserve disk space, but now there's support for using LZO compression. In this article we are looking at the Btrfs performance with its default options and then when using the transparent Zlib and LZO compression.

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

  • #2
    This bench cries to be compared to reiser4 compression abilities If you could do that it would be awesome...

    P.S. At the time of writing there is no 2.6.38 reiser4 patch yet, but it should follow shortly

    Comment


    • #3
      Why do i get the feeling that zlib/lzo mode speeds up iozone and fs-mark only because the created files are empty and thus compress almost infintely good ?

      Comment


      • #4
        Originally posted by Kirurgs View Post
        This bench cries to be compared to reiser4 compression abilities If you could do that it would be awesome...

        P.S. At the time of writing there is no 2.6.38 reiser4 patch yet, but it should follow shortly
        Indeed, more so considering reiser4 has had LZO compression support for many years already.

        Comment


        • #5
          I know seeing these benchmarks takes me back to my reiser4 days

          I guess it really was years ahead if it's time, it's a shame that the same level or development wasn't maintained after Hans arrest

          Comment


          • #6
            Originally posted by BenderRodriguez View Post
            Why do i get the feeling that zlib/lzo mode speeds up iozone and fs-mark only because the created files are empty and thus compress almost infintely good ?
            I get that impression, too. This makes those tests completely irrelevant.

            Comment


            • #7
              lzo + ssd?

              I wonder if compression helps or hurts performance on ssd? Access is already fast.

              Comment


              • #8
                Depends on what type of files you got and how many of them. Binary/video/audio/pdf/other already compressed files don't compress too well so LZO won't help much, it will help only with those that compress well. Also as the files will take a little bit less of space it will help and lower the writes number on SSD

                The threaded writes are slower probably because it is CPU bound, without zlib/lzo the cpu only had to process (or not at all, DMA) the write while with zlib/lzo it has to compress them.

                Comment


                • #9
                  Originally posted by BenderRodriguez View Post
                  Depends on what type of files you got and how many of them. Binary/video/audio/pdf/other already compressed files don't compress too well so LZO won't help much, it will help only with those that compress well. Also as the files will take a little bit less of space it will help and lower the writes number on SSD

                  The threaded writes are slower probably because it is CPU bound, without zlib/lzo the cpu only had to process (or not at all, DMA) the write while with zlib/lzo it has to compress them.
                  I was thinking that for slow mechanical disk, lzo helps performance because compress/decompress is faster than read/write extra blocks to/from disk. But SSD maybe not.

                  Comment


                  • #10
                    Originally posted by nbecker View Post
                    I was thinking that for slow mechanical disk, lzo helps performance because compress/decompress is faster than read/write extra blocks to/from disk. But SSD maybe not.
                    You may be right.

                    Comment

                    Working...
                    X