]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/radosgw/compression: separate RGW and RADOS pool level compression
authorLaimis Juzeliūnas <asnelaimis@gmail.com>
Fri, 25 Apr 2025 10:08:38 +0000 (13:08 +0300)
committerLaimis Juzeliūnas <asnelaimis@gmail.com>
Mon, 28 Apr 2025 14:35:39 +0000 (17:35 +0300)
Add notes indicating a difference between compressions done by RGW and on RADOS pool level for better understanding.

Signed-off-by: Laimis Juzeliunas <laimis.juzeliunas@oxylabs.io>
Co-authored-by: Anthony D'Atri <anthonyeleven@users.noreply.github.com>
doc/rados/operations/pools.rst
doc/radosgw/compression.rst

index 8686dddf635197922762dfd6c31773d0fb132d01..b84008b77f5660348cc9b5be0971c3c0aaf01ac8 100644 (file)
@@ -399,6 +399,12 @@ You may set values for the following keys:
    :Description: Sets the maximum size for chunks: that is, chunks larger than this are broken into smaller blobs no larger than this size before compression is performed.
    :Type: Unsigned Integer
 
+.. note:: Compressed pool statistics are visible using ``ceph df detail``.
+   Objects within compressed pools will show their original uncompressed
+   sizes via most API calls or CLI commands. For example: RGW buckets 
+   placed directly in a compressed RADOS pool with no RGW level compression 
+   will report uncompressed bucket sizes via ``radosgw-admin``.
+
 .. _size:
 
 .. describe:: size
index 429dde91c73ddf6290d7266e6447804f982ca22e..cf778cc762b7da98273415f0b5dd7b621794f71c 100644 (file)
@@ -5,7 +5,6 @@ Compression
 .. versionadded:: Kraken
 
 The Ceph Object Gateway supports server-side compression of uploaded objects.
-using any of the existing compression plugins.
 
 .. note:: The Reef release added a :ref:`feature_compress_encrypted` zonegroup
    feature to enable compression with `Server-Side Encryption`_.
@@ -17,6 +16,16 @@ Supported compression plugins include the following:
 * zlib
 * zstd
 
+.. note:: Ceph Object Gateway compression is performed by RGW daemons only
+   for RGW objects, and is distinct from BlueStore compression that is performed 
+   by OSDs at pool granularity. It is typical to only enable one or the other. 
+   Enabling at both levels does not cause a problem, but one should make the decision 
+   based on the use case. If your cluster only serves object storage and the nodes 
+   where RGW runs have more available CPU than OSD nodes, RGW level compression may be appealing. 
+   Compressing at the OSD level does mean compressing the same user data more 
+   than once since it is post-replication, but in a cluster with far more OSDs 
+   than RGWs this strategy may result in better performance.
+
 Configuration
 =============