在上週的ceph-devel 郵件列表中，有人提到了在測試的環境中出現了 unfound object 的狀態，本文試圖分析這種情況發生的原理。

首先介紹一下什麼是 unfoud object ？ unfoud object 物件就是 完成了peering 過程，各個副本達成了一致的狀態。 簡單的說，就是在副本中確定了物件的正確的版本。 在recovery 過程中，要去確定該正確的版本物件 所在的osd上的位置，如果沒有找到 擁有該正確 版本的 osd，該物件就被標記為 unfoud object。

通過上述分析可知，unfoud object 就是完成了peering 過程，但在 recovery 過程中找不到該物件正確版本所在的osd，無法恢復。

場景1

一個pg，兩副本，其acting set 為 [osd1，osd2]
此時pg處於recovery狀態，osd1上有 缺失的物件 （missing object），等待恢復。 osd2 上有完整的物件，正常情況下從osd2上同步osd1上缺失的物件即可。 這時候osd2 down掉後。 pg 重新開始peering，acting set 為[osd1,osd3],
osd1儲存了權威的日誌記錄，peering可以完成。在恢復階段，osd1上有缺失的物件無法恢復， 這些缺失的物件就處於 unfound object狀態。

這種情況發生的實質就是： pg只有兩副本，在rocovery 狀態中，只有osd2是一個完整的副本。如果唯一一個擁有完整副本的osd2 也down 了， 必然出現unfoud 物件。

場景2
當有request被阻塞時， 剔除以osd。

pool 的size 為3 ， min_size 為2 。給叢集新增負載，使叢集會出現 “requests are blocked > 32 sec” 的提示。 此時剔除一個盤，其方法如下：
移除節點操作如下：
ceph osd out osd.id
service ceph osd.1 stop
ceph osd crush remove osd.id 和host
ceph rm osd.id
ceph auth del osd.id

分析如下：

pg 的acting set 為 [osd1, osd2, osd3]，當執行 ceph osd out osd.1時：
該pg上物件objA：

 osd1     objA(22) objA(23)   已完成
 osd2     objA(22) objA(23)   正在完成
 osd3     objA(22) objA(23    正在完成

此時，osd1完成的物件objA 的版本22 和 23 的操作。而副本osd2和osd3 的物件objA的 22 和 23 操作都沒有完成。

osd1被標記為out後，osd2 和 osd3 首先都收到了 monitor傳送來的 osdmap的變化。 pg的 acting set 變為[osd2, osd3, osd4], pg開始觸發peering，在peering的過程中能夠從osd1上獲取pg log（由於osd標記為out，可以繼續訪問到）， 確定物件ojbA的版本為23.

當recovery 時， osd1 被停止，物件objA的23版本資料無法讀出，就標記為unfound object。

從上可知，objA的23版本只在以 osd1上存在一個唯一副本。它參與了peering 過程，從而獲取了該物件的權威版本，但是隨時把該osd down後，就無法獲取資料導致。

有以上原因分析可知：
1）當管理員縮容時，建議標記為osd out後，等待ceph叢集處於clean 狀態，確定請求沒有被阻塞時，才能停止osd

2）當有 request are blocked 的情況下，osd失效導致產生 unfound object。 在這種情況，正如情況2 中的例子，無論是版本22，或者23，資料都沒有應答給客戶端。所以最終結果是版本22或者23或者最後一次寫入成功的版本都可以接受。