2 年前我們發表了一遍文章 2018 儲存技術熱點與趨勢總結，受到了不少朋友的關注。2 年過去了，儲存行業也在不斷的發生著變化。今天，我們就結合過去兩年學術界和工業界的進展，幫大家做一次總結，供大家參考。

本文內容會涉及到 Persistent Memory、Consensus、Consistency、

Persistent Memory（PMem）

PMem 在 2018 年的時候還僅限於學術界的探討，而如今已經來到了工業界。Intel 在 2019 年 4 月份釋出了第一款 Intel Optane DC Persistent Memory（內部產品代號 Apache Pass），可以說是一個劃時代的事件。如果你完全沒有聽說過 PMem，那麼可以先透過我之前的文章瞭解一下。

我們先來看一下實物的樣子

是的，DIMM 介面，看起來就像記憶體。所以很多人會把 Optane PMem 和 Optane SSD 弄混，因為都叫 Optane。實際上 Optane SSD 是 NVMe 介面，走 PCIe 匯流排。由於介面和匯流排不同，Optane PMem 和 Optane SSD 的使用方式也完全不同的。

目前單條（因為長得像記憶體，所以就用“條”來做量詞了）容量一共有三種選擇：128G、256G、512G，價格還是相當貴的。

這裡我想強調的是：PMem 並不是更慢的記憶體，也不是更快的 SSD，PMem 就是 PMem，他有大量屬於自己的特性。為了使用好 PMem，我們還需要對 PMem 瞭解更多。

首先，由於 PMem 是 DIMM 介面，可以直接透過 CPU 指令訪問資料。讀取 PMem 的時候，和讀取一個普通的記憶體地址沒有區別，CPU Cache 會做資料快取，所有關於記憶體相關的知識，例如 Cache Line 最佳化，Memory Order 等等在這裡都是適用的。而寫入就更復雜了，除了要理解記憶體相關的特性以外，還需要理解一個重要的概念：Power-Fail Protected Domains。這是因為，儘管 PMem 裝置本身是非易失的，但是由於有 CPU Cache 和 Memory Controller 的存在，以及 PMem 裝置本身也有快取，所以當裝置掉電時，Data in-flight 還是會丟失。

針對掉電保護，Intel 提出了 Asynchronous DRAM Refresh（ADR）的概念，負責在掉電時把 Data in-flight 回寫到 PMem 上，保證資料永續性。目前 ADR 只能保護 iMC 裡的 Write Pending Queue（WPQ）和 PMem 的快取中的資料，但無法保護 CPU Cache 中的資料。在 Intel 下一代的產品中，將推出 Enhanced ADR（eADR），可以進一步做到對 CPU Cache 中資料的保護。

由於 ADR 概念的存在，所以簡單的 MOV 指令並不能保證資料持久化，因為指令結束時，資料很可能還停留在 CPU Cache 中。為了保證資料持久化，我們必須呼叫 CLFLUSH 指令，保證 CPU Cache Line 裡的資料寫回到 PMem 中。

然而 CLFLUSH 並不是為 PMem 設計的。CLFLUSH 指令一次只能 Flush 一個 Cache Line，且只能序列執行，所以執行效率非常低。為了解決 CLFLUSH 效率低的問題，Intel 推出了一個新的指令 CLFLUSHOPT，從字面意思上看就是 CLFLUSH 的最佳化版本。CLFLUSHOPT 和 CLFLUSH 相比，多個 CLFLUSHOPT 指令可以併發執行。可以大大提高 Cache Line Flush 的效率。當然，CLFLUSHOPT 後面還需要跟隨一個 SFENCE 指令，以保證 Flush 執行完成。

和 CLFLUSHOPT 對應的，是 CLWB 指令，CLWB 和 CLFLUSHOPT 的區別是，CLWB 指令執行完成後，資料還保持在 CPU Cache 裡，如果再次訪問資料，就可以保證 Cache Hit，而 CLFLUSHOPT 則相反，指令執行完成後，CPU Cache 中將不再儲存資料。

此外 Non-temporal stores（NTSTORE）指令（經專家更提醒，這是一個 SSE2 裡面就新增的指令，並不是一個新指令）可以做到資料寫入的時候 bypass CPU Cache，這樣就不需要額外的 Flush 操作了。NTSTORE 後面也要跟隨一個 SFENCE 指令，以保證資料真正可以到達持久化區域。

看起來很複雜對吧，這還只是個入門呢，在 PMem 上寫程式的複雜度相當之高。Intel 最近出了一本書 “Programming Persistent Memory”，專門介紹如何在 PMem 上進行程式設計，一共有 400 多頁，有興趣的小夥伴可以讀一讀。

為了簡化使用 PMem 的複雜度，Intel 成立了 PMDK 專案，提供了大量的封裝好的介面和資料結構，這裡我就不一一介紹了。

PMem 釋出以後，不少的機構都對它的實際效能做了測試，因為畢竟之前大家都是用記憶體來模擬 PMem 的，得到的實驗結果並不準確。其中 UCSD 發表的 “Basic Performance Measurements of the Intel Optane DC Persistent Memory Module” 是比較有代表性的。這篇文章幫我們總結了 23 個 Observation，其中比較重要的幾點如下：

The read latency of random Optane DC memory loads is 305 ns This latency is about 3× slower than local DRAM
Optane DC memory latency is significantly better (2×) when accessed in a sequential pattern. This result indicates that Optane DC PMMs merge adjacent requests into a single 256 byte access
Our six interleaved Optane DC PMMs’ maximum read bandwidth is 39.4 GB/sec, and their maximum write bandwidth is 13.9 GB/sec. This experiment utilizes our six interleaved Optane DC PMMs, so accesses are spread across the devices
Optane DC reads scale with thread count; whereas writes do not. Optane DC memory bandwidth scales with thread count, achieving maximum throughput at 17 threads. However, four threads are enough to saturate Optane DC memory write bandwidth
The application-level Optane DC bandwidth is affected by access size. To fully utilize the Optane DC device bandwidth, 256 byte or larger accesses are preferred
Optane DC is more affected than DRAM by access patterns. Optane DC memory is vulnerable to workloads with mixed reads and writes
Optane DC bandwidth is significantly higher (4×) when accessed in a sequential pattern. This result indicates that Optane DC PMMs contain access to merging logic to merge overlapping memory requests — merged, sequential, accesses do not pay the write amplification cost associated with the NVDIMM’s 256 byte access size

如果你正在開發針對 PMem 的程式，一定要仔細理解。

PMem 的好處當然很多，延遲低、峰值頻寬高、按位元組訪問，這沒什麼好說的，畢竟是 DIMM 介面，價格也在那裡擺著。

這裡我想給大家提幾個 PMem 的坑，這可能是很多測試報告裡面不會提到的，而是我們親身經歷過的，供大家參考：

儘管峰值頻寬高，但單執行緒吞吐率低，甚至遠比不上透過 SPDK 訪問 NVMe 裝置。舉例來說，Intel 曾釋出過一個報告，利用 SPDK，在 Block Size 為 4KB 的情況下，單執行緒可以達到 10 Million 的 IOPS。而根據我們測試的結果，在 PMem 上，在 Block Size 為 4KB 時，單執行緒只能達到 1 Million 的 IOPS。這是由於目前 PMDK 統一採用同步的方式訪問資料，所有記憶體複製都由 CPU 來完成，導致 CPU 成為了效能瓶頸。為了解決這個問題，我們採用了 DMA 的方式進行訪問，極大的提高了單執行緒訪問的效率。關於這塊資訊，我們將在未來用單獨的文章進行講解。

另一個坑就是，跨 NUMA Node 訪問時，效率受到比較大的影響。在我們的測試中發現，跨 NUMA Node 的訪問，單執行緒只提供不到 1GB/s 的頻寬。所以一定要注意保證資料訪問是 Local 的。

關於 PMem 的使用場景，其實有很多，例如：

作為容量更大，價格更便宜的主存，在這種情況下，PMem 實際上並不 Persitent。這裡又有兩種模式：
OS 不感知，由硬體負責將 DRAM 作為 Cache，PMem 作為主存
OS 感知，將 PMem 作為一個獨立的 memory-only NUMA Node，目前已經被 Linux Kernel 支援，Patchset
作為真正的 PMem，提供可持久化儲存能力

關於 PMem 的其他部分，我們後續還會有專門的文章介紹。

順便劇透一下，我們即將在今年上半年釋出的 SMTX ZBS 4.5 版本中，包含了針對 PMem 的大量最佳化工作，和上一個版本相比，整體延遲可以降低超過 80%~

Distributed Consensus and Consistency

Distributed Consensus 在過去十年已經被大家研究的比較透徹了，目前各種 Paxos，Raft 已經的實現已經被廣泛應用在各種生產環境了，各種細節的最佳化也層出不窮。

如果你想系統性的學習一下 Distributed Consensus 的話，那麼推薦你看一篇劍橋女博士 Heidi Howard 的畢業論文“Distributed consensus revised”。這篇論文可以說是把過去幾十年大家在 Distributed Consensus 上的工作做了一個大而全總結。透過總結前人的工作，整理出了一個 Distributed Consensus 的模型，並且逐個調節模型中的約束條件，從而遍歷了幾乎所有可能的最佳化演算法，可以說是庖丁解牛，非常適合作為 Distributed Consensus 的入門文章。

說到 Distributed Consensus，就離不開 Consistency。Distributed Consensus 是實現 Strong Consistency 的非常經典的做法，但是，並不是唯一的做法。

Distributed Consensus 只是手段，Strong Consistency 才是目的。

實現 Strong Consistency 的方法還有很多。在過去一段時間裡面，我認為最經典的要數 Amazon 的 Aurora。

Amazon Aurora 目前共發表了兩篇文章。第一篇是 2017 年在 SIGMOD 上發表的 “Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases”，另一篇是在 2018 年的 SIGMOD 上發表了一篇論文 “Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes”。第二篇論文主要講述了他們如何在不使用 Distributed Consensus 的情況下，達到 Strong Consistency 的效果。

為了介紹 Aurora，我們先來簡單看一下通常 Distributed Consensus 是如何做到 Strong Consistency 的。

我們假設當前計算端的狀態是 S0，此時我們收到了一個請求，要把狀態變更為 S1。為了完成這個變更，儲存端會發起了一次 Distributed Consensus。如果成功，則計算端把狀態變更為 S1；如果失敗，則狀態維持在 S0 不變。可以看到儲存端向計算端返回的狀態只有成功和失敗兩個狀態，而實際上儲存端內部會有更多的狀態，例如 5 個節點裡面 3 個成功了，1 個失敗了，1 個超時了。而這些狀態都被儲存端遮蔽了，計算端不感知。這就導致計算端必須等待儲存端完成 Distributed Consensus 以後，才能繼續向前推進。在正常情況下不會有問題，但一旦儲存端發生異常，計算端必須要等待儲存端完成 Leader Election 或 Membership Change，導致整個計算端被阻塞住。

而 Aurora 則打破了這個屏障。Aurora 的計算端可以直接向儲存端傳送寫請求，並不要求儲存端節點之間達成任何的 Consensus。

典型的 Aurora 例項包含 6 個儲存節點，分散在 3 個 AZ 中。每個儲存節點都維護了 Log 的列表，以及 Segment Complete LSN（SCL），也就是已經持久化的 LSN。儲存節點會將 SCL 彙報給計算節點。計算節點會在 6 個節點中，找出 4 個最大的 SCL，並將其中最小的值作為 Protection Group Complete LSN（PGCL）。而 PGCL 就是 Aurora 例項已經達成 Consistency Point。

看上去好像和 Multi-Paxos 也有些相似？是的，但 Aurora 並不要求儲存節點之間達成任何的 Consensus，發生故障的時候，儲存節點不需要參與 Leader Election，也不需要等待所有的日誌複製完成。這意味著計算節點基本上永遠不會被阻塞。

Aurora 的精妙之處在於把 Distributed Consensus 從儲存節點中抽離出來了，儲存節點只是單純的負責儲存工作就好了，而 Consensus 由計算節點來完成。那這樣看上去好像又和 PacificA 很相似？是的，我認為在整體思路上，Aurora 和 PacificA 是非常相似的。我個人認為 Consensus 和儲存節點的解耦會是未來的一個趨勢。

除了 Aurora 以外，Remzi 團隊在 FAST 2020 上的 Best Paper：“Strong and Efficient Consistency with Consistency-Aware Durability”，我認為也是非常有意思的一篇文章。

通常來說，我們在考慮 Consistency 的時候，都會結合 Durability 一起考慮。需要 Strong Consistency，就會用 Distributed Consensus，或者其他的 Replication 方式完成一次 Quorum Write，保證了 Strong Consistency 的同時，也保證了 Durability，代價就是效能差；如果只需要 Weak Consistency，那麼就不需要立刻完成 Quorum Write，只需要寫一個副本就可以了，然後再非同步完成資料同步，這樣效能會很好，但是由於沒有 Quorum Write，也就喪失了 Durability 和 Consistency。所以大家一直以來的一個共識，就是 Strong Consistency 效能差，Weak Consistency 效能好。

那有沒有一種方法既能保證 Strong Consistency，同時又保證 Performance 呢？Remzi 在這篇論文中提出了 “Consistency-Aware Durability”（CAD）的方法，把 Consistency 和 Durability 解耦，放棄了部分 Durability，來保證 Strong Consisteny 和 Performance。實現的方法可以用一句話總結，就是 Replicate on Read。

在 Strong Consistency 中，有一個很重要的要求就是 Monotonic Reads，當讀到了一個新版本的資料後，再也不會讀到老版本的資料。但換一個角度思考，如果沒有讀發生，是不存在什麼 Monotonic Reads 的，也就不需要做任何為了為了保證 Consistency 的工作（是不是有點像薛定諤的貓？）。

我們在寫時做 Replication，完全是為了保證 Durability，順便完成了保證 Consistency。如果我們可以犧牲 Durability，那麼在寫入時，我們完全不需要做 Replication，寫單複本就可以了。我們只需要在需要 Consistency 的時候（也就是讀的時候）完成 Consistency 的操作就可以了（也就是 Replication）。所以我把這種方法叫做 Replicate On Read。

如果你的應用程式屬於寫多讀少的，那麼這種方法就可以避免了大量無用的 Replication 操作，僅在必要的時候執行 Replication，也就是讀的時候。這樣既保證了 Strong Consistency，又保證了 Performance。真是不得不佩服 Remzi，把 Consensus，Consistency，Durability 研究的太透徹了。

可能做系統的同學覺得犧牲 Durability 好像不可接受，但是在類似網際網路應用的場景中，一些臨時資料的 Durability 其實是不太重要的，而 Consistency 才是影響體驗的核心因素。我們以叫車舉例，如果你看到司機距離你的位置一開始是 1 公里，然後忽然又變成了 3 公里，這很可能是後臺的 NoSQL 資料庫發生了一次故障切換，而從節點中儲存的資料是一個老資料，導致破壞了 Monotonic Reads。而司機位置這種資料是完全沒有必要保證 Durability 的，那麼在這種情況下利用比較小的代價來保證 Monotonic Reads，將極大地改善使用者的體驗，你會看到司機和你的距離會越來越近，而不是忽遠忽近。

另外再推薦給大家兩篇論文，一篇是 Raft 作者 John Ousterhout 大神的新作 “Exploiting Commutativity For Practical Fast Replication”，還有一篇是用 Raft 實現 Erasure Code “CRaft: An Erasure-coding-supported Version of Raft for Reducing Storage Cost and Network Cost”。有興趣的同學可以自己看一下，這裡我就不做介紹了。

Distributed Shared Memory and Heterogeneous computing

在開始之前，我們首先來回顧一下計算機的發展歷史。到今天為止，主流的計算機都是在馮諾依曼架構下發展的，一切的設計都圍繞著 CPU、記憶體進行。當 CPU、記憶體的能力不足時，就透過匯流排（Bus），不斷地對他們的能力進行擴充套件，例如磁碟、GPU 等等。隨著 CPU 速度不斷升級，匯流排的速度也在不斷地升級，以匹配 CPU 的運算速度。同時，為了安全高效的完成 CPU 以及外設之間的通訊，產生了例如 DMA、IOMMU 等技術。而匯流排受限於物理條件，通常只能進行非常短距離的通訊，CPU 能直接訪問的所有的裝置都需要整合在主機板上，也就是我們今天看到的主機。

在早期 CPU 的處理能力還非常弱的時候，單個 CPU 無法勝任大規模計算任務。這個時候出現了兩種發展的流派，一種是 Shared Memory，也就是在單機內擴充套件 CPU 的數量，所有 CPU 都共享相同的記憶體地址空間；另一種是 Distributed Memory，也可以理解為多機，每臺機器的 CPU 有獨立的記憶體和獨立的地址空間，程式之間透過 Message-Passing 的方式進行通訊。Shared Memory 技術對於硬體的要求較高，需要在處理器之間實現 Cache Coherence，而軟體層面的改動較為容易，早期的典型代表就是 Mainframe Computer，也就是俗稱的大型機；而 Distributed Memory 則對硬體的要求較低，但是軟體需要採用 Message-Passing 的方式進行重寫，例如早年的 MPI 類的程式，主要應用在 HPC 領域。由於 Mainframe 的硬體成本太高，MPI 逐漸成為了主流。

在上世紀八九十年代的時候，曾經流行了一陣 Distributed Shared Memory（DSM）技術，也就是分散式共享記憶體。DSM 透過作業系統的記憶體管理系統把各個獨立伺服器上的記憶體地址連線到一起，組成連續的記憶體地址，使得應用程式可以更方便的做資料共享。但 DSM 技術一直沒有發展起來，主要是受限於不斷提升的 CPU 頻率和當時的網路速度越來越不匹配，導致 DSM 的通訊成本過高，無法被普及。

到了 2000 年以後，CPU 的發展逐漸遇到瓶頸，單核計算效能已經不再可能有大的突破，CPU 逐漸轉向多核方向發展，個人電腦也用上了 Shared Memory 技術。而隨著大資料對算力和儲存能力的要求，Distributed Memory 技術也越來越廣泛地被使用，例如 MapReduce 和 Spark 這種計算框架就是典型的代表。

到了最近幾年，CPU 速度依然沒有明顯的突破，但網路速度卻在發生翻天覆地的變化。包括 IB 和乙太網都可以達到 200Gb 的頻寬和 us 級別的延遲（據說目前已經在制定 800Gb 的技術標準），以及 RDMA 技術的普及，使得 DSM 技術又再次被大家提起。

OSDI ‘18 的 Best Paper “LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation” 就是一種 DSM 系統，只不過除了 CPU 和記憶體外，LegoOS 還包括了對儲存的討論。在論文中，作者把 CPU、Memory 和 Storage 分別抽象為 pComponent、mComponent 和 sComponent，這些裝置之間透過 RDMA 網路連線在一起。LegoOS 向使用者提供了 vNode 的概念，每個 vNode 類似一個虛擬機器，可以包含一個或多個 pComponent，mComponent 和 sComponent。而每個 Component 同時也可以服務於多個 vNode。LegoOS 會負責對資源的隔離。由於具有統一的記憶體地址空間，且相容 POSIX 介面，應用程式不需要被改寫就可以執行在 LegoOS 上。

LegoOS 是一個非常不錯的想法，但我認為在實現上會面臨著非常巨大的挑戰，一方面由於大部分的功能都需要依賴軟體來實現，延遲可能會受到一定的影響，另一方面是 LegoOS 沒有采用 Cache Coherence 的模型，而是用了 Message-Passing 的方式在各個 Component 之間進行通訊。Message-Passing 可能是更優雅設計方案，但是如果真的想要在工業界中實現 LegoOS 這種思想，硬體廠商有需要根據 Message-Passing 來重新設計 Driver，這對於已有的硬體生態來說恐怕是很難接受的。

在工業界中，儘管目前還沒有看到 DSM 的成功案例，但是目前已經開始看到一些相關的技術出現。這裡我們會重點關注一下匯流排（Bus）技術。

最近幾年，異構計算（heterogeneous computing）變得越來越常見，CPU 透過 PCIe 匯流排和 GPU、FPGA 等異構計算單元進行通訊。而由於 PCIe 匯流排誕生時間較早，不支援 Cache Coherence，所以為編寫異構計算的應用程式帶來了極大的複雜度。例如應用程式想要在 CPU 和 GPU 之間共享資料，或者 GPU 和 GPU 之間共享資料，必須自行處理可能產生的 Cache 一致性問題。

為了適應逐漸增加的異構計算場景，各個廠商開始籌劃推出新的匯流排技術，這包括：

來自 Intel 的 Compute Express Link（CXL）
來自 IBM 的 Coherent Accelerator Interface（CAPI）
來自 Xilinx 的 Cache Coherence Interconnect for Accelerator（CCIX）
來自 AMD 的 Infinity Fabric
來自 NVIDIA 的 NVLink

毫無例外，不同廠家的技術都提供了對 Cache Coherence 的支援，這正是 PCIe 匯流排所缺乏的，也是工業界所需要的。目前這場關於下一代匯流排的競爭還在進行中，但大家認為能笑到最後的恐怕還是 Intel 所支援的 CXL。

這裡我們只對 CXL 做一個簡單的介紹。

CXL 協議中定義了 3 種子協議：

CXL.io：不提供 Cache Coherence 的 IO 訪問，類似於目前的 PCIe 協議
CXL.cache：用於裝置訪問主存
CXL.memory：用於 CPU 訪問裝置記憶體

例如對於一個 GPU 裝置，可以透過 CXL 來進行 GPU 到 CPU，GPU 到 GPU 的資料交換。而由於 CXL 支援 Cache Coherence，這個過程將變得非常簡單，這無疑是一個重大的變化。而對於儲存裝置來說，CXL 使得 PMem 無論是作為持久化記憶體還是易失性記憶體，都可以不僅僅侷限在記憶體匯流排，而是可以透過 CXL.memory 和 CPU 進行通訊。這意味著 PMem 未來不僅僅可以提供類似目前 NVMe 裝置的熱插拔功能，還可以擺脫記憶體匯流排對散熱和功耗的限制。甚至更進一步，未來可能會出現 CXL over Fabric 的技術，CPU 可以透過 CXL 協議訪問遠端記憶體。

CXL 1.0 將採用和 PCIe Gen5 向相容的硬體標準，這樣一來硬體廠商不需要為適配不同協議而生產兩種不同介面的硬體裝置，統一採用 PCIe Gen5 的標準就可以了。如果在裝置協商階段發現對端支援 CXL 協議，那麼就可以採用 CXL 協議執行，否則可以採用 PCIe Gen5 執行。

CXL.cache 和 CXL.memory 組成了一個異構的 Shared Memory 系統，這對傳統的 Shared Memory 系統是一個極大的擴充套件，讓異構計算變得更加簡單。而 CXL over Fabric 可能會組成一個由硬體支援的 Distributed Shared Memory 系統，這將使 Memory-level Composable Infrastructure 成為可能。在未來的資料中心，很可能會出現專門用於池化記憶體的伺服器，CPU、記憶體像樂高一樣搭建起來將真正成為現實。而這一切都有可能在未來的 5~10 年內發生。

其他方面

Open-Channel SSD

Open-Channel SSD 我在之前的文章中也做過介紹。和兩年前相比，目前已經被很多雲廠商用起來了。相比於傳統 SSD，採用 Open-Channel SSD 的好處是可以定製 FTL，從而方便對特定的 Workload 進行最佳化。但 Open-Channel SSD 短期內恐怕只會被雲廠商採用，畢竟大部分使用者沒有定製 FTL 的需求，通用的 FTL 就已經足夠了。而隨著 SPDK 中加入了對 FTL 的支援，也許未來會有廠商選擇直接在使用者態執行 Open-Channel SSD。

LSM-Tree 最佳化

過去兩年這方面的進展也比較少，我看過唯一相關的論文，是在 FAST ’19 上的一篇論文：SLM-DB: Single-Level Key-Value Store with Persistent Memory，對 PMem 上執行 LSM-Tree 進行最佳化。目前隨著 IO 裝置的速度越來越快，大家都比較認可 LSM-Tree 已經從 IO Bound 轉移到 CPU Bound，LSM-Tree 的劣勢越來越明顯，這讓大家開始反思是否應該繼續使用 LSM-Tree 了。

Machine Learning and Systems

儘管兩年前開始有 Machine Learning For Systems 的相關工作，但是過去兩年一直沒有什麼實質性的進展，反倒是 Systems for Machine Learning 有一些和 GPU 任務排程相關的工作。

VirtIO without Virt

VirtIO 是專門為虛擬化場景設計的協議框架。在 VirtIO 框架下，可以支援各種不同裝置的虛擬化，包括 VirtIO-SCSI，VirtIO-BLK，VirtIO-NVMe，VirtIO-net，VirtIO-GPU，VirtIO-FS，VirtIO-VSock 等等。而 VirtIO 裝置虛擬化的功能一直都是由軟體來完成的，之前主要是在 Qemu 裡面，現在還有 VHost。而目前逐漸有硬體廠商開始嘗試原生支援 VirtIO 協議，把虛擬化的功能 Offload 到硬體上完成，這樣進一步降低 Host 上因虛擬化而產生的額外開銷。這也是 AWS Nitro 的核心技術之一，透過把 VirtIO Offload 給硬體，使得 Host 上的幾乎所有 CPU、記憶體資源都可以用於虛擬機器，極大的降低了運營成本。

Linux Kernel

目前 Linux Kernel 已經來到了 5.0 的時代，近期比較重要的一個工作就是 IO_URING。關於 IO_URING，我們之前在文章中也做過介紹。IO_URING 和一年前相比又有了巨大的進步，目前除了支援 VFS 以外，也已經支援 Socket，為了提高效能還專門寫了新的 Work Queue。IO_URING 的終極目標是 one system call to rule them all，讓一切系統呼叫變成非同步！

總結
回顧過去兩年，儲存領域還是有非常巨大的進展，我們正處在一個最好的時代。工業界的進展相對更讓人 Exciting 一些，非易失記憶體、CXL 協議、支援 VirtIO 的硬體等等，都可以說是開啟了一個新的時代。而學術界儘管也有一些不錯的 idea，但主要進展還是圍繞在一些老的方向上，急需出現一些開創性的工作。

就我們公司而言，未來的一個工作重點就是如何充分利用 PMem 的特性，提高儲存系統整體的效能。

如果你對文章的內容感興趣，歡迎留言評論。如果你想要從事儲存這個方向，也歡迎加入我們團隊~

作者介紹
@張凱(Kyle Zhang)，SmartX 聯合創始人 & CTO。SmartX 擁有國內最頂尖的分散式儲存和超融合架構研發團隊，是國內超融合領域的技術領導者。

2020 儲存技術熱點與趨勢總結

Persistent Memory（PMem）

Distributed Consensus and Consistency

相關文章