重大變化：從打孔機制到應用程序數據塊
NFS(即網絡文件系統)算得上是計算發展史上最為成功的兩大文件協議之一。從20世紀80年代的NFSv2到20世紀90年代深入人心的NFSv3，再到如今最新的NFS4.1標準——如果大家對NFSv4.1與pNFS(并行NFS)還不熟悉，那么不妨馬上了解一下——該協議的開發目的是為了滿足用戶需求以及數據訪問與處理方面的不斷變化。
數據存儲業務迎來了爆炸式增長。根據IDC公司的調查，2010年中全世界范圍內售出的開放式系統存儲容量接近1EB(即1000PB)。而2011年中一個季度所售出的的存儲容量就超過了2007年全年的總和。這樣的數據增長幅度無疑令人驚訝，那么是什么樣的需求推動了這種增長呢?顯然，我們所能看到的、對存儲消費行為推動力最大的趨勢正是近年來虛擬化與云計算的興起。二者都使海量數據在管理及處理方面變得更為簡便。
上述類型的需求也同時促使NFS標準根據新情況做出又一輪修改：NFSv4.2也就隨之誕生。NFSv4.1與pNFS相較于NFSv3，在安全性與可擴展性方面提升明顯，管理機制也有了長足進步。NFSv4.2還在最新展望中承諾為NFSv4.1用戶提供期待已久的多種功能——這些功能將令NFS不僅扮演“日常”協議的角色，更將成為一套虛擬化數據中心內部應用程序的首選分布式文件協議。
服務器端副本
虛擬化意味著計算的移動化趨勢。不再被局限于固定地點的固定物理硬件，操作系統與應用程序能夠以無縫方式人一臺服務器轉移到另一臺。但每套虛擬機在運作中都離不開主數據與輔助數據，這些數據在計算平臺發生轉換時也需要同時進行遷移。如今，客戶端需要從源數據服務器處讀取數據，并將這些數據直接轉寫到另一套目的數據服務器中，這種三路式聯網結構使得數據副本帶來潛在的成本支出與不必要的遷移行為。
服務器端副本(簡稱SSC)機制完全消除了復制操作這一過程。相反，它會根據客戶端要求從一臺數據服務器上讀取完整的文件乃至文件目錄，并通過客戶端將這些內容上傳至另一臺數據服務器，也就是說SSC允許目標服務器與源服務器之間直接通信。客戶端負責管理復制流程，但并不涉及數據的具體遷移工作。數據在不同的數據服務器之間直接傳輸，而SSC則消除了過去那些令人頭痛的高維護成本以及對帶寬要求極嚴的服務器-客戶端-服務器通路。另外，復制操作由于網絡原因發生擁堵的可能性也大幅降低。
空間預留保障
每當面臨數據存儲空間不足的情況，就拿塊硬盤填充進去，這樣的處理方式其實面臨著一大根本性障礙，即：每塊硬盤的購置、運行及管理都會在一定程度上提高運營成本。許多存儲系統管理員都已經敏銳地意識到，用戶常常會高估自己所需要的存儲容量;而且高估的程度往往超乎想象。多年以來，人們通過一系列高效技術創建起一整套巨大的虛擬存儲池，而構成這一龐大體系的正是無數小型物理存儲系統。
自動按需配置作為上述技術中的一員，為用戶提供了大量可直觀查看的存儲空間。雖然這種做法目前可謂司空見慣，但這種做法其實并不能完全應對快速增長的使用環境。舉例來說，兩位用戶在查看時可能發現自己還有50%的剩余空間：但實際上他們雙方都沒有那么多容量可用。
NFSv4.2中的空間預留保障功能將徹底扭轉這一局勢，無論是否采用按需配置策略，特定文件將始終擁有最大程度的可用空間。
打孔
盡管對特定類型數據的處理已經令人滿意，并保證了終端用戶始終能夠根據需求獲得足夠的存儲空間，但上述保障功能常常會大幅度拉低硬盤存儲機制的利用效率，導致管理員們的優化努力淪為泡影。
舉例來說，當管理程序創建一個虛擬磁盤文件時，它通常會嘗試為文件分配預留空間，這樣的虛擬機執行操作的過程中就不會發生分配沖突類錯誤。應用程序中的這類文件往往實際體積為零，這種情況必然導致I/O性能與存儲效率的大幅走低。
為了支持更高的存儲效率，NFSv4.2推出了一套專為稀疏文件排布打造的支持技術。這就是俗稱的“打孔”機制，即將文件中已被刪除或未被使用的部分送回存儲系統的空閑容量池中(如圖一所示)。
圖一：按需配置方案與打孔方案
按需配置方案移除了為那些永遠不會真正需要的存儲行為保留的空間，而真正的空閑容量就能夠為廣大用戶所使用。NFSv4.2的打孔方案則更進一步，通過對擁有預留空間的文件進行頻繁掃描找出無用數據，并將其預留空間釋放出來。而客戶端所查看到的結果并無變化：NFSv4.2能夠以透明化方式正確反饋剩余空間情況。
應用程序數據塊(簡稱ADB)
應用程序數據塊(簡稱ADB)延用了打孔機制中的零體積數據塊概念，支持應用程序將各種功能性模塊寫入數據塊。舉例來說，管理程序或數據庫應用程序通過向虛擬機鏡像或數據庫中寫入監控模塊以提供復雜的數據破損檢查功能。ADB允許這類應用程序在某個單獨文件中對這些數據塊進行定義，而NFSv4.2則能夠利用一套經過大幅度簡化的映射對其加以存儲，最終達到節約空間的目的。這事實上是一種消除重復數據的管理方式。
讓我們舉個簡單的例子。大家的應用程序可能會以利用十六進制字符串0xDEADBEEF寫入數據塊的方式對文件進行初始化。按理來說，初始化過程應該需要對文件中每一個數據塊都寫入以上內容。但ADB能夠從中“找到”規律，注意到該映射內數據塊存在的目的在于初始化，并決定不向塊中寫入內容。
當數據塊接收到一條讀取請求時，存儲系統能夠檢查對應文件的映射，并認定需要查詢的目標為初始化數據塊，進而自動將0xDEADBEEF這一結果發送至應用程序。顯然返回的結果能夠滿足應用程序的需求，同時整個過程中沒有涉及任何額外操作，這就顯著節約了存儲空間與I/O性能。
有了這項功能，NFSv4.2將能夠迅速高效地為數據存儲初始化節約空間;創建大型數據庫或是虛擬機鏡像的任務現在也完全能夠通過一次操作就徹底搞定。
應用程序I/O提示
隨著數據流通量的不斷飆升，I/O量自然也是水漲船高;與此同時，采用緩存或SSD的分層存儲系統也逐步令傳統的高速DRAM與低速硬盤之間的效率沖突趨于緩和。NFSv4.2為應用程序創造了一套通向底層存儲系統的數據通信訪問模式。舉例來說，數據的讀取是具備一定先后順序的，因此應該將讀取放在第一位。而有些數據的讀取及寫入過程往往會重復多次，因此考慮利用緩存保存這些常用數據。接下來，有些數據寫入比較頻率、但讀取次數很少，所以要保證這類數據不會進入緩存。
那么這一整套機制什么時候才會投付使用呢?
NFSv4.2規范很可能于今年3月份獲得批準，而客戶端及服務器供應商要花多長時間才能將這套機制部署到位，就完全取決于作為用戶的我們支持這一新技術的力度啦。
這就又帶來一個問題：你還在用NFSv3嗎?如果答案是肯定的，你所失去的不僅僅是NFSv4、NFSv4.1以及pNFS所擁有的那么多先進功能，更是無緣邂逅雄心勃勃、技術先進的NFSv4.2。至于原因嘛，只有一點——為了提高安全性，從NFSv3到NFSv4的升級中包含了一系列本質性“改造”，因此NFSv3無法與NFSv4的后續版本直接銜接。
盡管存在上述問題，不過距離NFSv4.2真正面世還有一段時間，大家不妨把握最后的機會，在新項目中盡管采用NFSv4及更新的協議，以準備迎接NFS家族中這位了不起的新成員。
