]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commitdiff
doc: address review comments
authorShraddha Agrawal <shraddha.agrawal000@gmail.com>
Wed, 14 May 2025 12:36:38 +0000 (18:06 +0530)
committerShraddha Agrawal <shraddha.agrawal000@gmail.com>
Thu, 15 May 2025 05:33:50 +0000 (11:03 +0530)
Signed-off-by: Shraddha Agrawal <shraddha.agrawal000@gmail.com>
PendingReleaseNotes
doc/rados/operations/monitoring.rst

index b238937eb81ea0d512eb41b62a53de5dcb153f89..8380f6c06e0a3d5c21e339d1c7730e8f7582790e 100644 (file)
   users to view the availability score for each pool in a cluster. A pool is considered 
   unavailable if any PG in the pool is not in active state or if there are unfound 
   objects. Otherwise the pool is considered available. The score is updated every 
-  5 seconds. 
+  5 seconds. This feature is in tech preview. 
   Related trackers:
    - https://tracker.ceph.com/issues/67777
 
index 6e879defdaacd6954fa3937a5cbf83176a230571..176661d8bc91854afaa034697dbcafc236afcea2 100644 (file)
@@ -751,8 +751,7 @@ the following command can be invoked:
 
    ceph osd pool availability-status
 
-If the cluster has 4 pools, this is what the ``availability-status`` 
-will report:  
+Example output:  
 
 .. prompt:: bash $
 
@@ -762,15 +761,12 @@ will report:
    cephfs.a.meta       77s     0s              0       0s      0s      1       1
    cephfs.a.data       76s     0s              0       0s      0s      1       1
 
-We consider a pool unavailable if there is potentially any data loss. 
-This means, if there are any PG in the pool not in 
-active state or if there are unfound objects, some data might be
-either unreachable or lost. In such cases, we mark the pool as 
-unavailable. Otherwise the pool is considered available. 
-For example: A pool will be marked available even if an OSD is down 
-as long as PG replication ensures there is no data loss. 
+A pool is considered ``unavailable`` when at least one PG in the pool 
+becomes inactive or there is at least one unfound object in the pool. 
+Otherwise the pool is considered ``available``. 
 
 We first calculate the Mean Time Between Failures (MTBF) and 
-Mean Time To Recover (MTTR) and arrive at the availability score 
+Mean Time To Recover (MTTR) from the uptime and downtime recorded 
+for each pool and arrive at the availability score 
 by finding ratio of MTBF to total time (ie MTTR + MTBF).  The score
 is updated every 5 seconds. 
\ No newline at end of file