Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Btrfs LZO Compression Performance

  1. #1
    Join Date
    Jan 2007
    Posts
    15,438

    Default 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. #2
    Join Date
    Jul 2007
    Posts
    57

    Default

    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

  3. #3

    Default

    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 ?

  4. #4
    Join Date
    Oct 2008
    Posts
    14

    Default

    Quote 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.

  5. #5
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    593

    Default

    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

  6. #6
    Join Date
    Jan 2009
    Posts
    80

    Default

    Quote 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.

  7. #7
    Join Date
    Apr 2008
    Posts
    10

    Default lzo + ssd?

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

  8. #8

    Default

    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.

  9. #9
    Join Date
    Apr 2008
    Posts
    10

    Default

    Quote 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.

  10. #10

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •