HowtoCeph: ajouter HEALTH_ERR Possible data damage

HowtoCeph.md

@@ -1198,3 +1198,58 @@ Jan  1 12:34:56 hostmane ceph-osd[1234567]: 2022-01-01 12:34:56.789 01234567890a
 >                 │ ╰──────────────────────────────────┴╴UUID présent dans le nom du LV
 >                 ╰╴numéro de l'OSD
 > ~~~
+
+## `HEALTH_ERR` - `Possible data damage`
+
+La commande `ceph -s` nous retourne une erreur de cette forme :
+
+      cluster:
+        health: HEALTH_ERR
+                24 scrub errors
+                Possible data damage: 3 pgs inconsistent
+
+Pour avoir les PG concernés :
+
+    # ceph health detail
+    HEALTH_ERR 24 scrub errors; Possible data damage: 3 pgs inconsistent
+    OSD_SCRUB_ERRORS 24 scrub errors
+    PG_DAMAGED Possible data damage: 3 pgs inconsistent
+        pg 5.13 is active+clean+inconsistent, acting [8,0]
+        pg 5.99 is active+clean+inconsistent, acting [9,4]
+        pg 5.b8 is active+clean+inconsistent, acting [9,1]
+
+On voit qu’il s’agit des PG 5.13, 5.99 et 5.b8 hébergés respectivement sur les couples d’OSD [8,0], [9,4] et [9,1]. On peut avoir plus d’informations sur ces PG avec cette commande :
+
+    # rados list-inconsistent-obj 5.99 --format=json-pretty
+
+Ici, la commande indique :
+
+                "shards": [
+                    {
+                        "osd": 4,
+                        "primary": false,
+                        "errors": [],
+                        "size": 4194304,
+                        "omap_digest": "0xffffffff",
+                        "data_digest": "0x242f0b48"
+                    },
+                    {
+                        "osd": 9,
+                        "primary": true,
+                        "errors": [
+                            "read_error"
+                        ],
+                        "size": 4194304
+                    }
+                ]
+
+L’OSD 9 retourne l’erreur `read_error`. Si on regarde la sortie de la commande `ceph osd tree`, on constate, dans ce cas, que :
+
+* tous les OSD sont actifs et accessibles ;
+* tous les PG ont une machine en commun.
+
+À ce stade, il faut vérifier sur la machine en question si les disques fonctionnent correctement. En l’occurrence, le fichier `/var/log/syslog` est rempli d’erreurs `blk_update_request: I/O error` pour deux disques, donc il faut les changer disques. En attendant, on peut essayer de faire réparer les PG :
+
+    # ceph pg repair 5.99
+
+En fonction de l’état du disque physique, l’opération se déroulera correctement et le PG sera bon. Ça peut être une bonne de sortir l’OSD du _cluster_, car dans le cas d’une panne de disque, le problème va certainement se produire de nouveau.