董豪宇，陳 康

（清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系，北京 100084）

0 引言

傳統(tǒng)的文件系統(tǒng)，例如Ext4［1］，都實(shí)現(xiàn)在內(nèi)核態(tài)；但內(nèi)核態(tài)的編程需要具備內(nèi)核相關(guān)的知識(shí)，有很高的開(kāi)發(fā)門(mén)檻。內(nèi)核態(tài)程序的錯(cuò)誤常常會(huì)影響到整個(gè)操作系統(tǒng)穩(wěn)定運(yùn)行。如果程序使用到了內(nèi)核的內(nèi)部接口，整個(gè)程序會(huì)變得難以維護(hù)和移植。由于這些原因，將文件系統(tǒng)實(shí)現(xiàn)在用戶態(tài)成為了新的趨勢(shì)。分布式的文件系統(tǒng)，例如GlusterFS（Gluster File System）［2］、GFS（Google File System）［3］，由于涉及到復(fù)雜的容錯(cuò)策略和網(wǎng)絡(luò)通信，本身的邏輯很復(fù)雜，幾乎都實(shí)現(xiàn)在用戶態(tài)。本地文件系統(tǒng)添加某些功能（例如加密［4-5］，檢查點(diǎn)（checkpoint）設(shè)置優(yōu)化［6］等），也會(huì)優(yōu)先考慮使用FUSE（File system in USErspace）［7］搭建堆棧文件系統(tǒng)，將額外的功能實(shí)現(xiàn)在用戶態(tài)，而不是直接在內(nèi)核的文件系統(tǒng)上作改動(dòng)。許多出于研究目的搭建的文件系統(tǒng)［8-10］，也都通過(guò)FUSE 實(shí)現(xiàn)在了用戶態(tài)。

許多用戶態(tài)的文件系統(tǒng)，存儲(chǔ)過(guò)程基于本地的文件系統(tǒng)，在存儲(chǔ)的過(guò)程當(dāng)中，會(huì)發(fā)生用戶態(tài)與內(nèi)核態(tài)的切換。這種切換會(huì)引發(fā)系統(tǒng)調(diào)用、上下文切換、用戶態(tài)與內(nèi)核之間內(nèi)存的拷貝，這些過(guò)程為系統(tǒng)帶來(lái)了額外的軟件開(kāi)銷。

新一代的存儲(chǔ)硬件——NVMe（Non-Volatile Memory express）固態(tài)硬盤(pán)（Solid State Drive，SSD），能夠提供10 μs 以下的延遲和高達(dá)3 GB/s 的帶寬。硬件速度的提高，使得存儲(chǔ)系統(tǒng)的軟件開(kāi)銷成為了不可忽視的一部分［11］。如果將整個(gè)存儲(chǔ)過(guò)程遷移到用戶態(tài)，消除系統(tǒng)因?yàn)檫M(jìn)入內(nèi)核而產(chǎn)生的開(kāi)銷，整個(gè)系統(tǒng)的性能就可能得到改善。

出于這樣的目的，Intel 開(kāi)發(fā)了一套高性能的存儲(chǔ)性能開(kāi)發(fā) 套 件（Storage Performance Development Kit，SPDK）［12］。SPDK 誕生于2015年，目前學(xué)術(shù)界已經(jīng)有了一些基于SPDK 的研究［13-15］。由于繞過(guò)了內(nèi)核，并采用了輪詢的事件處理方式，相較于內(nèi)核驅(qū)動(dòng)，SPDK 的NVMe 驅(qū)動(dòng)能夠提供更低且更穩(wěn)定的延遲。在用戶態(tài)驅(qū)動(dòng)之上，SPDK還提供了具有不同語(yǔ)義的存儲(chǔ)服務(wù)，開(kāi)發(fā)者可以在此基礎(chǔ)上進(jìn)行存儲(chǔ)系統(tǒng)的開(kāi)發(fā)，而無(wú)需關(guān)注驅(qū)動(dòng)的實(shí)現(xiàn)細(xì)節(jié)。

在另外一個(gè)方面，隨著InfiniBand 等新硬件的成本下降［16］，以及RoCE（RDMA over Converged Ethernet）［17］技術(shù)的成熟，RDMA（Remote Direct Memory Access）技術(shù)逐漸在數(shù)據(jù)中心中普及，學(xué)術(shù)界也誕生了許多基于RDMA 構(gòu)建的系統(tǒng)［18-21］和相關(guān)的研究［22-24］。RDMA 技術(shù)允許機(jī)器在目標(biāo)機(jī)器CPU 不參與的情況下，遠(yuǎn)程地讀寫(xiě)目標(biāo)機(jī)器中的內(nèi)存。相較于傳統(tǒng)的TCP/IP 網(wǎng)絡(luò)棧，RDMA 技術(shù)不僅能提供更低的延遲和更高的帶寬［25］，還減少了CPU 的開(kāi)銷。由于RDMA 協(xié)議工作在用戶態(tài)，使用RDMA進(jìn)行數(shù)據(jù)傳輸，還能避免內(nèi)核-用戶態(tài)切換、內(nèi)存拷貝等過(guò)程帶來(lái)的開(kāi)銷。

當(dāng)前的用戶態(tài)文件系統(tǒng)，都依賴于本地文件系統(tǒng)進(jìn)行實(shí)際存儲(chǔ)。由于內(nèi)核-用戶態(tài)切換的開(kāi)銷，無(wú)法充分地利用NVMe SSD 的性能。另外一方面，多數(shù)文件系統(tǒng)為了實(shí)現(xiàn)較高的性能，默認(rèn)不保證數(shù)據(jù)實(shí)時(shí)保存到磁盤(pán)介質(zhì)上。本文希望設(shè)計(jì)一個(gè)純用戶態(tài)的網(wǎng)絡(luò)文件系統(tǒng)，減少存儲(chǔ)過(guò)程中的軟件開(kāi)銷，充分發(fā)揮NVMe SSD 的硬件性能，并提供同步語(yǔ)義，保證數(shù)據(jù)實(shí)時(shí)持久化。同時(shí)，利用RDMA進(jìn)行網(wǎng)絡(luò)通信，對(duì)外提供一個(gè)高吞吐和低延遲的文件系統(tǒng)服務(wù)。

本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)基于高速網(wǎng)絡(luò)與SSD的網(wǎng)絡(luò)文件系統(tǒng)——RUFS（Remote Userspace File System）。RUFS 遵循客戶端/服務(wù)器端架構(gòu)，采用RDMA 協(xié)議進(jìn)行通信。用戶可以利用客戶端提供的API，使用由服務(wù)器端提供的文件系統(tǒng)服務(wù)。服務(wù)器端是一個(gè)單機(jī)的文件系統(tǒng)，元數(shù)據(jù)管理基于鍵值存 儲(chǔ)RocksDB（Rocks DataBase），數(shù)據(jù)管理基于SPDK Blobstore，所有存儲(chǔ)過(guò)程都通過(guò)SPDK 提供的NVMe 驅(qū)動(dòng)運(yùn)行在用戶態(tài)。通常遵循POSIX（Portable Operating System Interface X）語(yǔ)義的文件系統(tǒng)，只能保證元數(shù)據(jù)操作的原子性。而RUFS 具備同步語(yǔ)義，能夠在遵循POSIX 語(yǔ)義基礎(chǔ)之上，保證已經(jīng)完成的數(shù)據(jù)和元數(shù)據(jù)操作，在服務(wù)器掉電之后不丟失，而無(wú)需使用fsync進(jìn)行持久化。

僅使用一塊SSD 作為數(shù)據(jù)盤(pán)，RUFS：在4KB 隨機(jī)訪問(wèn)上，讀、寫(xiě)操作就能獲得超過(guò)400 MB/s的性能，較默認(rèn)配置下NFS+ext4 的性能提升了202.2%和738.9%；對(duì)于4MB 順序訪問(wèn)，RUFS相較于NFS+ext4也有至少40%的性能提升。在元數(shù)據(jù)性能上，RUFS的文件夾創(chuàng)建性能，相較于NFS+ext4，有5 693.8%的性能提升，其他大部分元數(shù)據(jù)操作也有顯著的性能優(yōu)勢(shì)。

本文主要有三個(gè)方面的貢獻(xiàn)：第一，為如何在用戶態(tài)完成文件系統(tǒng)所有存儲(chǔ)過(guò)程給出了詳細(xì)的方案；第二，在此基礎(chǔ)上，實(shí)現(xiàn)了一個(gè)網(wǎng)絡(luò)文件系統(tǒng)原型RUFS，并報(bào)告了數(shù)據(jù)和元數(shù)據(jù)性能；第三，改進(jìn)了BlobFS 的緩存策略，使得工作在BlobFS 之上的鍵值存儲(chǔ)的讀性能有了非常明顯的提升，也間接提升了RUFS的元數(shù)據(jù)性能。

1 相關(guān)研究

1.1 基于鍵值存儲(chǔ)的文件系統(tǒng)元數(shù)據(jù)管理

鍵值存儲(chǔ)是一種NoSQL 存儲(chǔ)，一般基于LSM Tree（Log Structured Merged Tree）［26］構(gòu)建，提供有序鍵到任意長(zhǎng)度值的持久化存儲(chǔ)和查詢。通過(guò)將隨機(jī)寫(xiě)入轉(zhuǎn)化為順序?qū)懭?，這種鍵值存儲(chǔ)通常能夠取得更好的性能。

2013 年，Ren 等［8］提出了TableFS（Table File System）。TableFS 利用LevelDB（Level DataBase）［27］構(gòu)建了一個(gè)文件系統(tǒng)元數(shù)據(jù)模塊，以鍵值對(duì)的鍵描述父節(jié)點(diǎn)到子節(jié)點(diǎn)的關(guān)系，并將文件的元數(shù)據(jù)作為鍵值對(duì)的值存在LevelDB 中。在此基礎(chǔ)上，利用Ext4 作為對(duì)象存儲(chǔ)，為T(mén)ableFS 提供數(shù)據(jù)的存儲(chǔ)服務(wù)。為了減少對(duì)下層Ext4 的訪問(wèn)，TableFS 還將小于4 KB 的文件也放在了LevelDB當(dāng)中。

在此基礎(chǔ)上，2014年，Ren等［28］提出了TableFS的分布式版本——IndexFS（Index File System），并在此基礎(chǔ)上做了一些相關(guān)的工作［29-30］。2017年，Li等［31］提出了LocoFS（Loco File System）。LocoFS改進(jìn)了用鍵值存儲(chǔ)模擬目錄樹(shù)的方式，減少了元數(shù)據(jù)操作需要的網(wǎng)絡(luò)請(qǐng)求數(shù)量，提高了元數(shù)據(jù)操作的性能。

1.2 SPDK技術(shù)

存儲(chǔ)服務(wù)的性能由軟件與硬件共同決定。對(duì)于傳統(tǒng)存儲(chǔ)硬件（如機(jī)械硬盤(pán)），由于硬件性能較差，軟件上的開(kāi)銷只占整個(gè)存儲(chǔ)服務(wù)開(kāi)銷的一小部分。但隨著NVMe SSD 的出現(xiàn)，相當(dāng)一部分存儲(chǔ)硬件，例如Z-SSD、Optane SSD等，已經(jīng)能夠提供小于10 μs 的延遲和高達(dá)3 GB/s 的帶寬［11］。硬件性能的大幅提高，使得軟件棧的開(kāi)銷成為了整個(gè)存儲(chǔ)服務(wù)開(kāi)銷中不可忽視的一部分。

為了充分利用NVMe SSD的性能，減少存儲(chǔ)過(guò)程中的軟件開(kāi)銷，Intel開(kāi)發(fā)了SPDK。SPDK提供了一個(gè)純用戶態(tài)的NVMe驅(qū)動(dòng)，消除了內(nèi)核與系統(tǒng)中斷帶來(lái)的開(kāi)銷。SPDK提供的NVMe驅(qū)動(dòng)采用了無(wú)鎖的實(shí)現(xiàn)，支持多線程同時(shí)提交I/O請(qǐng)求。

根據(jù)SPDK 團(tuán)隊(duì)的論文［12］，對(duì)于NVMe SSD（實(shí)驗(yàn)所用的SSD 型號(hào)為Intel P3700，容量為800 GB）的4 KB 隨機(jī)訪問(wèn)。SPDK 的用戶態(tài)NVMe 驅(qū)動(dòng)，能用1 塊SSD 提供450 kIOPS（Input/output Operations Per Second）的訪問(wèn)性能，略高于Linux內(nèi)核中的NVMe 驅(qū)動(dòng)。得益于無(wú)鎖的實(shí)現(xiàn)方式，SPDK 提供的性能，能夠隨著SSD 的增多而線性增加，用8 塊SSD 提供約3 600 kIOPS 的訪問(wèn)性能。而增加SSD 數(shù)量，對(duì)內(nèi)核驅(qū)動(dòng)提供的性能沒(méi)有提高。在4 KB 隨機(jī)讀的延遲上，SPDK 能夠?qū)?nèi)核驅(qū)動(dòng)造成的軟件開(kāi)銷，降低約90%。

SPDK 為用戶提供了一套事件驅(qū)動(dòng)的編程框架。在這套框架中，每個(gè)線程相互獨(dú)立，通過(guò)消息傳遞的方式進(jìn)行線程間同步，線程間不共享任何資源。這種設(shè)計(jì)消除了資源共享帶來(lái)的數(shù)據(jù)競(jìng)爭(zhēng)，使框架具有良好的可擴(kuò)展性。這個(gè)編程框架定義了3個(gè)重要的概念，分別是reactor、event和poller。reactor是一個(gè)常駐的線程，持有一個(gè)無(wú)鎖的消息隊(duì)列；event 代表一個(gè)任務(wù)，可以通過(guò)reactor 的消息隊(duì)列在線程間傳遞；poller 與event 類似，也是一種任務(wù)，但需要注冊(cè)在一個(gè)reactor 上，reactor 會(huì)周期性地調(diào)用已注冊(cè)的poller。用戶可以使用poller在用戶態(tài)模擬系統(tǒng)中斷。

Blobstore和BlobFS（Blob File System）是SPDK提供的兩個(gè)存儲(chǔ)服務(wù)，前者提供對(duì)象（blob）存儲(chǔ)的語(yǔ)義，后者提供一個(gè)簡(jiǎn)易的文件系統(tǒng)，用戶可以在此基礎(chǔ)上搭建存儲(chǔ)應(yīng)用。Blobstore中最基礎(chǔ)的存儲(chǔ)單元被稱為page，每個(gè)page 4 KB大小。Blobstore可以保證每個(gè)page寫(xiě)入的原子性。根據(jù)用戶配置，Blobstore會(huì)將連續(xù)的多個(gè)page組織在一起（通常大小為1 MB），這一段連續(xù)的空間被稱為一個(gè)cluster，而blob則是一個(gè)cluster的鏈表。用戶可以在blob上進(jìn)行隨機(jī)、并發(fā)、無(wú)緩存的讀寫(xiě)，還可以將鍵值對(duì)以元數(shù)據(jù)的形式存儲(chǔ)在blob當(dāng)中，但元數(shù)據(jù)需要用戶自己手動(dòng)調(diào)用sync md（同步元數(shù)據(jù)）操作才能持久化。

BlobFS是在Blobstore的基礎(chǔ)上構(gòu)建的一個(gè)簡(jiǎn)易的文件系統(tǒng)。每個(gè)文件都對(duì)應(yīng)著B(niǎo)lobstore中的一個(gè)blob，文件的名字和長(zhǎng)度，都以鍵值對(duì)的形式存儲(chǔ)在blob的元數(shù)據(jù)當(dāng)中。BlobFS只能支持創(chuàng)建根目錄下的文件，不支持文件夾功能，不支持隨機(jī)位置的寫(xiě)入，只支持增量寫(xiě)。當(dāng)前BlobFS 已經(jīng)能夠作為鍵值存儲(chǔ)系統(tǒng)的存儲(chǔ)引擎，但由于不支持隨機(jī)位置的寫(xiě)入，仍然不適合用于管理文件數(shù)據(jù)。BlobFS當(dāng)中還實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的緩存模塊，可以為文件的順序讀和增量寫(xiě)帶來(lái)一定的性能提升。

1.3 基于RDMA的RPC技術(shù)

RDMA 是指一種允許處理器直接讀寫(xiě)遠(yuǎn)程計(jì)算機(jī)內(nèi)存的技術(shù)。相較于傳統(tǒng)網(wǎng)絡(luò)，RDMA 能夠提供極低的延時(shí)和很高的帶寬。最新商用的RDMA 網(wǎng)卡可以提供低至600 ns的延時(shí)和每端口高達(dá)200 Gb/s 的帶寬［25］。RDMA 編程一般使用verbs API，需要開(kāi)發(fā)者自己控制網(wǎng)絡(luò)連接、任務(wù)輪詢等細(xì)節(jié)，編程復(fù)雜度較高。

RPC（Remote Procedure Call）技術(shù)［32］，是一種允許本地機(jī)器透明地調(diào)用遠(yuǎn)端函數(shù)或者過(guò)程的技術(shù)。RPC技術(shù)向用戶隱藏了數(shù)據(jù)的發(fā)送、接收、序列化、反序列化等細(xì)節(jié)，大大降低了編程復(fù)雜度。Mercury 是面向超算領(lǐng)域的RPC 框架，于2013 年由Soumagne等［33］提出。Mercury包含了一個(gè)網(wǎng)絡(luò)抽象層，可以通過(guò)不同的通信插件，在不同網(wǎng)絡(luò)硬件下進(jìn)行數(shù)據(jù)傳輸。當(dāng)前，Mercury 采用了OFI（Open Fabric Interface）［34］作為支持RDMA傳輸?shù)耐ㄐ挪寮?。Mercury在常規(guī)的RPC接口之外，還提供了一組塊（bulk）傳輸接口。Bulk接口能夠充分利用RDMA單邊通信的性能，消除不必要的內(nèi)存拷貝。用戶可以把一塊內(nèi)存注冊(cè)為一個(gè)bulk，并將bulk句柄發(fā)送給其他機(jī)器，其他機(jī)器就能通過(guò)bulk句柄遠(yuǎn)程地讀寫(xiě)被注冊(cè)的內(nèi)存。在Mercury的基礎(chǔ)上，Intel正在開(kāi)發(fā)一套支持組通信的RPC 框架，CaRT（Collective and RPC Transport），作為其在新的存儲(chǔ)系統(tǒng)DAOS（Distributed Asynchronous Object Storage）［35-36］中的傳輸層。CaRT不僅支持傳統(tǒng)的點(diǎn)對(duì)點(diǎn)RPC通信，還能支持RPC的組播。

2 系統(tǒng)架構(gòu)與設(shè)計(jì)

本章主要介紹了RUFS 的設(shè)計(jì)與實(shí)現(xiàn)，包括元數(shù)據(jù)管理的策略、數(shù)據(jù)管理的策略、保證元數(shù)據(jù)與數(shù)據(jù)的一致性策略。

2.1 系統(tǒng)架構(gòu)

RUFS 是一個(gè)純用戶態(tài)的文件系統(tǒng)，采用客戶端/服務(wù)器端架構(gòu)，服務(wù)器端是一個(gè)單機(jī)系統(tǒng)，可以同時(shí)支持多個(gè)客戶端。服務(wù)器端與客戶端通過(guò)CaRT進(jìn)行通信。

RUFS客戶端為用戶提供了一套類POSIX語(yǔ)義的、并發(fā)安全的文件系統(tǒng)操作API（RUFS-API），支持的操作包括：access、mkdir、rmdir、stat、rename、opendir、readdir、closedir、open、creat、close、ftruncate、unlink、pread、pwrite、read、write，支持文件和文件夾操作。當(dāng)用戶調(diào)用客戶端API 時(shí)，客戶端會(huì)將請(qǐng)求通過(guò)RPC的形式發(fā)送到RUFS服務(wù)器端，并等待請(qǐng)求返回。

RUFS 服務(wù)器端實(shí)現(xiàn)了一個(gè)純用戶態(tài)文件系統(tǒng)（RUFSserver）。系統(tǒng)需要至少兩塊SSD才能工作，其中一塊用來(lái)建立BlobFS 實(shí)例，用來(lái)支持RocksDB［37］的數(shù)據(jù)存儲(chǔ)。RUFS 將利用RocksDB 對(duì)元數(shù)據(jù)進(jìn)行存儲(chǔ)和管理。剩下的每塊SSD 都會(huì)創(chuàng)建一個(gè)單獨(dú)的Blobstore 實(shí)例，用來(lái)存儲(chǔ)數(shù)據(jù)，其中的每個(gè)blob都包含著一個(gè)文件的數(shù)據(jù)。RUFS能利用多個(gè)SSD來(lái)提高服務(wù)器端的文件讀寫(xiě)的吞吐能力。在RUFS服務(wù)啟動(dòng)時(shí)，系統(tǒng)會(huì)為每一塊用于存儲(chǔ)數(shù)據(jù)的SSD 建立一個(gè)Blobstore 實(shí)例，同時(shí)，啟動(dòng)一定數(shù)量的reactor線程，負(fù)責(zé)處理讀寫(xiě)請(qǐng)求。reactor線程的數(shù)量可以自行配置，但不能超過(guò)Blobstore 的實(shí)例數(shù)量，每個(gè)Blobstore實(shí)例受一個(gè)固定的reactor線程的管理。

圖1 RUFS架構(gòu)Fig.1 RUFS architecture

2.2 元數(shù)據(jù)管理

2.2.1 基于鍵值存儲(chǔ)與Blobstore的元數(shù)據(jù)協(xié)同管理

文件系統(tǒng)的元數(shù)據(jù)通常組織為目錄樹(shù)。目錄樹(shù)的節(jié)點(diǎn)存儲(chǔ)了文件的元數(shù)據(jù)，每一個(gè)節(jié)點(diǎn)都有一個(gè)唯一的編號(hào)（inode number），目錄樹(shù)的邊代表目錄對(duì)下一級(jí)節(jié)點(diǎn)的包含關(guān)系。RUFS利用鍵值存儲(chǔ)模擬目錄樹(shù)，同樣模擬了目錄樹(shù)的節(jié)點(diǎn)和邊，并為每個(gè)節(jié)點(diǎn)賦予了一個(gè)唯一的UUID（Universally Unique IDentifier）。目錄樹(shù)的節(jié)點(diǎn)和邊用不同的鍵值對(duì)模擬，前者稱為N型（node）鍵值對(duì)，后者稱為E型（edge）鍵值對(duì)。兩者在鍵值存儲(chǔ)中，有不同的前綴，N 型鍵值對(duì)模擬節(jié)點(diǎn)，鍵由前綴、節(jié)點(diǎn)UUID 拼接而成，值包含了該節(jié)點(diǎn)的一部分元數(shù)據(jù)（記為Meta-N），E 型鍵值對(duì)模擬父節(jié)點(diǎn)到子節(jié)點(diǎn)的邊，鍵由前綴、父節(jié)點(diǎn)UUID、子節(jié)點(diǎn)文件名拼接而成，值中包含子節(jié)點(diǎn)UUID 和子節(jié)點(diǎn)的一部分元數(shù)據(jù)（記為Meta-E）?；阪I值存儲(chǔ)的鍵的有序性，擁有相同父節(jié)點(diǎn)的E 型鍵值對(duì)會(huì)聚合到一起，這方便了readdir 的實(shí)現(xiàn)。RUFS 可以將readdir 對(duì)子節(jié)點(diǎn)的遍歷，轉(zhuǎn)化為RocksDB對(duì)鍵值對(duì)的遍歷。

圖2 目錄樹(shù)與鍵值對(duì)的對(duì)應(yīng)關(guān)系Fig.2 Relationship between directory tree and key-value pairs

在RUFS 中，一個(gè)文件/文件夾的元數(shù)據(jù)包括：mode（其中包含了節(jié)點(diǎn)類型、權(quán)限信息）、gid、uid、atime、ctime、mtime。對(duì)于文件，還包括文件的長(zhǎng)度、文件對(duì)應(yīng)的blob的相關(guān)信息。許多元數(shù)據(jù)操作的接口，都是基于路徑名的（例如creat、rmdir等），系統(tǒng)需要從根節(jié)點(diǎn)開(kāi)始，通過(guò)文件名和E型鍵值對(duì)，順著目錄樹(shù)的樹(shù)邊逐層往下查找節(jié)點(diǎn)，直到找到路徑名對(duì)應(yīng)的節(jié)點(diǎn)，再做相應(yīng)的操作。在查找目標(biāo)節(jié)點(diǎn)的過(guò)程中，根據(jù)POSIX語(yǔ)義的要求，系統(tǒng)同時(shí)要判斷操作對(duì)節(jié)點(diǎn)是否有訪問(wèn)權(quán)限。這需要讀取節(jié)點(diǎn)元數(shù)據(jù)中的mode、gid 和uid。為了消除在權(quán)限判斷過(guò)程中，對(duì)N 型鍵值對(duì)的額外訪問(wèn)，RUFS 將mode、gid和uid 劃分到了E 型鍵值對(duì)中。圖3 展示了節(jié)點(diǎn)元數(shù)據(jù)是如何存儲(chǔ)在不同的鍵值對(duì)中的。

圖3 在鍵值對(duì)中存儲(chǔ)元數(shù)據(jù)的方式Fig.3 Method of storing metadata in key-value pairs

根據(jù)POSIX語(yǔ)義的要求，文件在被進(jìn)行讀寫(xiě)時(shí)，文件的時(shí)間戳需要被相應(yīng)地改變，文件的長(zhǎng)度也可能發(fā)生變化。如果要將這些改動(dòng)同步到RocksDB 當(dāng)中，當(dāng)系統(tǒng)需要同時(shí)處理大量的讀寫(xiě)請(qǐng)求時(shí)，RocksDB 的寫(xiě)入性能就會(huì)成為整個(gè)系統(tǒng)的瓶頸。因此，在RUFS 中，文件的長(zhǎng)度和時(shí)間戳還會(huì)存儲(chǔ)在對(duì)應(yīng)的blob 的元數(shù)據(jù)中。當(dāng)文件被讀寫(xiě)時(shí)，文件長(zhǎng)度和時(shí)間戳的變化只會(huì)存儲(chǔ)到blob的元數(shù)據(jù)中，當(dāng)文件被關(guān)閉時(shí)，長(zhǎng)度和時(shí)間戳才會(huì)被同步回RocksDB中。

2.2.2 元數(shù)據(jù)操作的原子性和并發(fā)安全性

某些元數(shù)據(jù)操作（例如rename）需要對(duì)目錄樹(shù)進(jìn)行多次改動(dòng)，為了保證操作的原子性，RUFS 中所有可能涉及目錄樹(shù)變化，或是在操作過(guò)程中默認(rèn)目錄樹(shù)不發(fā)生結(jié)構(gòu)變化的操作，都利用了RocksDB事務(wù)來(lái)保證元數(shù)據(jù)操作的原子性。

RUFS服務(wù)器端作為一個(gè)多線程的系統(tǒng)，能夠并發(fā)地更改目錄樹(shù)的結(jié)構(gòu)，如果不進(jìn)行并發(fā)控制，就會(huì)產(chǎn)生錯(cuò)誤。而單純使用RocksDB事務(wù)，無(wú)法避免這樣的錯(cuò)誤。圖4展示了一種出錯(cuò)的情況。在目錄樹(shù)為初始狀態(tài)時(shí)，系統(tǒng)同時(shí)收到了creat 操作和rmdir操作，由于RocksDB 事務(wù)只處理寫(xiě)-寫(xiě)操作的沖突，因此兩個(gè)元數(shù)據(jù)操作事務(wù)得以并發(fā)地執(zhí)行，并進(jìn)行了事務(wù)提交，結(jié)果造成了creat 操作創(chuàng)建了一個(gè)空懸的節(jié)點(diǎn)。為了解決這一問(wèn)題，RUFS 利用了RocksDB 事務(wù)中的get_for_update 操作。這一操作會(huì)促使RocksDB為目標(biāo)鍵值對(duì)加上一個(gè)讀寫(xiě)鎖，通過(guò)為目錄樹(shù)上的節(jié)點(diǎn)和邊上讀寫(xiě)鎖，就能避免元數(shù)據(jù)的并發(fā)操作破壞目錄樹(shù)結(jié)構(gòu)。在加鎖的順序上，RUFS總是遵循這樣的規(guī)則：對(duì)于兩個(gè)待加鎖的節(jié)點(diǎn)A 和B，若兩者在目錄樹(shù)中深度不同，那么RUFS會(huì)從較淺的節(jié)點(diǎn)到較深的節(jié)點(diǎn)加鎖。若兩者在目錄樹(shù)中的深度相同，RUFS會(huì)從UUID較小者到UUID較大者加鎖。RUFS通過(guò)有順序的加鎖，來(lái)避免死鎖問(wèn)題。

圖4 并發(fā)的元數(shù)據(jù)操作導(dǎo)致的錯(cuò)誤Fig.4 Error caused by concurrent metadata operations

2.3 數(shù)據(jù)管理

SPDK 提供3 個(gè)存儲(chǔ)服務(wù)，分別是BDev（Block Device）、Blobstore 和BlobFS。其中：BDev 只提供塊設(shè)備的語(yǔ)義，過(guò)于簡(jiǎn)單，不適合用作管理文件數(shù)據(jù)；BlobFS不支持對(duì)文件的隨機(jī)寫(xiě)入；而B(niǎo)lobstore則能提供對(duì)象存儲(chǔ)的語(yǔ)義，提供針對(duì)blob的創(chuàng)建、刪除、隨機(jī)讀寫(xiě)、長(zhǎng)度變更等操作。RUFS容易將針對(duì)文件內(nèi)容的操作，映射到Blobstore 中針對(duì)blob 的操作。因此，RUFS選擇將數(shù)據(jù)存儲(chǔ)在Blobstore中。

每創(chuàng)建一個(gè)文件，RUFS就在Blobstore中創(chuàng)建一個(gè)相應(yīng)的blob。目錄樹(shù)中的文件節(jié)點(diǎn)與Blobstore 中的blob 一一對(duì)應(yīng)。blob 的位置信息（blob 所屬的Blobstore 和blob ID），會(huì)成為文件元數(shù)據(jù)的一部分，存儲(chǔ)在RocksDB 當(dāng)中。每一個(gè)Blobstore實(shí)例都由一個(gè)固定的reactor管理，對(duì)Blobstore的任何操作，包括blob 的創(chuàng)建、刪除、讀寫(xiě)，都需要提交給對(duì)應(yīng)的reactor，由reactor完成。

2.3.1 元數(shù)據(jù)與數(shù)據(jù)的一致性策略

當(dāng)用戶創(chuàng)建或刪除一個(gè)文件時(shí)，RUFS不僅需要改變目錄樹(shù)的結(jié)構(gòu)，還需要在Blobstore 上創(chuàng)建或者刪除相應(yīng)的blob，維持文件節(jié)點(diǎn)與blob的一一對(duì)應(yīng)。宕機(jī)會(huì)導(dǎo)致文件的創(chuàng)建或刪除執(zhí)行不完整，破壞文件節(jié)點(diǎn)與blob一一對(duì)應(yīng)的關(guān)系。如果產(chǎn)生了游離的blob（沒(méi)有對(duì)應(yīng)文件節(jié)點(diǎn)的blob），則造成存儲(chǔ)空間的泄漏，如果文件節(jié)點(diǎn)沒(méi)有對(duì)應(yīng)的blob，則意味著數(shù)據(jù)丟失。

RUFS利用了一種基于blob標(biāo)記的手段來(lái)解決這個(gè)問(wèn)題?；镜乃悸肥牵瑢](méi)有和元數(shù)據(jù)建立聯(lián)系的blob 標(biāo)記為已解耦（detached），并將位置信息記錄到RocksDB 中，這樣即使服務(wù)器宕機(jī)，重啟RUFS之后，系統(tǒng)也能夠回收這些blob。

圖5（a）展示了文件的creat 過(guò)程，新創(chuàng)建的blob 會(huì)被標(biāo)記為detached，并記錄在RocksDB 當(dāng)中，只有在blob 元數(shù)據(jù)設(shè)置成功，并且將位置信息記錄在目錄樹(shù)上后，RocksDB 中的detached 記錄才會(huì)被刪除。如果因?yàn)殄礄C(jī)導(dǎo)致操作沒(méi)有完全執(zhí)行，RUFS 在重新啟動(dòng)時(shí)，通過(guò)檢查blob 的元數(shù)據(jù)和RocksDB中的記錄，就能回收游離的blob。Detached記錄的刪除過(guò)程與目錄樹(shù)的操作處于同一個(gè)RocksDB 事務(wù)中，能保證creat 成功后，被創(chuàng)建出的blob 不會(huì)被錯(cuò)誤地回收。圖5（b）展示了文件的unlink 操作，標(biāo)記blob 為detached 的過(guò)程會(huì)和刪除文件節(jié)點(diǎn)的過(guò)程放在同一個(gè)RocksDB 事務(wù)中。這能保證只要元數(shù)據(jù)的刪除操作成功，即使出現(xiàn)意外宕機(jī)，游離的blob也總能被回收。

圖5 創(chuàng)建和刪除文件的流程Fig.5 Processes of file creation and deletion

2.3.2 句柄與讀寫(xiě)狀態(tài)管理

根據(jù)POSIX 標(biāo)準(zhǔn)的要求，open、creat、opendir等操作，需要向調(diào)用者返回一個(gè)句柄。通過(guò)句柄，用戶可以進(jìn)一步地對(duì)文件或文件夾進(jìn)行其他操作，而不用再進(jìn)行從路徑到文件節(jié)點(diǎn)的搜索和權(quán)限判斷。在RUFS 中，通過(guò)句柄，用戶可以讀寫(xiě)文件（read、write、pread、pwrite），遍歷文件夾下的子項(xiàng)目（readdir）。

RUFS 的句柄包含兩個(gè)字段：一個(gè)字段是被打開(kāi)節(jié)點(diǎn)的UUID，用來(lái)標(biāo)示被打開(kāi)的節(jié)點(diǎn)；另一個(gè)字段是一個(gè)唯一的64位無(wú)符號(hào)數(shù)（fd ID），用來(lái)標(biāo)示打開(kāi)同一個(gè)文件的不同句柄。通過(guò)句柄，RUFS-server能夠查找當(dāng)前句柄對(duì)應(yīng)的讀寫(xiě)狀態(tài)。

RUFS-server采用了圖6中的數(shù)據(jù)結(jié)構(gòu)來(lái)管理句柄的讀寫(xiě)狀態(tài)，這個(gè)數(shù)據(jù)結(jié)構(gòu)用了一個(gè)以UUID 為鍵的哈系表，來(lái)維持被打開(kāi)文件/文件夾的內(nèi)存節(jié)點(diǎn)。內(nèi)存節(jié)點(diǎn)中包含了對(duì)其進(jìn)行操作所需要的數(shù)據(jù)；文件內(nèi)存節(jié)點(diǎn)中包含了文件對(duì)應(yīng)的blob的位置信息，緩存了文件的長(zhǎng)度和時(shí)間戳；文件夾內(nèi)存節(jié)點(diǎn)，存儲(chǔ)了以該文件夾為父節(jié)點(diǎn)的E 型鍵值對(duì)的鍵的公共前綴（前綴E+文件夾UUID），這個(gè)前綴用來(lái)在遍歷E 型鍵值對(duì)時(shí)，判斷被訪問(wèn)的鍵值對(duì)是否指向該文件夾的子節(jié)點(diǎn)。每個(gè)內(nèi)存節(jié)點(diǎn)中包含了一條鏈表，鏈表上的每一個(gè)元素，都記錄了某個(gè)句柄對(duì)應(yīng)的讀寫(xiě)狀態(tài)，如果句柄屬于一個(gè)文件，那么讀寫(xiě)狀態(tài)就是當(dāng)前偏移（offset）的位置，如果句柄屬于一個(gè)文件夾，那么讀寫(xiě)狀態(tài)就是readdir 操作所需的RocksDB 迭代器。利用圖6 中的數(shù)據(jù)結(jié)構(gòu)，RUFS 還能通過(guò)哈希表快速地判斷某個(gè)節(jié)點(diǎn)是否被打開(kāi)，阻止被打開(kāi)的節(jié)點(diǎn)被刪除。

圖6 RUFS對(duì)句柄的管理Fig.6 Management of handles in RUFS

3 系統(tǒng)實(shí)現(xiàn)與優(yōu)化

3.1 網(wǎng)絡(luò)傳輸優(yōu)化

RUFS 采用了CaRT 作為客戶端與服務(wù)器端通信的手段。CaRT 為用戶提供了RPC 接口和bulk接口，bulk接口能夠充分利用RDMA 的單邊通信性能，避免不必要的內(nèi)存拷貝。元數(shù)據(jù)操作需要傳輸?shù)臄?shù)據(jù)量通常很少，因此RUFS 只使用CaRT提供的RPC 接口來(lái)發(fā)送元數(shù)據(jù)操作。但讀寫(xiě)操作，可能需要傳輸較多的數(shù)據(jù)，為了充分利用RDMA的單邊通信原語(yǔ)，提高傳輸性能，RUFS利用bulk接口來(lái)傳輸讀寫(xiě)緩沖區(qū)中的內(nèi)容。

但使用bulk接口，需要用戶自己申請(qǐng)內(nèi)存，并將內(nèi)存注冊(cè)為一個(gè)塊（bulk）。注冊(cè)bulk非常耗時(shí)，將一塊僅1 B的內(nèi)存注冊(cè)為bulk，需要耗費(fèi)大約60 μs，如果在客戶端和服務(wù)器端都進(jìn)行內(nèi)存的注冊(cè)，一次通信會(huì)產(chǎn)生額外的120 μs的開(kāi)銷，隨著被注冊(cè)內(nèi)存的增大，耗時(shí)還會(huì)增大。圖7 展示了發(fā)送不同大小的負(fù)載時(shí)復(fù)用bulk（記為reuse-bulk）和每次注冊(cè)新的bulk（記為register-bulk）在傳輸延遲上的性能差距。

圖7 不同負(fù)載下bulk傳輸?shù)难舆tFig.7 Bulk transfer latency with different payload sizes

為了解決這一問(wèn)題，RUFS 設(shè)計(jì)了一個(gè)內(nèi)存池，Bulk-Mempool。Bulk-Mempool 會(huì)提前將一些大塊的內(nèi)存注冊(cè)為一個(gè)bulk，并在這塊內(nèi)存上進(jìn)行進(jìn)一步的分配。在讀寫(xiě)操作的過(guò)程中，服務(wù)器和客戶端用到的讀寫(xiě)緩沖區(qū)就從這個(gè)內(nèi)存池中分配，這就消除了RUFS 在每次讀寫(xiě)操作時(shí)，將讀寫(xiě)緩沖區(qū)所在的內(nèi)存注冊(cè)為bulk而帶來(lái)的開(kāi)銷。

Bulk-Mempool 并不是一個(gè)單一策略的內(nèi)存池，而是由兩個(gè)不同策略的內(nèi)存池BM-small 和BM-mid 組成的。BM-small實(shí)現(xiàn)比較簡(jiǎn)單，分配開(kāi)銷較小，只分配4 KB 大小的內(nèi)存；BM-mid內(nèi)部實(shí)現(xiàn)了一個(gè)buddy system 內(nèi)存池，開(kāi)銷相對(duì)較大。小文件讀寫(xiě)通常觸發(fā)小于等于4 KB 的內(nèi)存分配請(qǐng)求，此時(shí)由開(kāi)銷較小的BM-small 進(jìn)行內(nèi)存分配，能夠保證小文件讀寫(xiě)的性能；大于4 KB、小于等于4 MB 的內(nèi)存分配請(qǐng)求，則由BMmid 負(fù)責(zé)。BM-mid 能夠分配不同大小的內(nèi)存，提高內(nèi)存的利用率。

圖8 Bulk-Mempool的架構(gòu)Fig.8 Architecture of Bulk-Mempool

Bulk-Mempool 沒(méi)有對(duì)大于4 MB 的內(nèi)存分配進(jìn)行優(yōu)化，是因?yàn)橐? MB 為單位的數(shù)據(jù)傳輸，已經(jīng)能夠充分地利用InfiniBand 的高帶寬，使數(shù)據(jù)傳輸不會(huì)成為整個(gè)系統(tǒng)的瓶頸，本文的實(shí)驗(yàn)也說(shuō)明了這一點(diǎn)（見(jiàn)4.3 節(jié)）。如果用戶需要傳輸大文件，將每次讀寫(xiě)請(qǐng)求分割為4 MB大小即可。

Bulk-Mempool 提供get 和put接口。通過(guò)get 接口，調(diào)用者能夠獲得一個(gè)胖指針，其中包括了指向被分配內(nèi)存的指針、被分配內(nèi)存的大小、被分配內(nèi)存在bulk 中的偏移，以及bulk 句柄。前兩者使得調(diào)用者可以在本地讀寫(xiě)分配到的內(nèi)存，后兩者使得遠(yuǎn)端機(jī)器能夠正確在分配到的內(nèi)存上進(jìn)行讀寫(xiě)。

3.2 讀寫(xiě)吞吐能力優(yōu)化

按照POSIX 語(yǔ)義的要求，文件的讀寫(xiě)會(huì)導(dǎo)致文件的大小和時(shí)間戳發(fā)生變化，導(dǎo)致元數(shù)據(jù)的改動(dòng)。這在Blobstore 中就表現(xiàn)為需要通過(guò)sync md（同步元數(shù)據(jù)）操作同步blob 的元數(shù)據(jù)，但sync md 操作非常耗時(shí)，甚至超過(guò)了一次4 KB 的讀或?qū)?。如果每次文件讀寫(xiě)都要更新時(shí)間戳或是文件長(zhǎng)度，頻繁觸發(fā)sync md 操作，會(huì)讓整個(gè)系統(tǒng)的吞吐能力受到極大的影響。為此，RUFS提供了兩個(gè)優(yōu)化策略，以減小sync md的觸發(fā)頻率。

第一個(gè)策略是，提供了ftruncate 操作，并鼓勵(lì)用戶盡可能在寫(xiě)入數(shù)據(jù)前，將文件擴(kuò)展到合適的大小，這樣能夠避免寫(xiě)入操作“撐大”文件大小，進(jìn)而觸發(fā)sync md。另一個(gè)策略是，放寬對(duì)時(shí)間戳更新的要求，每次進(jìn)行讀寫(xiě)時(shí)，將系統(tǒng)當(dāng)前的時(shí)間，與文件當(dāng)前的時(shí)間戳進(jìn)行比較，只有文件需要更新的時(shí)間戳，與當(dāng)前的時(shí)間相差多于5 ms 時(shí)，才選擇更新時(shí)間戳?？紤]到系統(tǒng)本身就存在著時(shí)間上的誤差，這樣的放松策略是可以接受的。

3.3 可靠元數(shù)據(jù)性能優(yōu)化

RocksDB 會(huì)將寫(xiě)入操作記錄到日志里，但并不會(huì)立刻將日志寫(xiě)入到磁盤(pán)中。在內(nèi)存中緩存一定數(shù)量的日志之后，RocksDB 才會(huì)一次性地將所有內(nèi)存中的日志寫(xiě)到硬盤(pán)上。這個(gè)特性被稱作“組提交（group commit）”，組提交特性顯著地減少了向磁盤(pán)寫(xiě)入數(shù)據(jù)的次數(shù)，對(duì)RocksDB 的寫(xiě)入性能有很大的提升。但同時(shí)，由于寫(xiě)入的數(shù)據(jù)不能被及時(shí)持久化，服務(wù)器斷電就可能導(dǎo)致元數(shù)據(jù)操作的丟失。考慮到Blobstore會(huì)保證數(shù)據(jù)持久化后再返回，為了使元數(shù)據(jù)與數(shù)據(jù)保持一致，提供同步的文件系統(tǒng)語(yǔ)義，RUFS 也需要保證元數(shù)據(jù)操作返回后，就已經(jīng)持久化到了硬盤(pán)上。

為了提供這樣的保證，RUFS 打開(kāi)了RocksDB 的同步模式。同步模式下，每次寫(xiě)入操作后，RocksDB 都會(huì)調(diào)用fsync保證日志寫(xiě)入硬盤(pán)，使數(shù)據(jù)在宕機(jī)后不丟失。然而，本地文件系統(tǒng)的fsync 性能很差，這導(dǎo)致了RocksDB 同步模式下的寫(xiě)入性能也很差，降低了RUFS 整體的元數(shù)據(jù)性能。為了解決這個(gè)問(wèn)題，RUFS采用了由SPDK團(tuán)隊(duì)修改并開(kāi)源的RocksDB［38］。這個(gè)版本的RocksDB 將底層的存儲(chǔ)環(huán)境更換為了BlobFS。BlobFS 有很好的同步寫(xiě)入性能，能夠顯著提升RocksDB 在同步模式下的寫(xiě)入性能。

RocksDB 的讀操作觸發(fā)的都是文件的隨機(jī)讀，而B(niǎo)lobFS當(dāng)前僅針對(duì)順序讀進(jìn)行緩存。緩存的缺失使RocksDB 的讀性能變得很差。為了解決這個(gè)問(wèn)題，在BlobFS 中添加了一個(gè)支持緩存的隨機(jī)讀方法，當(dāng)RocksDB 調(diào)用這個(gè)方法進(jìn)行讀操作時(shí)，BlobFS 會(huì)預(yù)取所需數(shù)據(jù)所在的一個(gè)256 KB 的數(shù)據(jù)塊，并緩存在內(nèi)存當(dāng)中。利用緩存，相比以文件系統(tǒng)作為存儲(chǔ)環(huán)境，RocksDB 在BlobFS 上的寫(xiě)性能能得到顯著提升，且保持讀性能基本相同。

3.4 統(tǒng)一的SPDK環(huán)境管理模塊

RUFS 利用一個(gè)或多個(gè)Blobstore 管理數(shù)據(jù)，利用由SPDK團(tuán)隊(duì)提供的RocksDB 管理元數(shù)據(jù)。這兩者都需要工作在SPDK環(huán)境下。當(dāng)前，由SPDK團(tuán)隊(duì)提供的RocksDB，會(huì)在內(nèi)部自行啟動(dòng)一個(gè)SPDK 環(huán)境。由于一個(gè)進(jìn)程只能啟動(dòng)一個(gè)SPDK 環(huán)境，因此RocksDB 啟動(dòng)的SPDK 環(huán)境，會(huì)和RUFS 啟動(dòng)的SPDK環(huán)境產(chǎn)生沖突，導(dǎo)致整個(gè)系統(tǒng)啟動(dòng)失敗。

為了解決這一問(wèn)題，RUFS 去掉了RocksDB 中啟動(dòng)SPDK環(huán)境的功能，并將這部分功能整合到了RUFS 中，再加上對(duì)Blobstore 依賴的SPDK 環(huán)境的管理功能，形成了統(tǒng)一的SPDK環(huán)境管理模塊（SPDK-env-mod）。系統(tǒng)啟動(dòng)時(shí)，SPDK-env-mod會(huì)初始化SPDK 環(huán)境，同時(shí)創(chuàng)建BlobFS。在RocksDB 初始化時(shí)，SPDK-env-mod 會(huì)將BlobFS 暴露給RocksDB，使RocksDB順利在BlobFS上初始化和運(yùn)行。

除了解決SPDK 環(huán)境沖突的問(wèn)題，SPDK-env-mod 還方便了系統(tǒng)管理員對(duì)Blobstore 的管理。SPDK-env-mod 提供了一個(gè)配置文件，系統(tǒng)管理員可以通過(guò)該配置文件，指定用來(lái)管理數(shù)據(jù)的SSD，以及用于管理數(shù)據(jù)的reactor 線程的數(shù)量。系統(tǒng)啟動(dòng)后，SPDK-env-mod 會(huì)根據(jù)配置文件，在每塊用于管理數(shù)據(jù)的SSD 上，建立Blobstore 實(shí)例。同時(shí)，根據(jù)配置文件，啟動(dòng)一定數(shù)量的reactor 線程，并按照平均分配的原則，將Blobstore綁定到不同的reactor線程上。

除此之外，SPDK-env-mod 會(huì)給每一個(gè)Blobstore 賦予一個(gè)從0 開(kāi)始的、單調(diào)遞增的唯一編號(hào)，同時(shí)在內(nèi)存中維持一個(gè)計(jì)數(shù)器，每次系統(tǒng)需要?jiǎng)?chuàng)建一個(gè)blob 時(shí)，就將計(jì)數(shù)器的值對(duì)Blobstore 的數(shù)量取模，以此選出一個(gè)Blobstore 實(shí)例，在這個(gè)實(shí)例上創(chuàng)建blob，并將計(jì)數(shù)器原子地加1。由于Blobstore實(shí)例與用來(lái)管理數(shù)據(jù)的SSD 一一對(duì)應(yīng)，這樣的分配方案，可以保證blob均勻地分布在各個(gè)SSD上。

4 測(cè)試與評(píng)估

本章將評(píng)估RUFS 在元數(shù)據(jù)、讀寫(xiě)延遲和讀寫(xiě)吞吐方面的性能。RUFS的總體性能會(huì)和NFS+ext4進(jìn)行比較；而RUFSserver的性能會(huì)和ext4進(jìn)行比較。本章還會(huì)討論SPDK對(duì)元數(shù)據(jù)的加速效果和多SSD對(duì)吞吐性能的提升。

4.1 測(cè)試配置

所有的測(cè)試都在兩臺(tái)服務(wù)器上進(jìn)行，其中一臺(tái)作為RUFS的服務(wù)器，另一臺(tái)作為RUFS 的客戶端。RUFS 客戶端裝配了2 塊6 核CPU，128 GB 內(nèi)存；RUFS 服務(wù)器端裝配了4 塊12 核CPU、768 GB 內(nèi)存、8 塊容量為512 GB 的NVMe SSD。兩臺(tái)服務(wù)器通過(guò)56 Gb/s 帶寬的InfiniBand 網(wǎng)卡相連。表1 是測(cè)試環(huán)境的具體參數(shù)。

在所有測(cè)試中，NFS 與ext4 均采用默認(rèn)配置，ext4 建立在服務(wù)器端，使用1塊SSD，利用NFS掛載到客戶端。RUFS使用2 塊SSD，分別用來(lái)管理數(shù)據(jù)和元數(shù)據(jù)，使用16 個(gè)RPC 處理線程，1 個(gè)reactor 線程?？蛻舳死肦UFS 客戶端提供的API 訪問(wèn)RUFS服務(wù)器。

表1 測(cè)試環(huán)境設(shè)置Tab.1 Testing environment configuration

4.2 元數(shù)據(jù)性能

本文采用mdtest［39］對(duì)元數(shù)據(jù)性能進(jìn)行測(cè)試，用每秒的操作數(shù)量（Operations Per Second，OPS）衡量性能。該測(cè)試對(duì)比了NFS+ext4 與RUFS 整體的元數(shù)據(jù)性能。在元數(shù)據(jù)性能測(cè)試中，客戶端使用8 個(gè)mdtest 進(jìn)程，文件節(jié)點(diǎn)的最大深度為4，文件/文件夾總數(shù)大約為50 萬(wàn)。如果測(cè)試對(duì)象為RUFS，需要將mdtest中的文件系統(tǒng)函數(shù)換成RUFS-API。

4.2.1 需要關(guān)注的元數(shù)據(jù)操作

在本節(jié)的測(cè)試中，主要關(guān)注如下的元數(shù)據(jù)操作：D-creat、D-stat、D-remove、F-creat、F-stat、F-read 和F-remove，表2 展示了它們的意義和在過(guò)程中會(huì)觸發(fā)的操作。

表2 元數(shù)據(jù)操作和它們的屬性和含義Tab.2 Metadata operations and their attributions and meanings

4.2.2 測(cè)試結(jié)果

從圖9 來(lái)看：RUFS 在F-creat 和F-remove 兩個(gè)操作上，與NFS+ext4 的性能大致相同；在其他元數(shù)據(jù)操作上，RUFS 都具有顯著的優(yōu)勢(shì)，取得了至少70%的提升；特別對(duì)于D-creat 操作，RUFS 相對(duì)于NFS+ext4 有大約5 693.8%的性能提升。橫向?qū)Ρ萊UFS各個(gè)元數(shù)據(jù)操作的性能，F(xiàn)-creat和F-remove由于需要在Blobstore 上進(jìn)行多次操作，因此性能顯著低于其他元數(shù)據(jù)操作。F-read 操作包含了一次open 操作和一次close 操作，且需要訪問(wèn)Blobstore，因此性能也同樣較差。

圖9 RUFS與NFS+ext4元數(shù)據(jù)性能的比較Fig.9 Metadata performance comparison of RUFS and NFS+ext4

4.2.3 SPDK為元數(shù)據(jù)帶來(lái)的性能提升

為了達(dá)到同步語(yǔ)義，RUFS在使用RocksDB 時(shí)會(huì)打開(kāi)同步模式，這會(huì)導(dǎo)致RocksDB的寫(xiě)入性能大幅下降。SPDK能夠?yàn)榇鎯?chǔ)應(yīng)用帶來(lái)更低的延遲、更高的吞吐性能。通過(guò)將RocksDB 的存儲(chǔ)環(huán)境替換為優(yōu)化后的BlobFS，RocksDB 的同步寫(xiě)性能有了很大的提升，并且讀性能沒(méi)有受到影響。本節(jié)將展示BlobFS對(duì)元數(shù)據(jù)性能的影響。

圖10 展示了RUFS 元數(shù)據(jù)性能在RocksDB 在不同配置（同步模式或組提交模式，分別記為sync 和group-commit）、不同存儲(chǔ)環(huán)境下（文件系統(tǒng)或BlobFS，分別記為fs和SPDK）的結(jié)果。從非同步模式切換為同步模式，無(wú)論存儲(chǔ)環(huán)境是BlobFS還是文件系統(tǒng)，涉及到RocksDB寫(xiě)入的元數(shù)據(jù)操作，都會(huì)有明顯的性能下降。在BlobFS 環(huán)境下，creat 操作性能損耗最大，大約為38.8%，但由于原本性能很好，因此性能依然可以接受。存儲(chǔ)環(huán)境為本地文件系統(tǒng)時(shí)，元數(shù)據(jù)操作的性能損耗變得不可接受，性能損耗最多的元數(shù)據(jù)操作依然是creat，損耗比例高達(dá)98.7%，基本處于不可用的狀態(tài)。其他元數(shù)據(jù)操作，除了D-stat 與F-stat 不發(fā)生RocksDB 寫(xiě)入，不受同步模式的影響，其他操作的OPS都小于2 500。

圖10 SPDK對(duì)元數(shù)據(jù)操作的性能的影響Fig.10 Impact of SPDK on metadata operation performance

4.3 數(shù)據(jù)性能

本節(jié)將討論RUFS、NFS-ext4、RUFS-server 和ext4 在4 KB隨機(jī)讀寫(xiě)延遲、4 KB 隨機(jī)讀寫(xiě)吞吐、4 MB 順序讀寫(xiě)吞吐幾個(gè)場(chǎng)景上的性能。由于當(dāng)前RUFS 還沒(méi)有加入對(duì)緩存的支持，因此在對(duì)ext4 進(jìn)行測(cè)量時(shí)，盡量消除了緩存對(duì)ext4 的影響。ext4 的寫(xiě)入包括兩個(gè)項(xiàng)目：ext4-direct 和ext4-sync。前者在打開(kāi)文件時(shí)，使用了O_DIRECT 選項(xiàng)，避免數(shù)據(jù)寫(xiě)入到緩存；后者在打開(kāi)文件時(shí)使用了O_SYNC 選項(xiàng)，保證寫(xiě)入數(shù)據(jù)能夠持久化到硬盤(pán)。需要說(shuō)明的是，由于O_SYNC 選項(xiàng)不影響讀操作，因此在測(cè)試讀性能時(shí)，ext4-sync 與ext4-direct 會(huì)使用同一個(gè)數(shù)據(jù)。RUFS-server 仍然使用16 個(gè)RPC 處理線程，用1 塊SSD管理元數(shù)據(jù)，1塊SSD管理數(shù)據(jù)。

4.3.1 延遲

測(cè)量了RUFS-server、ext4-sync、ext4-direct、RUFS、NFS+ext4的4 KB 隨機(jī)讀寫(xiě)的延遲，圖11展示了測(cè)試結(jié)果。從結(jié)果上來(lái)看，RUFS-server 的讀延遲，大約只有ext4 的20%。在網(wǎng)絡(luò)環(huán)境下，RUFS 總體的讀延遲，只有NFS+ext4 的26%左右。而對(duì)于本地寫(xiě)性能，RUFS-server 僅略快于ext4-direct，但要注意，ext4-direct 并不保證操作返回時(shí)，能將數(shù)據(jù)持久化在硬盤(pán)上。提供這一保證的ext4-sync，寫(xiě)延遲則是RUFS-server 的近60 倍，在網(wǎng)絡(luò)環(huán)境下，RUFS 總體的寫(xiě)延遲也遠(yuǎn)遠(yuǎn)小過(guò)NFS+ext4。

圖11 RUFS與NFS+ext4關(guān)于4 KB隨機(jī)訪問(wèn)的延遲Fig.11 4 KB random access latency of RUFS and NFS+ext4

4.3.2 吞吐

吞吐性能測(cè)試包括了4 KB 隨機(jī)讀寫(xiě)和4 MB 順序讀寫(xiě)兩個(gè)項(xiàng)目。圖12 展示了4 KB 隨機(jī)讀寫(xiě)吞吐性能的結(jié)果。這個(gè)結(jié)果和延遲測(cè)試類似，RUFS-server 在讀寫(xiě)性能上，都遠(yuǎn)遠(yuǎn)地超過(guò)了ext4-sync，同時(shí)略強(qiáng)于不提供持久化保證的ext4-direct?？傮w性能上，RUFS 讀性能是NFS+ext4 的3 倍以上，寫(xiě)性能是NFS+ext4的8倍以上。

圖12 NFS+ext4與RUFS關(guān)于4 KB隨機(jī)訪問(wèn)的吞吐性能Fig.12 4 KB random access bandwidth of NFS+ext4 and RUFS

在4 MB 的順序讀寫(xiě)上，ext4 與RUFS 的差距就相對(duì)小了一些。沒(méi)有網(wǎng)絡(luò)參與時(shí)，無(wú)論是讀還是寫(xiě)，RUFS-server 均快于ext4，但性能提升不超過(guò)30%。但值得注意的是，在大文件的順序讀寫(xiě)中，RUFS 的總體性能與RUFS-server 的吞吐性能幾乎持平，這意味著網(wǎng)絡(luò)傳輸提供了足夠高的帶寬，沒(méi)有成為整個(gè)系統(tǒng)的瓶頸。

圖13 RUFS與NFS+ext4關(guān)于4 MB順序訪問(wèn)的吞吐性能Fig.13 4 MB sequential access bandwidth of RUFS and NFS+ext4

4.3.3 多SSD帶來(lái)的性能提升

RUFS-server默認(rèn)只用1個(gè)SSD管理數(shù)據(jù)，因此也只使用1個(gè)reactor 線程管理讀寫(xiě)請(qǐng)求。如果使用多個(gè)SSD 管理數(shù)據(jù)，RUFS-server 就能啟動(dòng)多個(gè)reactor 處理讀寫(xiě)請(qǐng)求，這能夠提升RUFS-server 的吞吐性能。圖14 展示了RUFS-server 在多塊SSD下吞吐性能的提升。當(dāng)使用6塊SSD管理數(shù)據(jù)時(shí)，通過(guò)將文件分散到各塊SSD，并用6 個(gè)reactor 同時(shí)處理讀寫(xiě)請(qǐng)求，RUFS-server的吞吐性能能獲得246%到450%的提升。

圖14 多SSD為RUFS-server帶來(lái)的加速比Fig.14 Speedup ratio brought by multi-SSD on RUFS-server

5 結(jié)語(yǔ)

本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)基于高速網(wǎng)絡(luò)和NVMe SSD 的用戶態(tài)網(wǎng)絡(luò)文件系統(tǒng)，RUFS。RUFS 利用RocksDB 管理元數(shù)據(jù)，利用Blobstore 管理數(shù)據(jù)，使用RDMA 技術(shù)對(duì)外提供服務(wù)。RUFS 充分地利用了NVMe SSD 的性能，所有的存儲(chǔ)過(guò)程都通過(guò)SPDK 提供的NVMe 驅(qū)動(dòng)運(yùn)行在用戶態(tài)。RUFS 在隨機(jī)讀寫(xiě)、順序讀寫(xiě)和元數(shù)據(jù)性能上，相較于NFS+ext4 都有十分明顯的優(yōu)勢(shì)。除此之外，RUFS 還具備同步語(yǔ)義，能夠保證用戶請(qǐng)求返回后，數(shù)據(jù)就已經(jīng)被持久化到硬盤(pán)當(dāng)中。

通過(guò)RUFS 的開(kāi)發(fā)和測(cè)試，也充分證明了SPDK 在存儲(chǔ)領(lǐng)域的潛力，尤其是保證數(shù)據(jù)可靠寫(xiě)入、并持久化在硬盤(pán)的性能，明顯地好于本地文件系統(tǒng)。因此SPDK 也十分適合于開(kāi)發(fā)對(duì)存儲(chǔ)持久性要求較高的應(yīng)用，例如關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)引擎。