From 4dbaf64498030ade305ed9d4d8815d98146b8dc7 Mon Sep 17 00:00:00 2001 From: Anthony D'Atri Date: Mon, 10 Feb 2025 10:59:19 -0500 Subject: [PATCH] src/common/options: improve rgw_max_chunk_size description Signed-off-by: Anthony D'Atri --- doc/radosgw/placement.rst | 8 +++++--- src/common/options/rgw.yaml.in | 17 ++++++++++------- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/doc/radosgw/placement.rst b/doc/radosgw/placement.rst index 391e7fc83b8..bf38798dd57 100644 --- a/doc/radosgw/placement.rst +++ b/doc/radosgw/placement.rst @@ -104,7 +104,7 @@ The zone placement configuration can be queried with: Adding a Placement Target ------------------------- -To create a new placement target named ``temporary``, start by adding it to +To create a new placement target named ``temporary``, add it to the zonegroup: :: @@ -124,7 +124,7 @@ Then provide the zone placement info for that target: --index-pool default.rgw.temporary.index \ --data-extra-pool default.rgw.temporary.non-ec -.. note:: With default placement target settings, RGW stores an object's first data chunk in the RADOS "head" object along +.. note:: With default placement target settings, RGW stores an object's first data chunk in the RADOS `HEAD` object along with XATTR metadata. The `--placement-inline-data=false` flag may be passed with the `zone placement add` or `zone placement modify` commands to change this behavior for new objects stored on the target. When data is stored inline (default), it may provide an advantage for read/write workloads since the first chunk of @@ -132,7 +132,9 @@ Then provide the zone placement info for that target: target that does not store data inline can provide a performance benefit for RGW client delete requests when the BlueStore DB is located on faster storage than bucket data since it eliminates the need to access slower devices synchronously while processing the client request. In that case, data associated with the deleted - objects is removed asynchronously in the background by garbage collection. + objects is removed asynchronously in the background by garbage collection. Note that inlining is only ever performed + when writing to the default storage class. Inlining is *never* performed when writing to a non-default + storage class. .. _adding_a_storage_class: diff --git a/src/common/options/rgw.yaml.in b/src/common/options/rgw.yaml.in index 663b51ab26a..e049c3c367a 100644 --- a/src/common/options/rgw.yaml.in +++ b/src/common/options/rgw.yaml.in @@ -85,13 +85,16 @@ options: type: size level: advanced desc: The maximum RGW chunk size. - long_desc: The chunk size is the size of RADOS I/O requests that RGW sends when - accessing data objects. RGW read and write operations will never request more than - this amount in a single request. This also defines the RGW head object size, as - head operations need to be atomic, and anything larger than this would require - more than a single operation. When RGW objects are written to the default - storage class, up to this amount of payload data will be stored alongside - metadata in the head object. + long_desc: The chunk size is the size of requests that RGW sends to + OSDs when accessing RADOS objects. RGW read and write operations will never + request more than this amount in a single request. This also defines the RGW + HEAD object size, as head operations need to be atomic, and anything larger + than this would require more than a single operation. When RGW objects are + written to the default storage class, up to this amount of payload data will + be stored alongside metadata in the head object. Note that when writing + an RGW object to a non-default storage class the HEAD RADOS object is always + stored in the default storage class' pool but no inlining of payload data + is performed. default: 4_M services: - rgw -- 2.39.5