I got back around to testing this more today and I believe figured this out.
Originally I set compression_mode to aggressive for the pool. The OSDs themselves, however, had their compression mode set to the default of none. That means that while the pool was flagging the writes so that they should be compressed, the OSD was ignoring that. Setting the OSDs to bluestore_compression_mode = passive tells the OSD not to compress anything unless the write is flagged for compression. So now I'm seeing compression for writes into the pool set to aggressive compression and no compression for the other pools. Alternatively if I were to have set compression for the OSD to aggressive, it should have been attempting compression for all writes to all pools. We have different pools in our deployment, some that I want compression on and others that I don't. If you just want compression on everything, set the OSD config to aggressive. However if you're like me, setting the OSDs to passive and the specific pools to aggressive will give you the desired result. On Wed, Jun 27, 2018 at 11:23 AM David Turner <drakonst...@gmail.com> wrote: > Default OSD settings for compression and the pool has `compression_mode: > aggressive`. From my understanding, that should not bother compressing > anything except for the specific pool. First I tested this with an EC data > pool, but it didn't compress anything. I thought this might be a thing > with EC sharding so I tested with a replica pool with 100 copies of the > same 10GB file and 1TB of zero's. Neither test seemed to show any > compression. > > On Wed, Jun 27, 2018 at 6:38 AM Igor Fedotov <ifedo...@suse.de> wrote: > >> And yes - first 3 parameters from this list are the right and the only >> way to inspect compression effectiveness so far. >> >> >> Corresponding updates to show that with "ceph df" are on the way and are >> targeted for Nautilus. >> >> >> Thanks, >> >> Igor >> >> On 6/26/2018 4:53 PM, David Turner wrote: >> >> ceph daemon osd.1 perf dump | grep bluestore | grep compress >> "bluestore_compressed": 0, >> "bluestore_compressed_allocated": 0, >> "bluestore_compressed_original": 0, >> "bluestore_extent_compress": 35372, >> >> I filled up an RBD in a compressed pool (aggressive) in my test cluster >> with 1TB of zeros. The bluestore OSDs in the cluster all show similar to >> this. Am I missing something here? Is there any other method to >> determining compression ratios? >> >> On Tue, Dec 5, 2017 at 1:25 AM Rafał Wądołowski < >> rwadolow...@cloudferro.com> wrote: >> >>> Finally, I've founded the command: >>> >>> >>> ceph daemon osd.1 perf dump | grep bluestore >>> >>> >>> And there you have compressed data >>> Regards, >>> >>> Rafał Wądołowski >>> >>> >>> http://cloudferro.com/ >>> On 04.12.2017 14:17, Rafał Wądołowski wrote: >>> >>> Hi, >>> >>> Is there any command or tool to show effectiveness of bluestore >>> compression? >>> >>> I see the difference (in ceph osd df tree), while uploading a object to >>> ceph, but maybe there are more friendly method to do it. >>> >>> >>> >>> _______________________________________________ >>> ceph-users mailing list >>> ceph-users@lists.ceph.com >>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >>> >> >> >> _______________________________________________ >> ceph-users mailing >> listceph-us...@lists.ceph.comhttp://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >> >> _______________________________________________ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
