上週 Ceph cluster 掛掉，結果是某個 OSD 一直起不來。

在 /var/log/ceph/ceph-osd.X.log 裡面看到了以下錯誤訊息

ceph version 0.80.5 (38b73c67d375a2552d8ed67843c8a65c2c0feba6)
1: (FileStore::lfn_open(coll_t, ghobject_t const&, bool, std::tr1::shared_ptr<FDCache::FD>*, std::tr1::shared_ptr<CollectionIndex::Path>*, std::tr1::shared_ptr<CollectionIndex>*)+0x4e6) [0x888926]
2: (FileStore::_touch(coll_t, ghobject_t const&)+0x18b) [0x88effb]
3: (FileStore::_do_transaction(ObjectStore::Transaction&, unsigned long, int, ThreadPool::TPHandle*)+0x48f6) [0x899856]
4: (FileStore::_do_transactions(std::list<ObjectStore::Transaction*, std::allocator<ObjectStore::Transaction*> >&, unsigned long, ThreadPool::TPHandle*)+0x74) [0x89b204]
5: (JournalingObjectStore::journal_replay(unsigned long)+0x886) [0x8af6e6]
6: (FileStore::mount()+0x30c2) [0x883052]
7: (OSD::do_convertfs(ObjectStore*)+0x1a) [0x61a11a]
8: (main()+0x1d88) [0x602f98]
9: (__libc_start_main()+0xed) [0x7f70e698276d]
10: /usr/bin/ceph-osd() [0x607229]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

因為 Ceph 掛掉時，剛好正在 VM 上安裝一些東西原本以為是 VM 卡在要做 I/O 才當掉但是把所有 server 都重開了以後，發現問題依然沒有解決。

Google 一番之後，看到有人說，升級可以解決這個問題於是將 Ceph 從 Firefly upgrade 到 Giant，但是很遺憾的是依然沒有解決問題。

新增了一個 OSD 進去，天真的想說如果變成 1/4 的 OSD 掛掉，那是否可以讓 Ceph 繼續運作呢，結果還是失敗。

忽然想起了很久以前看到一篇文章，上面說 Ceph OSD 最好不要安裝在 raid 上因為 Ceph 本身已經有 fault tolerance 了，如果硬碟發生錯誤，則兩者的 fault tolerance 將會互相影響。

雖然我的 OSD 不是建立在 raid 上，但是是在 LVM 上於是，使用了 e2fsck 去檢查並修復，發現了兩個 block 壞了修復完之後，再重新啟動 OSD 然後…然後 OSD 終於歸隊拉!!!

結論

LVM 與 Raid 本身就有自己的錯誤檢查機制。這些機制會與 Ceph 本身的的容錯機制互相衝突。因為 Ceph OSD 最好還是一個 OSD 就一個硬碟。

Ceph OSD stuck in an existing executable needed to interrupt.

結論