Octopus
Software限制了NVM和RDMA的效能
Background And Motivation
Software Overhead：
在配備了NVM和RDMA啟用網路的儲存系統中，硬體提供的效能要比傳統裝置高得多。相比之下，軟體層的開銷現在佔整個系統的很大一部分。
Copying Overhead：
資料在記憶體的多個位置進行多次複製，包括使用者緩衝區、檔案系統頁面快取和網路緩衝區。雖然這種設計對於低速磁碟和網路構建的檔案系統是可行的，但對於高速硬體，它對系統性能有重大影響。
CPU Overhead：
當網路變得更快時，伺服器端CPU很容易成為處理來自許多客戶機的請求的瓶頸。
RPC Overhead：
在硬體提供低延遲通訊時，基於事件驅動模型的傳統RPC具有相對較高的通知延遲。
Transaction Overhead：
分散式檔案系統在處理分散式事務時，由於多重網路往返和複雜的處理邏輯，造成了巨大的一致性開銷。
Architecture
Octopus是為一組配備非易失性儲存器和rdma網路的伺服器而設計的。Octopus由兩部分組成：客戶端和資料伺服器，它沒有集中的元資料伺服器，元資料分佈在不同的資料伺服器上。在Octopus中，檔案以基於雜湊的方式分發到資料伺服器，如上圖所示。一個檔案的元資料和資料塊在同一個資料伺服器中，但是它的父目錄和它的兄弟目錄可能被分發到其他伺服器。在每個伺服器中，資料區域在整個叢集中共享，以便進行遠端直接資料訪問，而元資料區域出於一致性的原因保持私有。
Design
Design1- Client-Active I/O
設計原因：
傳統的Server-Active Data I/O模型中，伺服器始終處於高利用率，並在配備新硬體時成為瓶頸，需要降低伺服器端CPU的開銷。
設計：
使用RDMA單邊原語，可以在不參與遠端伺服器中CPU的情況下訪問遠端資料，因此可以透過引入有限的網路往返，伺服器負載可以分擔給客戶端，從而可以提高併發請求的吞吐量。具體流程如下所示：
客戶端向伺服器傳送讀取/寫入請求；
服務端將元資料傳送回客戶端；
客戶端使用返回的元資料資訊，直接使用RDMA的單邊原語讀取或寫入檔案資料
Design2- Self-identified metadata RPC
設計原因：
基於訊息的RPC具有相對較高的延遲和較低的吞吐量。而基於記憶體RPC，伺服器需要輪詢訊息緩衝區，帶來較高的CPU消耗。
設計：
Self-identified的元資料RPC使用帶有imm的RDMA寫入命令將發件人的識別符號與RDMA寫入請求附加在一起。使用imm進行RDMA寫入會消耗來自遠端佇列對（QP）的一個接收請求，因此在請求到達後立即進行處理。immediate欄位中附加的識別符號可幫助伺服器直接定位新訊息，而無需掃描整個緩衝區。請求處理完成之後，伺服器使用RDMA寫操作將資料返回到節點ID客戶端中指定的偏移量地址。
Design3：Collect-Dispatch Transaction
設計原因：
單個檔案系統操作（例如mkdir，mknod）可能需要透過分散式事務在多個伺服器原子地更新元資料。但是2PC由於其分散式的日誌記錄以及對鎖和日誌永續性的協調而導致高昂的開銷。
設計：
在收集階段，Octopus從參與者收集讀和寫集，並在協調器中執行本地事務執行和本地日誌記錄。由於參與者不需要保留日誌記錄，因此無需為協調器和參與者之間的日誌永續性進行復雜的協商，從而減少了協議的開銷。另外，協調器使用GCC CAS釋放本地鎖定，但使用RDMA CAS釋放每個參與者的遠端鎖定。RDMA解鎖操作不涉及參與者的CPU處理，因此簡化了解鎖階段。
總體而言，Collect-Dispatch Transaction需要一個RPC，一個RDMA Write操作和一個RDMA原子操作，而2PC則需要兩個RPC。Collect-Dispatch仍然具有較低的開銷，因為（1）RPC比RDMA寫入/原子原語具有更高的延遲，（2）RDMA寫入/原子原語不涉及遠端端的CPU處理。
Evaluation
上圖顯示了Octopus的單次往返延遲和頻寬分解。Octopus中的軟體延遲尾6us（約佔總延遲的85％）。同時Octopus可達到接近原始網路頻寬的讀/寫頻寬。原始儲存和網路頻寬分別為6509MB/s（帶單執行緒記憶體）和6350MB/s，Octopus實現的讀/寫（6088/5629MB/s）頻寬為網路頻寬的95。9％/88。6％，因此，Octopus可以有效地利用硬體頻寬。
others
在Octopus中，元資料的一致性由collect-dispatch事務保證，該事務使用clflush將資料從CPU快取重新整理到記憶體以強制保留日誌。儘管可以使用collect-dispatch事務來提供資料一致性，但是為了提高效率，在當前的Octopus實現中，資料I/O並未包裝在事務中，資料的一致性不能得到保證。
