Merge pull request ceph#61742 from anthonyeleven/rgw-inlining

Improve rgw_max_chunk_size descriptions with respect to HEAD inlining

Author: anthonyeleven

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,15 +124,17 @@ 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
           an object's data can be retrieved/stored in a single librados call along with object metadata. On the other hand, a
           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:
 

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