import ceph quincy 17.2.6

[ceph.git] / ceph / doc / radosgw / placement.rst

diff --git a/ceph/doc/radosgw/placement.rst b/ceph/doc/radosgw/placement.rst
index 595fde2947040ddc74b09d22bd10786cf7adfb9e..ae4316524d94a062d91f711f3c3f7be66dfed868 100644 (file)
--- a/ceph/doc/radosgw/placement.rst
+++ b/ceph/doc/radosgw/placement.rst
@@ -86,7 +86,8 @@ The zone placement configuration can be queried with:
                       }
                   },
                   "data_extra_pool": "default.rgw.buckets.non-ec",
-                  "index_type": 0
+                  "index_type": 0,
+                  "inline_data": true
               }
           }
       ],
@@ -123,6 +124,15 @@ 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
+          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.                                          
 .. _adding_a_storage_class:
 
 Adding a Storage Class