src/common/options: improve rgw_max_chunk_size description

Signed-off-by: Anthony D'Atri <anthonyeleven@users.noreply.github.com>

diff --git a/doc/radosgw/placement.rst b/doc/radosgw/placement.rst
index 391e7fc83b8d0208c2b04d8c9b1199736c2d32d5..bf38798dd573175ba554f9e8100372475844f65f 100644 (file)
--- 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 663b51ab26aea0bcdf7e3424694e6711f967044a..e049c3c367afd3a38d20de0a9131095546379829 100644 (file)
--- 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