]> git.proxmox.com Git - ceph.git/blobdiff - ceph/doc/rados/troubleshooting/troubleshooting-pg.rst
update sources to v12.2.5
[ceph.git] / ceph / doc / rados / troubleshooting / troubleshooting-pg.rst
index c51ed316f725cbf1cb0044f4059007fdaad0383b..eddb9624bbe96c9a47e2e047519e42962bd08775 100644 (file)
@@ -383,8 +383,8 @@ objects. If an object named ``foo`` in PG ``0.6`` is truncated, we will have::
                     "size_mismatch"
                 ],
                 "union_shard_errors": [
-                    "data_digest_mismatch_oi",
-                    "size_mismatch_oi"
+                    "data_digest_mismatch_info",
+                    "size_mismatch_info"
                 ],
                 "selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])",
                 "shards": [
@@ -405,8 +405,8 @@ objects. If an object named ``foo`` in PG ``0.6`` is truncated, we will have::
                     {
                         "osd": 2,
                         "errors": [
-                            "data_digest_mismatch_oi",
-                            "size_mismatch_oi"
+                            "data_digest_mismatch_info",
+                            "size_mismatch_info"
                         ],
                         "size": 0,
                         "omap_digest": "0xffffffff",
@@ -437,9 +437,9 @@ In this case, we can learn from the output:
     ``oi`` indicate a comparison with ``selected_object_info``. Look at the
     ``shards`` array to determine which shard has which error(s).
 
-    * ``data_digest_mismatch_oi``: the digest stored in the object-info is not
+    * ``data_digest_mismatch_info``: the digest stored in the object-info is not
       ``0xffffffff``, which is calculated from the shard read from OSD.2
-    * ``size_mismatch_oi``: the size stored in the object-info is different
+    * ``size_mismatch_info``: the size stored in the object-info is different
       from the one read from OSD.2. The latter is 0.
 
 You can repair the inconsistent placement group by executing::