Ceph物件儲存閘道器允許你通過Swift及S3 API訪問Ceph。他將這些API請求轉化為librados請求。Librados是一個非常出色的物件儲存（庫）但是它無法高效的列舉物件。物件儲存閘道器維護自有索引來提升列舉物件的響應效能並維護了其他的一些元資訊。
我們先來看看一個已存在的bucket

這個bucket的物件列表儲存在一個單獨的rados物件中。這個物件的名字是.dir.加上bucket id。索引物件儲存在一個名為.rgw.buckets.index的獨立儲存池中。所以本例中，mybucket的索引應該是.dir.default.14113.1。

找到bucket索引

# rados -p .rgw.buckets.index ls - | grep "default.14113.1"
.dir.default.14113.1

你可以看到從.rgw.buckets.index儲存池返回的索引物件。

檢視索引物件的內容

# rados -p rados -p .rgw.buckets.index get .dir.default.14113.1 indexfile
# wc -c indexfile
0 indexfile

物件0位元組，怎麼回事呢？祕密是：索引資訊實際上儲存在Ceph的鍵/值資料庫中。每個OSD都有一個本地leveldb鍵/值資料庫。因此索引物件實際上只是一個佔位符，Ceph通過它找到那個包含索引資訊的OSD鍵/值資料庫。

檢視鍵/值資料庫的內容
先來看看索引鍵

# rados -p .rgw.buckets.index listomapkeys 
.dir.default.14113.1myobject

所以索引建就是物件名（情理之中）

再來看看索引值

現在比較對頭了！本例中索引佔175位元組，從上面的十六進位制轉儲資訊可以看到一些資訊片段。如果你用上面的轉儲資訊與radosgw-admin輸出的物件元資訊對比，你就會知道索引中儲存的是什麼。

物件元資訊

我們可以確定索引包含如下資訊:

• name
• owner
• owner_display_name
• etag

• tag

  需要注意的是owner既是鍵也是值。我認為這樣做是在出現資料損壞時能通過掃描索引值來恢復索引鍵。
  owner_display_name在這裡是為了相容S3。顯然是一個讀寫妥協。
  etag（實體標籤）是物件的MD5值，也是為了相容S3。這有點得不償失，因為我可以肯定如果每次建立一個物件就要計算MD5，這將會損害寫效能。
  我懷疑radosgw-admin顯示的其他元資訊也包含在索引中（或者為空或者不可見）

找到鍵值資料庫
計算出包含索引物件的OSD

# ceph osd map .rgw.buckets.index .rgw.buckets.index .dir.default.14113.24

osdmap e60 pool '.rgw.buckets.index' (11) object '.dir.default.14113.24/.rgw.buckets.index' -> pg 11.e6c72a3f (11.3f) -> up ([3,5], p3) acting ([3,5], p3)

我們看到鍵值資料庫在OSD3及5上，其中3是主OSD（第一個）。
找到OSD3上的鍵值資料庫

可以看到osd.3在主機ceph-osd1上

這就是包含索引的鍵值資料庫leveldb