一、概述

　　BlueFS是個小型文件系統，小體現在功能簡單，沒有實現Posix接口，不支持對文件的覆蓋寫操作只支持追加寫，沒有本地文件系統的樹形層次結構，只有扁平的目錄到文件的映射關系。和BlueStore一樣，BlueFS也依賴底層BlockDevice模塊，使用它來管理磁盤空間的分配釋放，將IO通過Libaio寫到裸盤。和BlueStore不一樣的是元數據的管理，BlueStore將元數據全權交給RocksDB，BlueFS存在的目的就是為了支持RocksDB，因此不能反過來依賴RocksDB，只能靠自己來解決元數據管理問題。

　　元數據主要包括3類，第一類是文件系統自身的元數據，例如Block大小、UUID、OSDUUID、版本號等，這部分數據通常保存在超級塊(Superblock)中，BlueFS也是這么做的。第二類是目錄文件的inode數據以及文件目錄間的層次關系，這部分內容通常以一定的結構持久化在磁盤，讀取文件時根據路徑(例如，/etc/ceph/ceph.conf)從根目錄開始一層一層查找到目標文件的inode數據在磁盤中的位置。BlueFS并沒有這么做，而是將對文件的所有操作都記錄到日志文件，掛載文件系統時Replay日志，以此來得到這部分元數據。也就是說，所有的元數據都會加載到內存。第三類是用于描述磁盤哪些地方空閑哪些地方被占用的磁盤元數據。BlueFS的文件元數據包含該文件對應的磁盤空間，通過Replay日志獲得所有文件的元數據后，就獲得了整塊磁盤的使用情況。

日志文件

BlueFS的一個重要概念是日志文件，所有操作都記錄到日志文件，掛載文件系統時先Replay日志，日志文件有兩個作用：首先，保證數據和元數據的一致性。普通文件的元數據保存在日志文件，通過Replay日志獲取普通文件的元數據。BlueFS只支持對文件的追加操作，不支持覆蓋寫操作，從而就沒有WAL操作的必要了。追加操作先將數據寫到磁盤，然后再更新元數據，即將日志文件落盤。如果在追加數據時掉電，元數據沒有更新，那么舊的元數據所描述的數據仍舊是正確的，不會出現數據和元數據不一致的問題。其次，通過Replay所有日志來獲取文件目錄的層級結構。BlueFS沒有像Ext2文件系統那樣在磁盤中持久化inode數據結構，只是在普通文件被修改時將對應的元數據作為日志項記錄到日志文件。另外，文件的元數據保存了，為文件分配的磁盤空間的信息。Allocator根據這部分信息來確定磁盤中哪些空間已分配哪些空間空閑，從而構建一文提到的樹形結構。因此，如果追加數據過程中主機掉電，來不及更新元數據，那么新分配的磁盤空間將被自動回收。

如何加載日志文件？
要加載日志文件，要先知道日志文件對應的磁盤空間，這部分信息記錄在日志文件的元數據，而日志文件的元數據存儲在Superblock超級塊。Superblock是一個地址被硬編碼的磁盤空間，起始位置為4K，長度為4k，掛載文件系統時首先加載這塊固定區域的內容。從這塊區域中讀取磁盤Block大小、版本號、UUID、OSDUUID以及日志文件的元數據。日志文件的元數據內部包括：

• 存儲日志文件內容的磁盤，BlueFS同時支持3塊不同的磁盤
• 日志文件內容所在磁盤空間的位置信息
• 文件修改時間、大小以及inode索引號，每個文件的索引號是唯一的，便于在內存中管理文件結構

根據日志元數據的前兩項內容，就能夠知道從哪塊磁盤的什么位置讀取日志文件了，然后調用Libaio接口去讀取文件即可。

Compact日志。
Inode索引號0和1，由BlueFS內部使用，并且都用于日志文件。正常情況下，日志文件只使用索引號1，只有在Compact日志時才使用臨時的索引號0。日志文件只支持Append操作，時間長了，日志文件會占用較大的磁盤空間，并且Replay日志時間也會變久。實際上，日志文件中有用的數據只有，目錄文件的元數據以及目錄和文件的對應關系。Compact日志的目是，提取這部分有用數據寫入到新磁盤空間，并丟掉原來的日志數據，減少日志文件大小，釋放磁盤空間。

Compact日志時先使用索引號0的新日志文件將有用數據寫入到磁盤的新位置，然后用新日志文件的元數據更新超級塊（除索引號外），將超級塊Flush到磁盤。從目前實現來看，修改超級塊是個危險系數很高的操作，一方面是因為超級塊的重要程度，如果超級塊數據出錯所有文件將都無法使用，另一方面似乎沒有對超級塊做數據保護，只提供CRC檢驗。不過，正常情況下極少修改超級塊的數據，寫磁盤時也會繞過本地緩存。

轉載于:https://www.cnblogs.com/chris-cp/p/8067439.html

總結

以上是生活随笔為你收集整理的Ceph BlueFS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。