ChubaoFS：一个面向大规模容器平台的分布式文件系统
目錄
1、簡介
2、設(shè)計與實施
3、設(shè)計選擇討論
4、價值評估
5、相關(guān)工作
6、結(jié)論和期望工作
CFS: A Distributed File System for Large Scale?Container Platforms
CFS：一個面向大規(guī)模容器平臺的分布式文件系統(tǒng)
?
摘要
我們提出了一個面向大規(guī)模容器平臺的分布式文件系統(tǒng) CFS。CFS 支持順序和隨機文件訪問，對大文件和小文件都進行了優(yōu)化存儲，并針對不同的寫入場景采用不同的復(fù)制協(xié)議，以提高復(fù)制性能。它采用元數(shù)據(jù)子系統(tǒng)，根據(jù)內(nèi)存使用情況在不同的存儲節(jié)點上存儲和分發(fā)文件的元數(shù)據(jù)。這種元數(shù)據(jù)放置策略避免了在容量擴展期間重新平衡數(shù)據(jù)的需求。CFS 還為 POSIX 兼容的?API?提供了寬松的語義和元數(shù)據(jù)原子性，以提高系統(tǒng)性能。我們與?Ceph 進行了全面的比較，Ceph 是在容器平臺上廣泛使用的分布式文件系統(tǒng)。實驗結(jié)果表明，在測試?7?種常用的元數(shù)據(jù)操作時，CFS 的性能平均提高了?3?倍左右。此外，CFS?在具有多個客戶端和進程的高度并發(fā)環(huán)境中表現(xiàn)出更好的隨機讀/寫性能。
?
?
1、簡介
在過去的幾年里，容器化和微服務(wù)已經(jīng)徹底改變了云環(huán)境和架構(gòu)[1,3,17]。隨著應(yīng)用程序可以通過連續(xù)交付（through continuous delivery）更快地構(gòu)建、部署和管理，越來越多的公司開始將遺留應(yīng)用程序和核心業(yè)務(wù)功能轉(zhuǎn)移到容器環(huán)境中。
運行在每組容器上的微服務(wù)通常獨立于本地磁盤存儲。雖然將計算與存儲分離允許公司以更有效的方式擴展容器資源，但這也帶來了對單獨存儲的需求。因為：（1）容器可能需要保存應(yīng)用程序數(shù)據(jù)，即使在它們關(guān)閉之后。（2）同一文件可能需要由不同的容器同時訪問。（3）存儲資源可能需要由不同的服務(wù)和應(yīng)用程序共享。如果沒有持久化數(shù)據(jù)的能力，容器在許多工作負(fù)載中的使用可能有限，尤其是在有狀態(tài)的應(yīng)用程序中。
一種選擇是通過容器存儲接口（Container Storage Interface，CSI）將現(xiàn)有的分布式文件系統(tǒng)帶到云本地環(huán)境中，該接口已被?Kubernetes[5] 和?Mesos[13] 等各種容器協(xié)調(diào)器支持，或者通過一些存儲協(xié)調(diào)器（如Rook2）支持。在尋找這樣一個分布式文件系統(tǒng)時，擁有運行在 JD 容器平臺上的應(yīng)用程序和服務(wù)的工程團隊提供了很多有價值的反饋。然而，在性能和可擴展性方面，這些反饋也讓我們很難直接采用任何現(xiàn)有的開源解決方案。
例如，為了降低存儲成本，通常需要從?同一個共享存儲基礎(chǔ)架構(gòu)?中為不同的應(yīng)用程序和服務(wù)提供服務(wù)。因此，組合工作負(fù)載中的文件大小可以從幾千字節(jié)到幾百GB不等，并且可以按順序或隨機方式訪問這些文件。然而，許多分布式文件系統(tǒng)都針對大文件（如 HDFS[22] ）或小文件（如 Haystack[2] ）進行了優(yōu)化，但很少有系統(tǒng)同時針對大文件和小文件優(yōu)化了存儲[6,12,20,26]。此外，這些文件系統(tǒng)通常采用一刀切的復(fù)制協(xié)議，這可能無法為不同的寫入場景提供優(yōu)化的復(fù)制性能。
此外，大量?Client 可能同時對文件進行大量訪問。大多數(shù)文件操作（如創(chuàng)建、追加或刪除文件）都需要更新文件元數(shù)據(jù)。因此，由于硬件限制，存儲所有文件元數(shù)據(jù)的單個節(jié)點很容易成為性能或存儲瓶頸[22，23]。通過使用一個單獨的集群來存儲元數(shù)據(jù)，可以解決這個問題，但是以這種方式的大多數(shù)現(xiàn)有工作[4]都需要在容量擴展期間重新平衡存儲節(jié)點，這可能會嚴(yán)重降低讀/寫性能。
最后，盡管擁有與 POSIX 兼容的文件系統(tǒng)接口可以大大簡化上層應(yīng)用程序的開發(fā)，但是?POSIX I/O 標(biāo)準(zhǔn)中定義的強一致性語義也會極大地影響性能。大多數(shù)與 POSIX 兼容的文件系統(tǒng)通過提供寬松的 POSIX 語義來緩解這個問題，但是同一文件的 inode（索引節(jié)點）和 dentry（目錄項）之間的原子性需求仍然會限制它們在元數(shù)據(jù)操作上的性能。
針對這些問題，本文提出了一種面向大規(guī)模容器平臺的分布式文件系統(tǒng) Chubao 文件系統(tǒng)（CFS）。CFS 是用 Go 編寫的，代碼在 https://github.com/ChubaoFS/cfs。一些關(guān)鍵功能包括：
- 通用高性能存儲引擎（General-Purpose and High Performance Storage Engine）。CFS 提供了一個通用存儲引擎，可以在不同的文件訪問模式下以優(yōu)化的性能高效地存儲大文件和小文件。它利用 Linux[21] 中的 punch hole 接口異步地釋放掉被刪除的小文件所占用的磁盤空間，這大大簡化了處理小文件刪除的工程工作。
- 場景感知復(fù)制（Scenario-Aware Replication）。與現(xiàn)有的任何開放源代碼解決方案在任何時候只允許一個復(fù)制協(xié)議[22,26,27]不同，CFS 采用了兩種基于不同寫場景的強一致性復(fù)制協(xié)議（即追加和覆蓋）來提高復(fù)制性能。
- 基于利用率的元數(shù)據(jù)分配（Utilization-Based Metadata Placement）。CFS 使用一個單獨的集群來根據(jù)內(nèi)存使用情況在不同的存儲節(jié)點上存儲和分發(fā)文件元數(shù)據(jù)。這種基于利用率的布局的一個優(yōu)點是，它不需要在容量擴展期間進行任何元數(shù)據(jù)重新平衡。盡管 MooseFS[23] 中也使用了類似的思想來選擇塊服務(wù)器，但據(jù)所知，CFS 是第一個將此技術(shù)應(yīng)用于元數(shù)據(jù)分配的開源解決方案。
- 寬松的 POSIX?語義和元數(shù)據(jù)原子性（Relaxed POSIX Semantics and Metadata Atomicity）。在與 POSIX 兼容的分布式文件系統(tǒng)中，在多個?Client 節(jié)點上服務(wù)多個進程的行為應(yīng)該與在具有直接連接存儲的單個節(jié)點上服務(wù)多個進程的本地文件系統(tǒng)的行為相同。CFS 提供了與 POSIX 兼容的?API。然而，POSIX 一致性語義，以及同一文件的 inode 和 dentry 之間的原子性要求，已經(jīng)被仔細(xì)放寬，以便更好地與應(yīng)用程序的需求保持一致，并提高系統(tǒng)性能。
?
?
2、設(shè)計與實施
如 圖 1 所示，CFS 由?一個元數(shù)據(jù)（metadata）子系統(tǒng)、一個數(shù)據(jù)子系統(tǒng)?和 一個資源管理器?組成，并且可以被不同的?Client 作為一組托管在容器上的應(yīng)用程序進程來訪問。
元數(shù)據(jù)子系統(tǒng)存儲文件元數(shù)據(jù)，由一組 meta 節(jié)點組成。每個元節(jié)點由一組元分區(qū)組成。數(shù)據(jù)子系統(tǒng)存儲文件內(nèi)容，由一組數(shù)據(jù)節(jié)點組成。每個數(shù)據(jù)節(jié)點由一組數(shù)據(jù)分區(qū)組成。我們將在下面幾節(jié)中詳細(xì)介紹這兩個子系統(tǒng)。
volume 是 CFS 中的一個邏輯概念，由一組元分區(qū)和數(shù)據(jù)分區(qū)組成。每個分區(qū)只能分配給一個 volume。從?Client 的角度來看，volume 可以被視為包含容器可訪問的數(shù)據(jù)的文件系統(tǒng)實例。一個 volume 可以裝載到多個容器上，這樣文件就可以在不同的?Client 之間同時共享。volume?需要在任何文件操作開始之前創(chuàng)建。
資源管理器 通過處理不同類型的任務(wù)（?例如創(chuàng)建和刪除分區(qū)、創(chuàng)建新 volume 以及添加/刪除節(jié)點?）來管理文件系統(tǒng)。它還跟蹤狀態(tài)，比如內(nèi)存和磁盤利用率，以及集群中的元數(shù)據(jù)節(jié)點和數(shù)據(jù)節(jié)點的活躍度。資源管理器有多個副本，其中的強一致性由一致算法（?如Raft[16]?）維護，并持久化到鍵值存儲（?如rocksdb?）進行備份和恢復(fù)。
?
?
2.1 元數(shù)據(jù)存儲
元數(shù)據(jù)子系統(tǒng)可以看作是文件元數(shù)據(jù)在內(nèi)存中的分布式數(shù)據(jù)存儲。
2.1.1 內(nèi)部結(jié)構(gòu)
元數(shù)據(jù)子系統(tǒng)由一組?meta?節(jié)點組成，每個?meta?節(jié)點可以有數(shù)百個元分區(qū)。每個元分區(qū)在內(nèi)存中存儲同一個?volume?的文件的 inode 和 dentry，并使用兩個名為 inodeTree 和 dentryTree 的?B?樹來快速查找。inodeTree 按 inode id 索引，dentryTree 按父 inode id 和 dentry 名稱編制索引。
下面的代碼片段顯示了 CFS 中的元分區(qū)、inode 和 dentry?的定義。
type metaPartition struct {config ? *MetaPartitionConfig;size ? uint64;dentryTree ?*BTree // btree for dentries;inodeTree ? *BTree. // btree for inodes;raftPartition raftstore.Partition;freeList ? *freeList // free inode list;vol ? *Vol;... // other fields } type inode struct {inode ? uint64 // inode idtype ? uint32 // inode typelinkTarget []byte // symLink target namenLink ? uint32 // number of linksflag ? uint32... // other fields } type dentry struct {parentId uint64 // parent inode idname ? string // name of the dentryinode ? uint64 // current inode idtype ? uint32 // dentry type }?
2.1.2?基于 Raft 的復(fù)制
文件寫入期間的復(fù)制是按照元分區(qū)執(zhí)行的。副本之間的強一致性由 Raft 共識協(xié)議[16]的修訂版?MultiRaft?來保證，與原始版本相比，該協(xié)議的優(yōu)點是減少了網(wǎng)絡(luò)上的心跳流量。
?
2.1.3 故障恢復(fù)
在內(nèi)存中被緩存的元分區(qū)通過快照和日志保存到本地磁盤上，用于備份和恢復(fù)。一些技術(shù)，如日志壓縮被用來減少日志文件的大小和縮短恢復(fù)時間。
值得注意的是，在元數(shù)據(jù)操作期間發(fā)生的故障可能會導(dǎo)致一個孤立的 inode，而該 inode 沒有與 dentry 關(guān)聯(lián)。這個 inode 占用的內(nèi)存和磁盤空間很難釋放。為了將這種情況發(fā)生的可能性降到最低，客戶端總是在失敗后發(fā)出重試，直到請求成功或達到最大重試限制。
?
?
2.2 數(shù)據(jù)存儲
數(shù)據(jù)子系統(tǒng)針對大文件和小文件的存儲進行了優(yōu)化，這些文件可以按順序或隨機方式訪問。
2.2.1?內(nèi)部結(jié)構(gòu)
數(shù)據(jù)子系統(tǒng)由一組數(shù)據(jù)節(jié)點組成，每個數(shù)據(jù)節(jié)點都有一組數(shù)據(jù)分區(qū)。每個數(shù)據(jù)分區(qū)會存儲一組分區(qū)的元數(shù)據(jù)，例如分區(qū) id 和副本地址。它還有一個稱為 extent store 的存儲引擎（參見圖2），它由一組稱為 extense 的存儲單元構(gòu)成。每個區(qū)段的 CRC 緩存在內(nèi)存中，以加快數(shù)據(jù)完整性的檢查。下面的代碼片段顯示了 CFS 中數(shù)據(jù)分區(qū)的結(jié)構(gòu)。
type dataPartition struct {clusterID ? string;volumeID ? string;partitionID ? uint64;partitionStatus int;partitionSize int;replicas ? []string;? // replica addressesdisk ? *Disk;isLeader ? bool;isRaftLeader ? bool;path ? string;extentStore ? *storage.ExtentStore;raftPartition raftstore.Partition;... // other fields }大文件和小文件的存儲方式不同，用閾值 t（默認(rèn)為128kb）來判斷是否應(yīng)該將文件視為?"小文件"，即大小小于或等于閾值的文件將被視為?"小文件"。t 的值在啟動時是可配置的，并且在數(shù)據(jù)傳輸過程中通常與數(shù)據(jù)包大小一致，以避免分組組裝或拆分。
?
2.2.2?大文件存儲
對于大文件，內(nèi)容存儲為一個或多個塊的序列，這些塊可以分布在不同數(shù)據(jù)節(jié)點上的不同數(shù)據(jù)分區(qū)上。將新文件寫入數(shù)據(jù)塊存儲區(qū)時，數(shù)據(jù)總是以新數(shù)據(jù)塊的零偏移量寫入，這樣就不需要在數(shù)據(jù)塊內(nèi)進行偏移量。文件的最后一個盤區(qū)不需要通過填充來填充其大小限制，并且從不存儲來自其他文件的數(shù)據(jù)。
?
2.2.3?小文件存儲
將多個小文件的內(nèi)容聚合并存儲在單個塊中，塊中每個文件內(nèi)容的物理偏移量記錄在相應(yīng)的塊的元數(shù)據(jù)中。CFS 依賴?fallocate()?來異步釋放被刪除文件所占用的磁盤空間。這種設(shè)計的優(yōu)點是不需要實現(xiàn)垃圾收集機制，因此避免在塊[2]中使用從邏輯偏移量到物理偏移量的映射。注意，這與刪除大文件不同，在刪除大文件時，可以直接從磁盤中刪除文件的區(qū)段。
?
2.2.4?場景感知復(fù)制
雖然可以簡單地使用基于 Raft 的復(fù)制來保證強一致性，但 CFS 在數(shù)據(jù)子系統(tǒng)中采用了兩種復(fù)制協(xié)議，以在性能和代碼重用性上取得更好的折衷。
在文件寫入期間，復(fù)制是按分區(qū)執(zhí)行的。根據(jù)文件寫入模式，CFS 采用不同的強一致性復(fù)制策略。具體來說，對于順序?qū)懭?#xff08;即append），我們使用主備份復(fù)制[25,27]，對于覆蓋，我們使用基于MultiRaft的復(fù)制協(xié)議，類似于元數(shù)據(jù)子系統(tǒng)中使用的協(xié)議。
一個原因是主備份復(fù)制不適合覆蓋，因為可能需要損害復(fù)制性能。具體地說，在覆蓋期間，將至少創(chuàng)建一個新的擴展數(shù)據(jù)塊來存儲新的文件內(nèi)容，并且一些原始擴展數(shù)據(jù)塊將邏輯地拆分為多個碎片，這些碎片通常像鏈接列表一樣鏈接在一起。在此鏈接列表中，指向原始碎片的指針將替換為與新創(chuàng)建的盤區(qū)關(guān)聯(lián)的指針。隨著越來越多的文件內(nèi)容被覆蓋，最終數(shù)據(jù)分區(qū)上會有太多需要碎片整理的碎片，這可能會嚴(yán)重影響復(fù)制性能。
另一個原因是，眾所周知，基于 MultiRaft 的復(fù)制存在寫放大問題，因為它引入了寫入日志文件的額外 IO，這可能會直接影響讀寫性能。但是，由于我們的應(yīng)用程序和微服務(wù)的覆蓋操作的需求比順序?qū)懭氩僮鞯男枨笊俚亩?#xff0c;所以這個性能問題是可以容忍的。
?
2.2.5?故障恢復(fù)
由于存在兩種不同的復(fù)制協(xié)議，當(dāng)發(fā)現(xiàn)副本上的故障時，我們首先通過檢查和調(diào)整所有數(shù)據(jù)塊來啟動主備份復(fù)制恢復(fù)過程。一旦處理完成，我們就可以在基于 MultiRaft 的復(fù)制中啟動恢復(fù)過程。
應(yīng)該注意的是，在順序?qū)懭肫陂g，只要不將過時數(shù)據(jù)返回給?Client ，就允許在分區(qū)上使用（存在）過時的數(shù)據(jù)。這是因為，在本例中，偏移量處的數(shù)據(jù)提交也表示偏移量之前的所有數(shù)據(jù)的提交。因此，我們可以使用偏移量來指示所有副本已提交的數(shù)據(jù)部分，Leader?總是將所有副本提交的最大偏移量返回給客戶端，然后客戶端在相應(yīng)的元節(jié)點上更新這個偏移量。當(dāng)?Client 請求讀取時，元節(jié)點只提供副本的地址以及所有副本已提交的數(shù)據(jù)的偏移量，而不管是否存在尚未完全提交的過時數(shù)據(jù)。
因此，不需要恢復(fù)副本上不一致的數(shù)據(jù)部分。如果?Client 發(fā)送了一個 k MB 文件的寫入請求，并且所有副本只提交了第一個p?MB，則該?Client 將對剩余的 k?p MB 數(shù)據(jù)重新發(fā)送一個寫請求到不同數(shù)據(jù)分區(qū)/節(jié)點中的數(shù)據(jù)塊。這種設(shè)計極大地簡化了當(dāng)文件按順序?qū)懭?CFS 時保持強復(fù)制一致性的實現(xiàn)。
?
?
2.3 資源管理器
資源管理器通過處理不同類型的任務(wù)來管理文件系統(tǒng)。
2.3.1?基于利用率的設(shè)置
一個重要的任務(wù)是在不同的節(jié)點之間分發(fā)文件元數(shù)據(jù)和內(nèi)容。在 CFS 中，我們采用了基于利用率的布局，其中文件元數(shù)據(jù)和內(nèi)容根據(jù)內(nèi)存/磁盤使用情況分布在存儲節(jié)點上。這大大簡化了分布式文件系統(tǒng)中的資源分配問題。
據(jù)我們所知，CFS 是第一個將這種思想用于元數(shù)據(jù)分配的開源解決方案。一些常用的元數(shù)據(jù)分配策略，如哈希和子樹分區(qū)[4]通常需要在添加服務(wù)器時移動不成比例的元數(shù)據(jù)。這種數(shù)據(jù)遷移在容器環(huán)境中可能是一個令人頭痛的問題，因為容量擴展通常需要在短時間內(nèi)完成。其他方法，如?lazyhybrid[4] 和 dynamicsubtree partition[28] 延遲移動數(shù)據(jù)或使用代理來隱藏數(shù)據(jù)遷移延遲。但這些解決方案也為未來的開發(fā)和維護帶來了額外的工程工作量。與這些方法不同，基于利用率的布局盡管簡單，但在容量擴展期間添加新的存儲節(jié)點時，不需要對數(shù)據(jù)進行任何重新平衡。此外，由于分布的均勻性，可以減少多個?Client 同時訪問同一存儲節(jié)點上的數(shù)據(jù)的機會，這有可能提高文件系統(tǒng)的性能穩(wěn)定性。具體而言，我們基于利用率的安置工作如下：
首先，在創(chuàng)建?volume 之后，?Client 向資源管理器請求一定數(shù)量的可用元數(shù)據(jù)和數(shù)據(jù)分區(qū)。這些分區(qū)通常位于內(nèi)存/磁盤利用率最低的節(jié)點上。但是，需要注意的是，在編寫文件時，?Client 只需選擇從資源管理器分配的元數(shù)據(jù)和數(shù)據(jù)分區(qū)中隨機抽取。客戶端不采用類似的基于利用率的方法的原因是為了避免與資源管理器的通信，以獲取每個分配節(jié)點的最新利用率信息。
其次，當(dāng)資源管理器發(fā)現(xiàn)一個 volume 中的所有分區(qū)即將滿時，它會自動向該 volume 添加一組新分區(qū)。這些分區(qū)通常位于內(nèi)存/磁盤利用率最低的節(jié)點上。請注意，當(dāng)分區(qū)已滿或達到閾值（即，元分區(qū)上的文件數(shù)或數(shù)據(jù)分區(qū)上的盤區(qū)數(shù)）時，此分區(qū)上不能存儲任何新數(shù)據(jù)，盡管它仍然可以修改或刪除。
?
2.3.2?元分區(qū)拆分
在分割元分區(qū)時，資源管理器還需要處理一個特殊的需求。特別是，如果一個元分區(qū)即將達到存儲?inode?和 dentry 數(shù)量的上限，則需要執(zhí)行拆分任務(wù)，以確保存儲在新創(chuàng)建分區(qū)中的 inode id 與存儲在原始分區(qū)中的 inode id 是唯一的。
我們解決方案的偽代碼在 算法1 中給出，資源管理器首先在上界端預(yù)先切斷元分區(qū)的 inode 范圍，一個大于目前使用的最大 inode id 的值（表示為 maxinodeid），然后向 meta 節(jié)點發(fā)送一個分割請求：（1）將 inode id 范圍從 1 到 end 更新為原始元分區(qū)，和（2）創(chuàng)建一個新的元分區(qū)，索引節(jié)點的范圍從 end+1 到??∞ 。因此，這兩個元分區(qū)的 inode 范圍分別為 [1，end] 和 [end+1，∞] 。如果需要創(chuàng)建另一個文件，那么它的 inode id 將在原始元分區(qū)中選擇為?maxInode?ID+1，或者在新創(chuàng)建的元分區(qū)中選擇為 end+1。通過資源管理器和元節(jié)點之間的周期性通信，可以得到每個元分區(qū)的最大值。
?
2.3.3?異常處理
當(dāng)對元數(shù)據(jù)/數(shù)據(jù)分區(qū)的請求超時時（例如，由于網(wǎng)絡(luò)中斷），其余副本被標(biāo)記為只讀。當(dāng)元數(shù)據(jù)/數(shù)據(jù)分區(qū)不再可用時（例如，由于硬件故障），該分區(qū)上的所有數(shù)據(jù)最終將被手動遷移到新分區(qū)。此不可用性由節(jié)點報告的多個故障來標(biāo)識。
?
?
2.4 Client
Client 已與?FUSE 集成，以在用戶空間中提供文件系統(tǒng)接口。Client 進程完全在自己緩存的用戶空間中運行。
為了減少與資源管理器的通信，Client 緩存分配給裝入?volume?的可用元數(shù)據(jù)和數(shù)據(jù)分區(qū)的地址，這些地址可以在啟動時獲得，并定期將這些可用分區(qū)與資源管理器同步。
為了減少與元節(jié)點的通信，Client 在創(chuàng)建新文件時還緩存返回的 inode 和 dentry，并在文件成功寫入數(shù)據(jù)節(jié)點后緩存數(shù)據(jù)分區(qū) id、盤區(qū) id 和偏移量。當(dāng)打開文件進行讀/寫操作時，客戶端將強制緩存元數(shù)據(jù)與元節(jié)點同步。
為了減少與數(shù)據(jù)節(jié)點的通信，Client 緩存最近識別的?Leader。我們的觀察結(jié)果是，在讀取文件時，客戶端可能不知道哪個數(shù)據(jù)節(jié)點是當(dāng)前的?Leader 節(jié)點，因為在故障恢復(fù)后，?Leader 可能會發(fā)生變化。因此，客戶端可能會嘗試逐個向每個副本發(fā)送讀請求，直到找到一個Leader。但是，由于?Leader?不經(jīng)常更改，通過緩存最后一個標(biāo)識的?Leader，在大多數(shù)情況下，客戶端可以最小化重試次數(shù)。
?
?
2.5 優(yōu)化
部署在 JD 的 CFS 集群主要有兩種優(yōu)化方式，解釋如下：
2.5.1?盡量減少心跳。因為我們的生產(chǎn)環(huán)境可能會有大量的分區(qū)分布在不同的元數(shù)據(jù)和數(shù)據(jù)節(jié)點上，即使使用基于?MultiRaft?的協(xié)議，每個節(jié)點仍然可以從同一 Raft 組中的其他節(jié)點獲得大量心跳，從而導(dǎo)致嚴(yán)重的通信開銷。為了緩解這種情況，我們在節(jié)點上增加了一層稱為 Raft set 的抽象層，以進一步減少 Raft 組之間要交換的心跳次數(shù)。具體來說，我們把所有的將節(jié)點分為若干個 Raft 組，每個 Raft 組維護自己的 Raft 組。在創(chuàng)建新分區(qū)時，我們更喜歡從同一個 Raft 集中選擇副本。這樣，每個節(jié)點只需與同一個 Raft 集中的節(jié)點交換心跳。
2.5.2?非持久性連接。可能有成千上萬的?Client 訪問同一個 CFS 集群，如果它們的所有連接都保持活動狀態(tài)，這可能會導(dǎo)致資源管理器過載。為了防止這種情況發(fā)生，我們在每個?Client 和資源管理器之間使用非持久性連接。
?
?
2.6 元數(shù)據(jù)操作
在大多數(shù)現(xiàn)代 POSIX 兼容的分布式文件系統(tǒng)中[26]，文件的 inode 和 dentry 通常駐留在同一個存儲節(jié)點上，以保持目錄的局部性。但是，由于基于利用率的元數(shù)據(jù)放置，在 CFS 中，同一文件的 inode 和 dentry 可能分布在不同的元數(shù)據(jù)節(jié)點上。因此，操作一個文件的 inode 和 dentry 通常需要作為分布式事務(wù)運行，這帶來了可能會顯著影響系統(tǒng)性能的開銷。
我們的權(quán)衡是，只要 dentry 總是與至少一個 inode 相關(guān)聯(lián)，就可以放寬這種原子性要求。CFS 中的所有元數(shù)據(jù)操作都基于此設(shè)計原則。缺點是有可能創(chuàng)建孤立的?inodes，并且很難從內(nèi)存中釋放出來。為了緩解這個問題，CFS 中的每個元數(shù)據(jù)操作工作流都經(jīng)過了精心設(shè)計，以盡量減少出現(xiàn)孤立的 inode?的機會。實際上，元節(jié)點在內(nèi)存中很少有很多的孤立?inode?。但是如果發(fā)生這種情況，管理員可以使用?fsck?等工具修復(fù)文件。
圖3 演示了三個常見元數(shù)據(jù)操作的工作流，可以解釋如下：
?
2.6.1?創(chuàng)建
創(chuàng)建文件時，客戶端首先請求可用的元節(jié)點創(chuàng)建?inode。元節(jié)點為新創(chuàng)建的 inode?獲取迄今為止在這個分區(qū)中尚未使用的最小 inode id，并相應(yīng)地更新其最大的?inode id。只有成功創(chuàng)建?inode?后，?Client 才能請求創(chuàng)建相應(yīng)的?dentry。如果發(fā)生故障，客戶端將發(fā)送一個?unlink?請求，并將新創(chuàng)建的?inode?放入本地孤立的?inode?列表中，當(dāng)?meta?節(jié)點收到來自客戶端的刪除請求時，這些?inode?將被刪除。注意?inode?和同一個文件的?dentry?不需要存儲在同一個元節(jié)點上。
?
2.6.2?連接
當(dāng)鏈接一個文件時，?Client 首先要求?inode?的?meta?節(jié)點將?nlink?的值（關(guān)聯(lián)的鏈接數(shù)）增加1，然后請求目標(biāo)父?inode?的?meta?節(jié)點在同一個元分區(qū)上創(chuàng)建?dentry。如果創(chuàng)建?dentry?時發(fā)生故障，nlink?的值將減少1。
?
2.6.3?取消鏈接
當(dāng)取消文件鏈接時，客戶端首先請求相應(yīng)的元節(jié)點刪除?dentry。只有當(dāng)這個操作成功時，客戶端才會向?meta?節(jié)點發(fā)送一個?unlink?請求，以將目標(biāo)?inode?中?nlink?的值減少一個。當(dāng)達到某個閾值（文件為0，目錄為2）時，客戶端將此?inode?放入本地孤立?inode?列表中，當(dāng)?meta?節(jié)點收到來自客戶端的逐出請求時，該列表將被刪除。請注意，如果降低?nlink?的值失敗，客戶端將執(zhí)行多次重試。如果所有重試失敗，這個?inode?最終將成為孤立的 inode，管理員可能需要手動解決該問題。
?
?
2.7 文件操作
CFS?放寬了?POSIX?一致性語義，也就是說，它沒有提供強大的一致性保證，而是只確保文件/目錄操作的順序一致性，沒有任何租賃機制來防止多個客戶端寫入同一個文件/目錄。如果需要，它依賴于上層應(yīng)用程序來維護更嚴(yán)格的一致性級別。
2.7.1?順序?qū)懭?/span>
如 圖 4 所示，為了按順序?qū)懭胛募?#xff0c;Client 首先從?緩存?中隨機選擇可用的數(shù)據(jù)分區(qū)，然后連續(xù)地將若干固定大小的數(shù)據(jù)包（例如，128 KB）發(fā)送給?Leader，每個數(shù)據(jù)包包括副本的地址、目標(biāo)盤區(qū) id、盤區(qū)中的偏移量和文件內(nèi)容。副本的地址由資源管理器以數(shù)組的形式提供，并緩存在客戶端。此數(shù)組中項目的索引指示復(fù)制的順序，即索引 0 處的地址為?Leader 的副本。因此，?Client 總是可以在不引入額外通信開銷的情況下向?Leader 發(fā)送寫請求，并且如前一節(jié)所述，將按照以下順序執(zhí)行主備份復(fù)制。一旦?Client 接收到來自?Leader 的提交，它將立即更新本地緩存，并定期或在收到來自上層應(yīng)用程序的系統(tǒng)調(diào)用?fsync()?時與?meta node?同步。
?
2.7.2?隨機寫入
CFS 中的隨機寫入已就緒。為了隨機寫入一個文件，客戶端首先使用原始數(shù)據(jù)和新數(shù)據(jù)的偏移量來計算要附加的數(shù)據(jù)部分和要覆蓋的部分?jǐn)?shù)據(jù)，然后分別處理它們。在前一種情況下，?Client 按照前面所述順序?qū)懭胛募Ｔ诤笠环N情況下，如 圖 5 所示，文件在數(shù)據(jù)分區(qū)上的偏移量沒有改變。
?
2.7.3?刪除
刪除操作是異步的。要刪除文件，?Client 向相應(yīng)的元節(jié)點發(fā)送刪除請求。meta?節(jié)點一旦接收到這個請求，就會更新目標(biāo)?inode?中?nlink?的值。如果這個值達到某個閾值（文件為0，目錄為2），目標(biāo)?inode?將被標(biāo)記為已刪除（請參閱第 2.1 節(jié)中給出的?inode?結(jié)構(gòu)）。稍后，將有一個單獨的進程來清除這個?inode?并與數(shù)據(jù)節(jié)點通信以刪除文件內(nèi)容。
?
2.7.4?讀
讀取只能在?Raft?上進行（請注意，主備分組和 Raft 組可能不同）。要讀取文件，?Client 向相應(yīng)的數(shù)據(jù)節(jié)點發(fā)送讀取請求。這個請求是由?Client 緩存中的數(shù)據(jù)構(gòu)造的，如數(shù)據(jù)分區(qū) id、盤區(qū) id、盤區(qū)偏移量等。
?
?
3、設(shè)計選擇討論
在本節(jié)中，我們將重點介紹構(gòu)建 CFS 時所做的一些設(shè)計選擇。
?
3.1 集中與分散
集中和分散是分布式系統(tǒng)的兩種設(shè)計范式[7]。盡管前一個[10,22]相對容易實現(xiàn)，但單主機可能成為可伸縮性的瓶頸。相比之下，后一種方法通常更可靠，但實現(xiàn)起來也更復(fù)雜。
在設(shè)計 CFS 時，我們選擇集中而不是分散，主要是因為它的簡單性。然而，存儲所有文件元數(shù)據(jù)的單個資源管理器限制了元數(shù)據(jù)操作的可伸縮性，元數(shù)據(jù)操作可能占典型文件系統(tǒng)工作負(fù)載的一半[18]。因此，我們使用一個單獨的集群來存儲元數(shù)據(jù)，這大大提高了整個文件系統(tǒng)的可伸縮性。從這個角度來看，CFS 的設(shè)計可以最大限度地減少資源管理器的參與，從而減少成為瓶頸的機會。誠然，即使有了這些努力，資源管理器的可伸縮性仍然會受到內(nèi)存和磁盤空間的限制。但根據(jù)我們的經(jīng)驗，這從來不是一個問題。
?
?
3.2 單獨的 Meta 節(jié)點與數(shù)據(jù)節(jié)點上的元數(shù)據(jù)
在一些分布式文件系統(tǒng)中，文件元數(shù)據(jù)和內(nèi)容存儲在同一臺機器上[15,26]（不管數(shù)據(jù)還是元數(shù)據(jù)，最后在底層?filestore?層，都以對象文件的形式存儲）。在一些分布式文件系統(tǒng)中，元數(shù)據(jù)由專門的元數(shù)據(jù)服務(wù)器單獨管理[11,22]。
在 CFS 中，我們選擇使用一個單獨的?meta 節(jié)點，并在內(nèi)存中維護所有的文件元數(shù)據(jù)，以便快速訪問。因此，我們可以為?meta 節(jié)點選擇內(nèi)存密集型機器，為數(shù)據(jù)節(jié)點選擇磁盤密集型機器以提高成本效益。這種設(shè)計的另一個優(yōu)點是部署的靈活性。如果一臺機器同時有很大的內(nèi)存和磁盤空間，我們總是可以將?meta 節(jié)點和數(shù)據(jù)節(jié)點物理地部署在一起。
?
?
3.3 一致性模型和保證
在 CFS 中，存儲層和文件系統(tǒng)層有不同的一致性模型。
存儲引擎通過主備份或基于?Raft?的復(fù)制協(xié)議來保證副本之間的強一致性。這個設(shè)計決定是基于這樣的觀察：前者不適合覆蓋，因為復(fù)制性能需要受到損害；后者由于引入了寫入日志文件的額外 IO，因此存在寫放大問題。
盡管文件系統(tǒng)本身提供了與?POSIX?兼容的?API，但它有選擇性地放寬了?POSIX?一致性語義，以便更好地與應(yīng)用程序的需求保持一致，并提高系統(tǒng)性能。例如，POSIX?的語義定義了寫操作必須是強一致的，也就是說，在系統(tǒng)可以保證任何其他讀操作都能看到剛剛寫入的數(shù)據(jù)。雖然這可以很容易地在本地完成，但是由于與鎖爭用/同步相關(guān)操作的配合導(dǎo)致性能下降，在分布式文件系統(tǒng)上確保如此強的一致性是非常困難的。CFS 放寬了?POSIX?的一致性，當(dāng)不同的?Client 修改文件中不重疊的部分時，CFS 提供了一致性，但是如果兩個?Client 試圖修改文件的同一部分，它不提供任何一致性保證。這種設(shè)計是基于這樣一個事實：在一個容器化的環(huán)境中，有許多情況下，POSIX?語義的剛性并不是必須的，即應(yīng)用程序很少依賴文件系統(tǒng)來提供完全強致一性，并且兩個獨立的作業(yè)很少寫入多用戶系統(tǒng)上的公共共享文件。
?
?
4、價值評估
Ceph?是一個分布式文件系統(tǒng)，在容器平臺上得到了廣泛的應(yīng)用。在這一部分，我們進行了一組實驗，從各個方面比較了?CFS?和?Ceph。
?
4.1?實驗安裝
我們實驗所用機器的規(guī)格見 表1。對于?CFS，我們將?meta 節(jié)點和數(shù)據(jù)節(jié)點部署在同一個集群的?10 臺機器上，以及一個具有 3 個副本的單個資源管理器。每臺機器有 10 個元分區(qū)和 1500 個數(shù)據(jù)分區(qū)。對于?Ceph，我們有類似的設(shè)置，其中對象存儲設(shè)備（OSD）和元數(shù)據(jù)服務(wù)器（MDS）部署在 10 臺機器的同一個集群上。每臺機器有 16 個 OSD 過程和 1 個 MSD 過程。Ceph?版本是 12.2.11，存儲引擎配置為具有?TCP/IP?網(wǎng)絡(luò)堆棧的 bluestore。除非另有說明，CFS?和?Ceph?在下面的實驗中都使用默認(rèn)配置。
?
?
4.2?元數(shù)據(jù)操作
在評估元數(shù)據(jù)子系統(tǒng)的性能和可伸縮性時，我們從?mdtest?中重點對 7 個常用的元數(shù)據(jù)操作進行了測試。說明見 表2。請注意，TreeCreation?和?TreeRemoval?測試主要集中在樹結(jié)構(gòu)中作為非葉節(jié)點的操作目錄。
圖6 顯示了具有不同進程數(shù)的單?Client 環(huán)境中這些測試的?IOPS，圖7 描繪了多?Client 環(huán)境中同一組測試的?IOPS，其中每個?Client 運行 64 個進程。請注意，Y 軸使用對數(shù)刻度，以便更好地說明不同的測試結(jié)果。
可以看出，當(dāng)只有一個?Client 有一個進程時，Ceph?在 7 個測試中有 5 個優(yōu)于 CFS（除了?DirStat?和?TreeRemoval?測試），但隨著客戶端和進程數(shù)量的增加，CFS?開始迎頭趕上。當(dāng)它到達 8 個?Client （每個?Client 運行 64 個進程）時，CFS?在 7 個測試中有? 6? 個優(yōu)于?Ceph?（除了?TreeCreation?測試）。表3 給出了使用 8 個客戶端進行測試的詳細(xì)?IOPS，它顯示平均性能提高了大約? 3? 倍。從這個結(jié)果我們可以看出，隨著?Client 和進程數(shù)量的增加，CFS?中基于利用率的元數(shù)據(jù)分配帶來的性能優(yōu)勢可能會超過?Ceph?中基于目錄位置的元數(shù)據(jù)分配的優(yōu)勢。
從 DirStat、TreeCreation?和?TreeRemoval?的結(jié)果中有一些觀察結(jié)果，如下所述：
在?DirStat?測試中，CFS 在兩種情況下（即單?Client 和多?Client ）都比?Ceph?表現(xiàn)出更好的性能。這主要是因為它們以不同的方式處理?readdir?請求。在?Ceph?中，每個?readdir?請求后面都有一組?inodeGet?請求，用于從不同的?md?獲取當(dāng)前目錄中的所有?inode。MDINO?通常在將來的訪問中請求?MDINO。然而，在?CFS?中，為了減少通信開銷，這些?inodeGet?請求被?batchInodeGet?請求所代替，并且結(jié)果被緩存在客戶端，以便在不需要與同一組元節(jié)點進一步通信的情況下快速響應(yīng)連續(xù)的請求。在多?Client 情況下（參見圖7），性能的突然下降可能是由?CFS?中的?Client 緩存未命中引起的。
在?TreeCreation?測試中，Ceph?在單?Client 情況下的性能優(yōu)于?CFS。但隨著越來越多的客戶參與進來，他們之間的性能差距越來越大。這可能是由于這樣一個事實：當(dāng)只有少數(shù)?Client 時，目錄局部性提供的好處（如在同一 MDS 上重用緩存的 dentry 和 inode）使?Ceph?具有更好的性能。然而，隨著越來越多的?Client 參與進來，某些?MDS?的壓力越來越大，這就要求?Ceph?將同一目錄下的文件元數(shù)據(jù)動態(tài)地放入不同的?MDS?中，并將相應(yīng)的請求重定向到代理?MDSs[28]，這會增加額外的開銷，并縮小?Ceph?與?CFS?之間的差距。
在?TreeRemoval?試驗中，CFS?在這兩種情況下的性能都優(yōu)于?Ceph。與?DirStat?測試類似，CFS?處理?readdir?請求的方式可能是導(dǎo)致這些結(jié)果的原因之一。另外，由于同一目錄下的文件元數(shù)據(jù)通常存儲在一個 MDS 上，當(dāng)客戶端數(shù)量較少時，刪除文件元數(shù)據(jù)的請求可能需要在?Ceph?中排隊；隨著客戶端的增多，Ceph?中目錄局部性所帶來的潛在好處可能會降低，因為文件元數(shù)據(jù)可能已經(jīng)分布在不同的?MDS 中，這是因為在前面的測試中觸發(fā)的重新平衡。
?
?
4.3?大文件
對于大型文件操作，我們首先查看單個?Client 環(huán)境中進程數(shù)不同的結(jié)果，其中每個進程操作一個單獨的?40GB?文件。我們使用?fio?（帶直接IO模式）來生成各種類型的工作負(fù)載。在?CFS?和?Ceph?的兩種設(shè)置中，?Client 和服務(wù)器部署在不同的機器上。此外，為了獲得最佳性能，Ceph?中需要調(diào)整兩個參數(shù)，即?osd_op_num_shards?和?osd_op_num_threads_per_shard，它們控制隊列的數(shù)量和處理隊列的線程數(shù)。我們將它們分別設(shè)置為?6?和?4。進一步增加這些值中的任何一個都會由于高CPU壓力而導(dǎo)致寫入性能下降。
如 圖 8 所示，不同進程下的性能非常相似，除了隨機讀寫測試，當(dāng)進程數(shù)大于?16?時，CFS?具有更高的?IOPS。
這可能是由于以下原因。首先，Ceph?的每個?MDS?只在其內(nèi)存中緩存文件元數(shù)據(jù)的一部分。在隨機讀取的情況下，緩存未命中率會隨著進程數(shù)的增加而急劇增加，從而導(dǎo)致頻繁的磁盤 IO。相比之下，CFS?的每個?meta 節(jié)點都在內(nèi)存中緩存所有的文件元數(shù)據(jù)，以避免昂貴的磁盤 IO 次數(shù)。其次，CFS?中的覆蓋已經(jīng)就緒，不需要更新文件元數(shù)據(jù)。相反，Ceph?中的覆蓋通常需要遍歷多個隊列，只有在數(shù)據(jù)和元數(shù)據(jù)被持久化和同步之后，提交消息才能返回給客戶端。
接下來，我們研究?CFS?和?Ceph?如何在多?Client 環(huán)境中使用相同的測試集執(zhí)行。在這個實驗中，每個客戶端在隨機讀/寫測試中有?64?個進程，在順序讀/寫測試中有?16?個進程，其中每個進程操作一個單獨的?40GB 文件。Ceph?中的每個客戶端操作不同的文件目錄，每個目錄都綁定到特定的?MDS?上，以最大限度地提高并發(fā)性和提高性能穩(wěn)定性。如 圖9 所示，CFS?在隨機讀/寫測試中比?Ceph?具有顯著的性能優(yōu)勢，盡管它們在順序讀/寫測試中的性能非常相似。這些結(jié)果與之前的單客戶實驗結(jié)果一致，并可以用類似的方法解釋。
總而言之，在高并發(fā)環(huán)境中，CFS?在我們對大文件的隨機讀/寫測試中的性能優(yōu)于?Ceph。
?
?
4.4 小文件
在本節(jié)中，我們將研究在?CFS?和?Ceph?中操作大小從?1kb?到?128kb?的小文件的性能。與元數(shù)據(jù)測試類似，結(jié)果來自?mdtest。這個實驗?zāi)M了在操作產(chǎn)品圖像時的用例，這些圖像通常在創(chuàng)建后永遠不會被修改。在我們的?CFS?配置中，128kb?是設(shè)置的閾值，用于確定是否應(yīng)該在單個范圍內(nèi)聚合文件，即，我們是否應(yīng)該將其視為?"小文件"。在?Ceph?中，每個客戶端操作不同的文件目錄，每個目錄都綁定到特定的?MDS?上，以最大限度地提高并發(fā)性和提高性能穩(wěn)定性。從 圖10 中可以看出，CFS?在讀寫測試方面都優(yōu)于?Ceph。這是因為：
(1) CFS?將所有的文件元數(shù)據(jù)存儲在內(nèi)存中，以避免文件讀取過程中的磁盤IO。
(2) 在小文件寫入的情況下，CFS?客戶端不需要向資源管理器請求新的擴展數(shù)據(jù)塊，而是直接將寫請求發(fā)送到數(shù)據(jù)節(jié)點，這進一步降低了網(wǎng)絡(luò)開銷。
?
?
5、相關(guān)工作
GFS [10] 和它的開源實現(xiàn)?HDFS[22] 是為按順序訪問存儲大文件而設(shè)計的。它們都采用主從架構(gòu)[24]，其中單個主機存儲所有文件元數(shù)據(jù)。與 GFS 和 HDFS 不同，CFS 使用一個獨立的元數(shù)據(jù)子系統(tǒng)來為元數(shù)據(jù)存儲提供一個可擴展的解決方案，這樣資源管理器就不太可能成為瓶頸。
Haystack[2] 采用了日志結(jié)構(gòu)文件系統(tǒng)[19]來處理在大型社交網(wǎng)絡(luò)中分享照片所帶來的請求。關(guān)鍵是在訪問元數(shù)據(jù)時避免磁盤操作。CFS?采用了類似的思想，將文件元數(shù)據(jù)放入主內(nèi)存中。但是，與?Haystack?不同的是，文件內(nèi)容的實際物理偏移量而不是邏輯索引存儲在內(nèi)存中，刪除文件是通過底層文件系統(tǒng)提供的?punch hole?接口來實現(xiàn)的，而不是依賴?yán)占鞫ㄆ谶M行合并和壓縮，以提高磁盤的效率利用。此外，Haystack?在刪除文件時不能保證副本之間的強一致性，它需要定期執(zhí)行合并和壓縮以提高磁盤利用率，這可能是一個性能殺手。一些著作[9,29]提出了通過將相關(guān)文件和元數(shù)據(jù)智能地組合在一起來更有效地管理小文件和元數(shù)據(jù)。CFS 采用不同的設(shè)計原則來分離文件元數(shù)據(jù)和內(nèi)容的存儲。這樣，我們就可以更靈活、更具成本效益地部署元數(shù)據(jù)和數(shù)據(jù)節(jié)點。
Windows Azure Storage（WAS）[6]是一個云存儲系統(tǒng)，它為客戶端提供了強一致性和多租戶。與 CFS 不同，它構(gòu)建了一個額外的分區(qū)層來處理隨機寫入，然后將數(shù)據(jù)流傳輸?shù)捷^低級別。WS-EFS[20]是一種云存儲服務(wù)，提供可伸縮和彈性的文件存儲。我們無法評估?Azure?和?WS-EFS?與?CFS?的性能，因為它們不是開源的。
PolarFS[7] 是為阿里巴巴的數(shù)據(jù)庫服務(wù)設(shè)計的分布式文件系統(tǒng)，它利用輕量級網(wǎng)絡(luò)堆棧和 I/O 堆棧，利用 RDMA、NVMe 和 SPDK 等新興技術(shù)。OctopusFS[14] 是一個基于 HDFS 的分布式文件系統(tǒng)，具有自動化的數(shù)據(jù)驅(qū)動策略，用于跨集群的存儲層（如內(nèi)存、ssd、hdd 和遠程存儲）管理數(shù)據(jù)的放置和檢索。這些與我們的工作是有交集的，因為?CFS?也可以采用類似的技術(shù)來充分利用新興的硬件和存儲層次結(jié)構(gòu)。
有一些分布式文件系統(tǒng)已經(jīng)與?Kubernetes?集成[12,23,26]。Ceph[26]是一個 PB 規(guī)模的對象/文件存儲，通過采用偽隨機數(shù)據(jù)分布函數(shù)（CRUSH）將數(shù)據(jù)和元數(shù)據(jù)管理之間的分離最大化，該函數(shù)是為不可靠對象存儲設(shè)備（Object storage devices, OSDs）的異構(gòu)和動態(tài)集群而設(shè)計的。本文對?Ceph?進行了全面的比較。GlusterFS[12]是一個可擴展的分布式文件系統(tǒng)，它將來自多個服務(wù)器的磁盤存儲資源聚合到一個全局命名空間中。MooseFS[23]是一個容錯、高可用、兼容 POSIX 且可擴展的分布式文件系統(tǒng)。但是，與 HDFS 類似，它使用一個主節(jié)點來管理文件元數(shù)據(jù)。
MapR-fs 是一個與 POSIX 兼容的分布式文件系統(tǒng)，它提供可靠、高性能、可擴展和完整的讀/寫數(shù)據(jù)存儲。與?Ceph?類似，它以分布式方式存儲元數(shù)據(jù)，同時存儲數(shù)據(jù)本身。
?
?
6、結(jié)論和期望工作
本文介紹了為京東電子商務(wù)服務(wù)的分布式文件系統(tǒng)?CFS。CFS?有一些獨特的特性，它有別于其他開源解決方案。例如，它有一個通用存儲引擎，該引擎具有場景感知復(fù)制功能，以優(yōu)化性能適應(yīng)不同的文件訪問模式。此外，它使用一個單獨的集群以分布式方式存儲文件元數(shù)據(jù)，并采用簡單而高效的元數(shù)據(jù)放置策略。此外，它還為符合 POSIX 的?API?提供了寬松的 POSIX 語義和元數(shù)據(jù)原子性，以獲得更好的系統(tǒng)性能。
我們已經(jīng)通過遵循?POSIX?標(biāo)準(zhǔn)實現(xiàn)了大部分操作，并且正在積極處理其余的操作，如 xattr、fcntl、ioctl、mknod?和?readdirplus。未來，我們計劃利用?Linux?頁面緩存加速文件操作，改善文件鎖定機制和緩存一致性，并支持?RDMA?等新興硬件標(biāo)準(zhǔn)。我們還計劃在內(nèi)核空間開發(fā)自己的兼容?POSIX?的文件系統(tǒng)接口，以完全消除?FUSE?帶來的開銷。
?
?
原論文中的聲明：
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.
總結(jié)
以上是生活随笔為你收集整理的ChubaoFS：一个面向大规模容器平台的分布式文件系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C++ map 使用详解(含C++20新
- 下一篇： java信息管理系统总结_java实现科