On Fri, Oct 27, 2017 at 5:03 PM, Ragan, Tj (Dr.) <tj.ragan@xxxxxxxxxxxxxxx> wrote: > Hi Haomai, > > According to the documentation, and a brief test to confirm, the lz4 > compression plugin isn’t distributed in the official release. I’ve tried > asking google how to add it back to no avail, so how have you added the > plugin? Is it simply a matter of putting a symlink in the right place or > will I have to recompile? yep, maybe we could add lz4 as the default buld option > > Any suggestions or pointers would be gratefully received. > > -TJ Ragan > > > > On 26 Oct 2017, at 07:44, Haomai Wang <haomai@xxxxxxxx> wrote: > > > Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>于2017年10月26日 周四17:06写道： >> >> Hi Sage, >> >> Am 25.10.2017 um 21:54 schrieb Sage Weil: >> > On Wed, 25 Oct 2017, Stefan Priebe - Profihost AG wrote: >> >> Hello, >> >> >> >> in the lumious release notes is stated that zstd is not supported by >> >> bluestor due to performance reason. I'm wondering why btrfs instead >> >> states that zstd is as fast as lz4 but compresses as good as zlib. >> >> >> >> Why is zlib than supported by bluestor? And why does btrfs / facebook >> >> behave different? >> >> >> >> "BlueStore supports inline compression using zlib, snappy, or LZ4. >> >> (Ceph >> >> also supports zstd for RGW compression but zstd is not recommended for >> >> BlueStore for performance reasons.)" >> > >> > zstd will work but in our testing the performance wasn't great for >> > bluestore in particular. The problem was that for each compression run >> > there is a relatively high start-up cost initializing the zstd >> > context/state (IIRC a memset of a huge memory buffer) that dominated the >> > execution time... primarily because bluestore is generally compressing >> > pretty small chunks of data at a time, not big buffers or streams. >> > >> > Take a look at unittest_compression timings on compressing 16KB buffers >> > (smaller than bluestore needs usually, but illustrated of the problem): >> > >> > [ RUN ] Compressor/CompressorTest.compress_16384/0 >> > [plugin zlib (zlib/isal)] >> > [ OK ] Compressor/CompressorTest.compress_16384/0 (294 ms) >> > [ RUN ] Compressor/CompressorTest.compress_16384/1 >> > [plugin zlib (zlib/noisal)] >> > [ OK ] Compressor/CompressorTest.compress_16384/1 (1755 ms) >> > [ RUN ] Compressor/CompressorTest.compress_16384/2 >> > [plugin snappy (snappy)] >> > [ OK ] Compressor/CompressorTest.compress_16384/2 (169 ms) >> > [ RUN ] Compressor/CompressorTest.compress_16384/3 >> > [plugin zstd (zstd)] >> > [ OK ] Compressor/CompressorTest.compress_16384/3 (4528 ms) >> > >> > It's an order of magnitude slower than zlib or snappy, which probably >> > isn't acceptable--even if it is a bit smaller. >> > >> > We just updated to a newer zstd the other day but I haven't been paying >> > attention to the zstd code changes. When I was working on this the >> > plugin >> > was initially also misusing the zstd API, but it was also pointed out >> > that the size of the memset is dependent on the compression level. >> > Maybe a different (default) choice there woudl help. >> > >> > https://github.com/facebook/zstd/issues/408#issuecomment-252163241 >> >> thanks for the fast reply. Btrfs uses a default compression level of 3 >> but i think this is the default anyway. >> >> Does the zstd plugin of ceph already uses the mentioned >> ZSTD_resetCStream instead of creating and initializing a new one every >> time? >> >> So if performance matters ceph would recommand snappy? > > > > in our test, lz4 is better than snappy >> >> >> Greets, >> Stefan >> _______________________________________________ >> ceph-users mailing list >> ceph-users@xxxxxxxxxxxxxx >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |