專利名稱：一種分布式文件系統客戶端的文件系統的制作方法
技術領域：
本發明涉及分布式文件系統中高效的元數據緩存管理機制，具體來說，涉及一種分布式文件系統客戶端的文件系統。
背景技術：
在目前的主流分布式文件系統，如NFS、Lustre、GPFS等，所有的模塊均處于Linux 內核態，由于內核態開發的難點比較多，因而相比較而言，這些文件系統的開發和維護的成本相對比較高。近幾年，一些新興的分布式文件系統，如Google FS、HDFS、M00SeFS等，均將各個部分放在用戶態，以降低開發難度。
對于基于用戶態的分布式文件系統，如果需要支持系統標準的文件系統操作， 則無法完全避開內核態，因為系統調用必須要先進入內核態。為了解決這一問題，HDFS、 MooseFS等采用了目前Linux內核自帶的用戶空間文件系統FUSE的架構進行客戶端的開發。
FUSE通過建立一個輔助設備和用戶態進行通信，通過將內核態系統調用的請求傳遞給用戶態，由用戶態的守護進程完成請求處理后，再通過輔助設備通知內核態。FUSE的不足之處在于，其和用戶態通信中有太多的內存拷貝，尤其是文件讀寫時，也需要通過數據拷貝，在內核態模塊和用戶態守護進程之間進行傳遞數據。過多的內存拷貝導致基于FUSE的客戶端效率低下，實驗結果表明，采用FUSE的客戶端，其性能損失在10%以上，因此在性能要求比較高的應用中，基于FUSE的分布式客戶端是難以被接受的。發明內容
本發明旨在公開一種高效的用戶態分布式文件系統客戶端方案，該方案能夠很好地解決目前Linux內核態自帶的用戶態文件系統FUSE性能低下的問題。
一種分布式文件系統客戶端的文件系統，
內核態模塊注冊一個字符設備，用戶態守護進程通過系統讀寫調用來訪問該字符設備，來讀取請求以及返回請求執行的結果；
所述內核態模塊采用頁面的方式管理文件系統請求，當收到文件系統相關請求時，先將文件系統的請求加入到自定義的請求緩存管理區；
所述用戶態的守護進程會有線程采用阻塞時讀取的方式，一直嘗試讀取請求，如果請求緩存區中沒有有效的請求，則守護進程的讀線程會一直阻塞；當內核態模塊接收到文件系統請求后，會將守護進程的讀線程喚醒。
優選的，所述讀線程被喚醒后，會在內核態將文件系統請求緩存區的相關頁面映射到該進程用戶態可以訪問的虛擬地址，為其分配管理結構，將地址填到該管理結構中，并通過讀系統調用傳遞給用戶態守護進程，用戶態守護進程讀取到管理結構后，會從中取出相應的文件系統請求，進行處理。
優選的，所述管理結構分為兩種，一種是文件系統請求，該類請求是變長的，來自分布式文件系統客戶端的應用程序；另一種是管理請求，該類請求是文件系統請求的管理結構，用于在內核態模塊和用戶態守護進程之間傳遞消息。
優選的，所述用戶態處理完請求后，會將處理結果填充到由內核態模塊傳遞過來的虛擬地址當中，通過字符設備的寫系統調用通知內核態目錄，內核態模塊收到該寫請求后，會取出管理結構，并從中取出文件系統請求，直接拷貝給應用程序。
優選的，所述文件系統對于文件的讀寫，還需要將文件頁面緩存中相關的頁面映射到進程的虛存空間，并通過請求結構傳遞給用戶態守護進程，用戶態進程收到請求后，會直接操作文件的頁面緩存，將文件緩存頁面直接映射。
本發明中，客戶端由內核態模塊和用戶態守護進程兩部分組成。這兩個模塊通過字符設備進行通信，但是和FUSE的不同點在于，內核態在與用戶態通信之前，會將需要的內存頁面準備好，并映射為用戶態可以訪問的虛擬地址，將虛擬地址作為通信的一部分，傳遞給用戶態守護進程。這樣以來，用戶態進程就可以直接操作內核態事先準備好的內存區域，而不需要再進行內存分配，同時避免了用戶態和內核態之間的內存拷貝。
具體實施方式
發明中的技術方案具體描述如下
(1)內核態模塊注冊一個字符設備，用戶態進程通過系統讀寫調用來訪問該字符設備，來讀取請求以及返回請求執行的結果。
(2)本發明中請求的管理結構分為兩種，一種是文件系統請求，該類請求是變長的，來自分布式文件系統客戶端的應用程序；另一種是管理請求，該類請求是文件系統請求的管理結構，用于在內核態模塊和用戶態守護進程之間傳遞消息。
(3)內核態模塊采用頁面的方式管理文件系統請求，當收到文件系統相關請求時， 先將文件系統的請求加入到自定義的請求緩存管理區。用戶態的守護進程會有一個專門的線程采用阻塞時讀取的方式，一直嘗試讀取請求。如果請求緩存區中沒有有效的請求，則守護進程的讀線程會一直阻塞。
一旦內核態模塊接收到文件系統請求后，會將守護進程的讀線程喚醒。當讀線程被喚醒后，會首先在內核態將文件系統請求緩存區的相關頁面映射到該進程用戶態可以訪問的虛擬地址，為其分配管理結構，將地址填到該管理結構中，并通過讀系統調用傳遞給用戶態守護進程。用戶態守護進程讀取到管理結構后，會從中取出相應的文件系統請求，進行處理。
當用戶態處理完請求后，會將處理結果填充到由內核態傳遞過來的虛擬地址當中，通過字符設備的寫系統調用通知內核態目錄。內核態收到該寫請求后，會取出管理結構，并從中取出文件系統請求，由于之前用戶態進程已經將處理結果填充到了文件系統請求緩存區，因此可以直接拷貝給應用程序了。
通過在內核態模塊中作虛擬內存映射的方式，避免了在內核態和用戶態頻繁地拷貝文件系統請求。
(4)對于文件的讀寫，為了避免文件內容的拷貝，除了需要映射請求本身，還需要將文件頁面緩存中相關的頁面映射到進程的虛存空間，并通過請求結構傳遞給用戶態守護進程。用戶態進程收到請求后，會直接操作文件的頁面緩存，避免了大量內存拷貝。將文件緩存頁面直接映射，使用戶態進程直接操作文件的頁面緩沖，是本發明在性能上能夠超越 FUSE的主要原因。
權利要求
1.一種分布式文件系統客戶端的文件系統，其特征在于內核態模塊注冊一個字符設備，用戶態守護進程通過系統讀寫調用來訪問該字符設備，來讀取請求以及返回請求執行的結果；所述內核態模塊采用頁面的方式管理文件系統請求，當收到文件系統相關請求時，先將文件系統的請求加入到自定義的請求緩存管理區；所述用戶態的守護進程會有線程采用阻塞時讀取的方式，一直嘗試讀取請求，如果請求緩存區中沒有有效的請求，則守護進程的讀線程會一直阻塞；當內核態模塊接收到文件系統請求后，會將守護進程的讀線程喚醒。
2.如權利要求1所述的文件系統，其特征在于所述讀線程被喚醒后，會在內核態將文件系統請求緩存區的相關頁面映射到該進程用戶態可以訪問的虛擬地址，為其分配管理結構，將地址填到該管理結構中，并通過讀系統調用傳遞給用戶態守護進程，用戶態守護進程讀取到管理結構后，會從中取出相應的文件系統請求，進行處理。
3.如權利要求1所述的文件系統，其特征在于所述管理結構分為兩種，一種是文件系統請求，該類請求是變長的，來自分布式文件系統客戶端的應用程序；另一種是管理請求，該類請求是文件系統請求的管理結構，用于在內核態模塊和用戶態守護進程之間傳遞消息。
4.如權利要求2所述的文件系統，其特征在于所述用戶態處理完請求后，會將處理結果填充到由內核態模塊傳遞過來的虛擬地址當中，通過字符設備的寫系統調用通知內核態目錄，內核態模塊收到該寫請求后，會取出管理結構，并從中取出文件系統請求，直接拷貝給應用程序。
5.如權利要求1所述的文件系統，其特征在于所述文件系統對于文件的讀寫，還需要將文件頁面緩存中相關的頁面映射到進程的虛存空間，并通過請求結構傳遞給用戶態守護進程，用戶態進程收到請求后，會直接操作文件的頁面緩存，將文件緩存頁面直接映射。
全文摘要
本發明提供了一種分布式文件系統客戶端的文件系統。本發明中，客戶端由內核態模塊和用戶態守護進程兩部分組成。這兩個模塊通過字符設備進行通信，但是和FUSE的不同點在于，內核態在與用戶態通信之前，會將需要的內存頁面準備好，并映射為用戶態可以訪問的虛擬地址，將虛擬地址作為通信的一部分，傳遞給用戶態守護進程。這樣以來，用戶態進程就可以直接操作內核態事先準備好的內存區域，而不需要再進行內存分配，同時避免了用戶態和內核態之間的內存拷貝。
文檔編號G06F17/30GK102541984SQ20111032644
公開日2012年7月4日 申請日期2011年10月25日 優先權日2011年10月25日
發明者劉新春, 張東陽, 楊浩, 王勇, 苗艷超, 邵宗有, 馬振杰, 馬照云 申請人:曙光信息產業(北京)有限公司