[go: up one dir, main page]

TWI476610B - 同級間冗餘檔案伺服器系統及方法 - Google Patents

同級間冗餘檔案伺服器系統及方法 Download PDF

Info

Publication number
TWI476610B
TWI476610B TW098113958A TW98113958A TWI476610B TW I476610 B TWI476610 B TW I476610B TW 098113958 A TW098113958 A TW 098113958A TW 98113958 A TW98113958 A TW 98113958A TW I476610 B TWI476610 B TW I476610B
Authority
TW
Taiwan
Prior art keywords
storage
file
node
client
server
Prior art date
Application number
TW098113958A
Other languages
English (en)
Other versions
TW201007489A (en
Inventor
Francesco Lacapra
Peter Wallace Steele
I Chung Joseph Lin
Bruno Sartirana
Ernest Ying Sue Hua
Samuel Sui-Lun Li
Nathanael John Diller
Thomas Reynold Ramsdell
Don Nguyen
Kyle Dinh Tran
Original Assignee
Maxiscale Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Maxiscale Inc filed Critical Maxiscale Inc
Publication of TW201007489A publication Critical patent/TW201007489A/zh
Application granted granted Critical
Publication of TWI476610B publication Critical patent/TWI476610B/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Description

同級間冗餘檔案伺服器系統及方法
本發明係有關於大型電腦(large scale computer)檔案儲存，更有關於使用同級間技術儲存大量電腦檔案以對這些檔案提供可擴充、可靠並且有效率的磁碟操作。
網際網路通常透過用戶端伺服器通訊模式提供服務，例如電子郵件、瀏覽網頁、遊戲、檔案傳送等等。根據用戶端伺服器模式，伺服器電腦提供網際網路服務至其他電腦(用戶端)。常見的伺服器包含郵件伺服器以及網路伺服器。伺服器與用戶端電腦進行通訊以傳送資料並執行用戶端所請求的動作。電腦可以作為用戶端或伺服器。例如，網路伺服器可與其他電腦連接而將其時脈同步。在此實施例中，提供時脈資料的電腦為時脈伺服器，且該請求電腦為時脈用戶端以及網路伺服器。
一般來說，服務提供者(例如網站)會建立與製造可取得的內容給人們使用。網站通常按照此模式包含，新聞網站(例如CNN.com或BBC.co.uk)，提供零售銷售的網站(例如Amazon.com或BestBuy.com)以及具有索引搜尋資料得搜尋引擎(例如Google.com或MSN.com等等)。然而其中所呈現的使用模式為服務使用者(而非服務提供者)產生內容給其他使用者使用。在此”Web 2.0”模式中，服務提供者操作內容建立伺服器並且邀請使用者建立或上傳內容。此模式的範例包含部落格提供者(例如Blogger.com)，新聞聚合器(news aggregator)(例如Digg.com與Reddit.com)，以及影音分享網站(例如YouTube.com)。某些網站為兩者之間的混合，其中網站管理提供主題讓使用者評論。混合網站的例子為技術新聞討論網站Slashdot.org，其中可從其他網站選取新聞報導來評論。傳統網站產生內容似乎轉變為這樣的混合網站。新聞網站MSNBC.com可允許讀者對發表的新聞報導進行評論。
網際網路的基礎結構必須改善來適應傳統用戶端伺服器模式的改變。傳統服務提供者可以為商業用途，具有有限的人員在任何既定時間範圍內建立與公佈相對小部分的內容。然而，藉由使用者產生內容可以在相同時間範圍內建立大量資料。因此，當必須處理與儲存的資料量以指數方式成長時，伺服器基礎結構可能遭遇到可擴充性的問題。當技術限制因為容量增加而造成儲存裝置之成本對容量比值的增加時，購買較大資料儲存裝置可能會非常昂貴。服務提供者可尋求更有成本效益的方法來儲存資料，包含購買大量具有小儲存容量的儲存裝置。這樣的小裝置叢集(cluster)為熟悉此技藝之人士所瞭解的。例如，發展技術來控制廉價磁碟(RAID)的冗餘陣列。另外，服務提供者可能會需要儲存解決方案與其現存電腦基礎結構(而非所購買的現成系統)緊密結合。服務提供者亦可能需要處理資料儲存中斷的能力。RAID系統可提供這些優點，然而，服務提供者可能需要具成本效益的儲存系統來支援與維持。RAID系統通常比較昂貴、複雜並且需要相當大的專門技能與耐心來管理。
儲存系統係將其資料設置於檔案系統內。檔案系統(filesystem)是一種在儲存系統中儲存與組織電腦檔案的系統，以便輕易的尋找與存取檔案。檔案(file)為資料的集合。第1圖顯示例如在UNIX模式中的傳統檔案系統目錄樹(directory tree)。檔案系統中的檔案會被組織為目錄。在Unix中的目錄為一檔案類型，在此實施例中為包含關於其他檔案資訊的檔案。目錄可能代表資料檔案與其他目錄，目錄可嵌入於其他目錄內。因此，檔案系統具有類樹狀結構，其中美個目錄作為分支(branch)。依此類推，一般資料檔案作為樹狀結構的葉(leaf)。像是一棵樹，每個檔案系統具有根部(root)，根目錄110。第1圖中的根目錄110包含兩個目錄120與122(分支)以及一檔案124(葉)。目錄120具有兩個檔案130與132，而目錄122具有三個檔案與一個子目錄(subdirectory)140。
藉由指定從根目錄110到檔案的路徑可以存取檔案系統中的所有檔案。例如，檔案150在檔案系統中的位置係取決於從根目錄110至目錄122至目錄140至檔案150的路徑。路徑通常是由中間檔案名稱的串聯來表示，檔案名稱之間以特殊字元隔開。Unix系統的慣例表示法係以向前斜線(forward slash)/作為路徑分隔符號，而Microsoft的Windows系統可使用不同的路徑分隔符號。根目錄110具有特殊名稱/。因此，若目錄如第1圖的標籤命名，檔案150具有路徑/122/140/150。而在Windows的路徑表示法為C：\122\140\150，其中C：\為根目錄的名稱。
第2圖顯示對設置於檔案系統目錄樹內的檔案執行各種操作的方塊圖。檔案操作主要有四種類型：建立檔案(file creation)、讀取資料(reading data)、更新資料(updating data)以及刪除檔案(file deletion)。該四種操作稱為CRUD操作，提供任何儲存系統所需要的核心功能。作業系統設計師對這些主要操作提供額外操作。例如，軟體開發者來說，連續參考每個檔案操作的檔案全路徑是不方便的。因此，作業系統可在執行四個主要操作之任一者之前提供開啟(open)檔案的能力(也就是初始關於檔案的某些資料，包含檔案路徑)。同樣的，作業系統可以在不需要存取檔案時提供關閉(close)檔案的能力來釋放系統資源。CRUD與支援操作定義了檔案系統的能力。POSIX(Portable Operating System Interface)工業標準(IEEE 1003 ISO/IEC 9945)同樣也定義了這些操作。
不同的檔案系統設計者可能會希望實現不同的檔案系統能力。例如，某些檔案系統支援非常大的檔案。某些檔案系統支援檔案操作紀錄，可重複播放檔案操作紀錄以確保系統失效時的資料一致性。某些檔案系統將資料儲存至網路而非儲存在本地點腦的硬碟中。具有不同能力之檔案系統的例子包含Windows NT檔案系統NTFS、通用網際網路檔案系統(Common Internet File System,CIFS)、Unix檔案系統UFS2、Sun Microsystem ZFS與網路檔案系統(Network File System,NFS)、Linux檔案系統EXT與ReiserFS等等。這些檔案系統皆實現各種檔案系統CRUD與支援操作。因此，NTFS檔案系統210實現開啟功能(open)212來開啟檔案，關閉功能(close)214來關閉已開啟的檔案，讀取功能(read)216來讀取已開啟檔案的資料，寫入功能(write)218來將資料寫入已開啟檔案等等。同樣的CIFS檔案系統230實現開啟功能(open)232、關閉功能(close)234、讀取功能(read)236以及寫入功能(write)238。然而，這些檔案系統與包含存取本地硬碟220操作的NTFS檔案系統210不同，CIFS檔案系統230包含存取網路240(例如區域網路(local area network,LAN))的操作。在CIFS檔案系統230中，網路240係連接至具有儲存檔案資料的硬碟260之檔案伺服器250。CIFS檔案系統230建立包含指令的網路訊息(例如從檔案F讀取一千位元組的資料)並將其傳送至檔案伺服器250。檔案伺服器250接收網路訊息，並將其翻譯為本身檔案系統的請求(其中可能會存取硬碟260)。一旦完成請求，檔案系統250建立響應網路訊息並透過網路240將其回傳至CIFS檔案系統230。然而，在支援CIFS的電腦上所執行的軟體應用程式可使用讀取功能(read)236而不需要考慮基礎網路通訊的細節。除了NTFS與CIFS之外的檔案系統在實現上並不相同，但是所有POSIX適用的檔案系統提供至少相同的最小檔案系統CRUD與支援操作。
電腦可同時支援各種不同的檔案系統。然而，此能力會引起一個問題。不論檔案儲存在任何檔案系統中，使用者需要統一的方法來指出檔案。如上所述，指出檔案的範例方法為使用檔案路徑。然而，需要一種方法來辨識兩檔案系統的兩種不同根目錄，不可以兩者皆命名為/。此問題的一般解決方法為將一檔案系統樹依附至另一者，該處理步驟稱為鑲嵌(mounting)。拆卸兩檔案系統樹的反相處理步驟稱為卸除(unmounting,dismounting)。
第3圖顯示包含於檔案系統鑲嵌操作中兩檔案系統目錄樹之間的關係。在鑲嵌操作中，檔案系統之一者作為樹的根目錄，稱為根檔案系統(root filesystem)。一般來說，根檔案系統將會是存取本地硬碟的檔案系統。在第3圖的實施例中，根檔案系統310為NTFS檔案系統210，具有存取本地硬碟382的相關NTFS檔案系統操作。而另一檔案系統稱為已安裝檔案系統(mounted filesystem)。在此，已安裝檔案系統340為CIFS檔案系統230，具有相關CIFS檔案系統操作。
如上所述，根檔案系統310具有一些檔案：目錄A330、目錄B332、目錄C334一直到目錄Z336等等。如圖所示，這些目錄具有子目錄並包含檔案。檔案系統使用者選取這些目錄之一者(例如336)作為依附點(又叫做鑲嵌點(mount point))。使用者接著使用作業系統指令將檔案系統340鑲嵌至此目錄，例如Unix的mount命令。在執行鑲嵌之前，目錄路徑/Z代表目錄336。在執行鑲嵌之後，鑲嵌目錄350取代檔案系統樹中的目錄336，因此目錄路徑/Z現在代表目錄350而不是目錄336。由於沒有指向目錄336的路徑，因此包含於目錄336中的任何檔案(例如檔案338)目前皆無法存取。基於此理由，通常選擇空目錄作為鑲嵌點，也可能會為了這個目的而特別建立空目錄。典型的Unix實施例為目錄/mnt。一個檔案系統可同時鑲嵌多個檔案系統。因此，若多個檔案系統要鑲嵌至/mnt，則/mnt可以為空目錄或是包含幾個空的子目錄來作為鑲嵌點。
根據本發明實施例，在鑲嵌檔案系統340之前，目錄Z 336是空目錄。在執行鑲嵌之後，目錄/Z目前包含兩個子目錄，/Z/D1與/Z/D2。路徑/Z/D1代表包含根目錄320、鑲嵌點/Z(這代表第二檔案系統的根目錄350)以及目錄360的路徑。根據本發明另一實施例，檔案370與372在分別使用路徑/Z/D2/F1與/Z/D2/F2(透過目錄D2 362)執行鑲嵌之後便可取得。當使用者完成之後，可透過umount命令來卸除兩檔案系統。一旦卸除第二檔案系統，則可透過檔案(例如檔案338)再次存取作業系統。
用於既定檔案的檔案操作取決於檔案所在的檔案系統，依序由檔案路徑來判斷。例如，檔案331的路徑為/A/F2，設置於NTFS檔案系統中，因此對該檔案使用NTFS操作。這些操作根據NTFS的設計存取個人的本地硬碟382。然而，檔案372的路徑為/Z/D2/F2，其橫跨(cross)鑲嵌點/Z，因此對該檔案使用CIFS檔案操作。這些操作透過LAN 392傳送CIFS訊息至其他電腦394。電腦394支援CIFS並包含檔案系統340的根目錄350。電腦394接收請求並接著應用至檔案系統340。接著，再次開始對電腦394執行處理步驟。電腦394上的檔案路徑為/D2/F2，這可以視為僅從檔案系統340來看。電腦394根據此路徑判斷適當的檔案操作來執行，其本身尋找鑲嵌點。若/D2為檔案系統340的鑲嵌點，電腦394可將操作傳遞至其本地硬碟396或是傳遞至使用其他檔案系統類型的其他裝置。因此，電腦394的作業系統提供進一步的抽象等級。
檔案系統鑲嵌可用來增加網路伺服器可取得的檔案儲存空間量。因此，鑲嵌可用來緩和服務提供者在這方面的需求。一般來說有三種用來擴充儲存空間的例子：增加額外本地硬碟，鑲嵌網路附接儲存器(network-attached storage,NAS)，以及鑲嵌儲存區域網路(storage area network,SAN)。NAS為至少一僅用來儲存(且不用於任何其他應用)的硬碟裝置，可透過網路存取，可鑲嵌於使用標準網路檔案系統(例如CIFS或NFS)的電腦。在NAS之內，電腦將會辨識檔案的遠端特性，並將檔案操作轉換為格式化網路訊息。對SAN來說是相同的，除了遠端莊至使用適當檔案系統來鑲嵌之外，因此核心操作系統不會察覺檔案資料為遠端儲存的。
第一實施例增加了額外本地硬碟，但是並沒有良好的縮放。現代電腦僅具有有限數量的連結來依附額外的裝置。因此，此實施例通常不會用於非常大型的商業操作。
第二實施例需要鑲嵌NAS。NAS縮放良好的智慧型硬體，因此任何數量的裝置皆可形成NAS，並且可輕易的新增至現存設定。各種版本的Microsoft Windows皆限制鑲嵌檔案系統的數量。Unix系統通常不具有這樣的限制。對每個位元組來說，NAS通常也比SAN便宜。然而，由於CIFS與NFS對每個檔案操作存取遠端電腦，因此具有效能損失(performance penalty)。追蹤檔案路徑的處理步驟需要設置目錄、讀取其內容、設置下一目錄、讀取其內容等等直到設置最後的檔案。在NFS中，每個操作皆為網路存取。在接近頻寬飽和的大型網路中可藉由延遲NFS請求/回應對而造成使用困難。另外，NFS不會對故障狀態做良好的回應。例如，若具有NFS檔案系統的伺服器變得反應遲鈍，鑲嵌該檔案系統的用戶端可等待相當長的一段時間來完成NFS處理。在某些NFS應用中，此延遲可能會延伸至作業系統的其他部分，導致用戶電腦反應遲鈍。因此，NFS網路管理者對重新開啟電腦或指出故障狀態有特定的順序。
第三實施例需要鑲嵌SAN。SAN為專利權產品(proprietary product)，可採用各種不同的儲存裝置，使得電腦將其視為單一且大型的本地儲存單元。因此，SAN不需要依賴現成的協定CIFS或NFS。基於此理由，對產品來說，SAN提供者可提供比NAS提供者更好的支援，包含將其產品較佳整合至現存網路結構的服務。SAN通常比NAS更昂貴。每個SAN具有自己的方法來處理資料儲存中斷，且不同的廠商會提供不同的保證以及服務水準協議(service level agreement)。當然，使用SAN通常代表在適用SAN提供至應用面的區塊圖的裝置形式中出現媒介(例如在執行至少一協調用戶端之間存取與實現抽象的SAN用戶端軟體形式中，例如檔案、郵件儲存庫以及DBMS等等)。由於SAN與NAS裝置具有不同的固有能力，因此直接比較SAN與NAS裝置可能會產生誤解。
本發明實施例一種檔案儲存系統，用來處理包含路徑名稱的標準檔案系統請求。檔案儲存系統包含複數個儲存提供者以及一用戶端。用戶端係與儲存提供者進行通訊，接受檔案系統請求並產生對應至儲存提供者之已選取一者的再格式化請求，用戶端根據應用至路徑名稱之至少一部分的散列演算法來初始選取儲存提供者之已選取一者，因此用戶端係作為標準檔案系統請求與儲存提供者之間的介面。
在各種其他實施例中，每個儲存提供者可以為包含形成一組同級節點之複數個同級間電腦處理程序的一虛擬伺服器。指向特定虛擬伺服器的特定請求係遞送至虛擬伺服器的所有同級組節點，然而該同級組被組構為只有同級節點之一者來回應特定請求。每個同級節點可實現為耦接至不同微處理器的不同實體儲存媒體。系統可包含複數個實體儲存伺服器，每個實體儲存伺服器包含複數個實體儲存媒體以及一微處理器，其中每個虛擬伺服器皆被組構為與每個同級組節點有關的不同儲存伺服器。
本發明另一實施例提供一種檔案設置方法，將特定檔案設置於具有至少一儲存提供者的檔案儲存系統中，關於檔案路徑的特定檔案包含一系列的目錄名稱以及一檔案名稱。檔案設置方法包含(a)應用，在電腦處理程序中使用散列演算法選取目錄名稱之一者來取得索引編號，其中散列演算法的特性為不同的目錄名稱具有不同的索引編號；(b)辨識關於已取得索引編號之已選取儲存提供者；以及(c)接觸已選取儲存提供者編號來取得已選取儲存提供者所維持關於檔案儲存系統內特定檔案的位置資訊，由於不論特定檔案是藉由已選取儲存提供者以及/或藉由至少一其他儲存提供者來儲存皆可以設置特定檔案。
在各種其他實施例中，每個儲存提供者可以為包含形成一組同級節點之複數個同級間電腦處理程序的一虛擬伺服器。散列演算法可取得從零至已選取基底整數之整數乘冪的數目，但不包含該數目，因此此數目係大於或等於檔案儲存系統中檔案伺服器的數量，且該數目除以基底整數係小於檔案儲存系統中檔案伺服器的數量。已選取基底整數可以為二。檔案設置方法更包含改變檔案儲存系統內特定檔案的位置，以及更新藉由已選取儲存提供者所維持的資訊來反應已改變的位置。特定檔案的多個實例可儲存於檔案儲存系統中，且其中藉由已選取儲存提供者所維持的資訊可用來辨識實例的位置。辨識關於已取得索引編號之已選取儲存提供者可包含使用已取得之索引編號對儲存提供者表格編索引。
本發明另一實施例提供一種方法，藉由用戶端來存取儲存系統中的檔案，其中檔案係關於檔案路徑名稱，該方法包含：(a)將檔案之實例儲存在每個複數個儲存提供者中；(b)將檔案的元資料儲存在使用預定映射機制根據至少部分路徑名稱所選取之目標儲存提供者中，元資料包含至少一儲存提供者列表；(c)藉由用戶端將請求傳送至目標儲存提供者；(d)藉由目標儲存提供者將儲存提供者列表提供至用戶端來回應請求；(e)用戶端使用預定選擇機制選擇所列出的儲存提供者之一者；以及(f)用戶端與已選取儲存提供者進行通訊來存取儲存在已選取儲存提供者中的檔案實例。
在各種其他實施例中，預定映射機制可包含應用至部分路徑名稱的散列演算法。預定選擇機制可包含從所列出的儲存提供者之間隨機選取。預定選擇機制可包含使用者可組構策略。目標儲存提供者可以是儲存檔案之一實例的複數個儲存提供者之一者。目標儲存提供者可以是儲存檔案之實例的複數個儲存提供者之一者或者可以不是儲存檔案之實例的複數個儲存提供者之一者。元資料可更包含路徑名稱、部分路徑名稱以及檔案版本編號之至少一者。檔案之實例係儲存在每個複數個儲存提供者中來提供冗餘性以及/或將處理負載分配至複數個儲存提供者。
本發明另一實施例提供一種儲存系統，包含用戶端以及儲存提供者。儲存提供者透過通訊網路與用戶端進行通訊，儲存提供者包含複數個節點，每個儲存節點係由不同的儲存伺服器管理，其中複數個儲存節點係關於多播位址，且複數個請求係使用多播位址傳送至儲存提供者。
本發明另一實施例提供一種儲存系統，包含用戶端以及儲存提供者。儲存提供者透過通訊網路與用戶端進行通訊，儲存提供者包含複數個儲存節點以及分配佇列機制，允許儲存節點之至少一者對已佇列複數個任務進行處理。
在各種其他實施例中，每個儲存節點可由不同的儲存伺服器管理。儲存節點可關於多播位址，且使用多播位址來佇列任務。儲存節點之一者可於任何特定時間處理已佇列任務。儲存節點可以被指派不同的角色來管理已佇列任務的處理，角色預設至少包含主要節點來管理已佇列任務的處理，以及次要節點在主要節點無法運作時管理已佇列任務的處理。角色可以被指派使用指定顏色。
本發明另一實施例提供一種儲存系統，包含用戶端以及儲存提供者。儲存提供者透過通訊網路與用戶端進行通訊，儲存提供者包含複數個儲存節點，其中儲存節點之一者被指派作為複數個節點之代理主機，用來管理複數個節點之間的資料儲存，並且代表其他儲存節點與用戶端互動。
在各種其他實施例中，每個儲存節點係由不同的儲存伺服器管理。儲存節點可關於多播位址，且其中用戶端可使用多播位址與儲存系統進行通訊。儲存節點可以被指配不同的角色，至少包含主要節點作為代理主機，以及次要節點在主要節點於法運作時作為代理主機。角色可以被指派使用指定顏色。
本發明另一實施例提供一種儲存系統，包含複數個儲存提供者，用來分配關於檔案系統的檔案儲存，其中每個儲存提供者係維持關於其儲存檔案的統計資料，且其中指定儲存提供者係蒐集統計資料來進行處理。
在各種其他實施例中統計資料可包含檔案存取頻率。
本發明另一實施例提供一種將處理負載分配至複數個儲存提供者的方法。方法包含(a)判斷期望存取特定儲存提供者所儲存之檔案的多個用戶端；(b)複製至少一額外儲存提供者中的檔案，因此每個儲存提供者，包含特定儲存提供者，係儲存檔案之實例；以及(c)允許用戶端存取檔案的任何實例，因而將處理負載分配至儲存提供者。
在各種其他實施例中，允許用戶端存取檔案之任何實例包含將儲存提供者之列表提供至每個用戶端；以及允許每個用戶端從所存取的檔案中選擇儲存提供者之一者。允許用戶端存取檔案之任何實例包含對每個用戶端指定不同的儲存提供者。
本發明另一實施例提供一種方法，用來維持電腦檔案儲存系統之複數個同級組節點。方法包含根據節點選擇演算法辨識關於目前同級組的等待節點，節點選擇演算法在第一電腦處理程序中的根節點處產生目前同級組節點之更新列表；以及在第二電腦處理程序中，已辨識節點之間進行對話，對話建立一階層以及節點之間的角色分配。
在各種其他實施例中，辨識關於目前同級組節點之等待節點可包含藉由等待節點從根節點接收包含關於目前同級組之等待節點之複數個描述符的訊息。進行對話可包含每個節點邀請者將邀請函傳送至節點受邀者，每個邀請函觸發節點受邀者藉由傳送確認訊息至對應節點邀請者來做回應，至少一節點邀請者接收至少一確認訊息，其中節點邀請者與節點受邀者皆為辨識為關於目前同級組的等待節點。若每個節點邀請者接收來自每個節點受邀者的確認訊息，則對話指標為正，否則對話指標為負。方法更包含在第三電腦處理程序中，若對話成功指標為負，則組構用於目前同級組之替代節點。進行對話更包含將每個節點邀請者所接收來自根節點的訊息傳遞至每個節點受邀者以及/或至少一節點邀請者將訊息傳遞至節點受邀者來接收，訊息包含關於目前同級組之等待節點的描述符並且由來自根節點之至少一節點邀請者所接收。
為讓本發明之該和其他目的、特徵、和優點能更明顯易懂，下文特舉出較佳實施例，並配合所附圖式，作詳細說明如下：檔案為資料的集合。根據UNIX模型(Unix)，檔案也可以為存取電腦資源的介面，例如網路卡、硬碟或電腦記憶體。這只是一些範例，可以被當作檔案來存取的電腦資源可以在手持作業系統介面(Portable Operating System Interface,POSIX)以及定義Unix規格核心的工業標準(IEEE 1003,ISO/IEC 9945)找到。
檔案系統(filesystem)為在儲存系統中儲存與組織電腦檔案的系統。檔案系統將檔案組織為叫做目錄(directory)的列表。列表本身可以為檔案以及具有屬於其他檔案的資料集合。因此，目錄可顯示於其他目錄中。可重複這類型的內容物來建立階層式目錄結構。檔案系統在階層底部具有根目錄(root directory)。檔案的父目錄(parent directory)為包含檔案的目錄(根目錄可視為其本身的上代)。檔案或目錄可以被視為其上代目錄的下代(child)，且檔案上代的其他下代可以被視為檔案的同輩份(sibling)。在階層中檔案與根目錄之間的目錄組(包含根目錄)可以視為檔案的上代(ancestor)。在階層的檔案組中既定目錄的上代可以被視為其他目錄的下代(descendant)。
檔案路徑(file path)(簡稱為路徑)為在檔案系統階層內目標檔案或目錄之位置的文字表示法。絕對路徑(absolute path)係藉由將設置於根目錄與目標檔案或目錄之間的所有目錄名稱串接而形成。相對路徑(relative path)係形成於來源目錄與目標檔案或目錄之間，藉由串接兩個路徑而形成：第一路徑是從來源目錄透過父目錄到一般上代目錄，且第二路徑是從一般上代目錄透過其下代至目標檔案或目錄。中間讀目錄名稱係透過路徑分隔符號(path separator)隔開，標示為向前斜線”/”。根目錄路徑亦可標示為向前斜線”/”。檔案的相關負目錄路徑可標示為兩個句號”..”。
鑲嵌(mounting)為依附兩檔案系統(基部檔案系統(base filesystem與鑲嵌檔案系統(mounted filesystem)))之目錄樹的處理步驟。首先在基部檔案系統中選取目標目錄或鑲嵌點(mount point)。接下來將命令發佈至作業系統而將鑲嵌點與鑲嵌作業系統的根目錄結合。在執行鑲嵌之後，鑲嵌點的檔案路徑代表鑲嵌檔案系統的根目錄，且對此路徑的請求將會回傳與鑲嵌檔案相關的資料。卸除(unmounting)為拆卸已鑲嵌檔案系統的處理步驟。
儲存元資料(storage metadata)為關於檔案儲存的資訊。例如，儲存元資料可包含檔案系統內的檔案路徑以及可找到檔案資料副本的伺服器列表。
同級組(peer set)為一組同級服務或是在至少兩儲存伺服器上執行的節點，用來控制對檔案或其儲存元資料的存取與修改。
網路交換器(network switch)(簡稱交換器)是一種電腦網路裝置，用來連結區域網路(local area network,LAN)中的網路區段，並且可以將網路流量指向根據交換器已知硬體位址的特定區段而依附至該區段。硬體位址為指定給在ISO開放式系統互連架構(open system interconnection,OSI)網路模型與TCP/IP網路模型之資料鏈結層(data link layer)(第2層)中的網路裝置。
儲存提供者(storage provider)為用來提供儲存之硬體、軟體或是硬體與軟體的組合。儲存提供者可實現為單一伺服器(如第5圖所示)，或是可以為其他提供儲存之硬體或軟體，包含網路附接儲存或是儲存區域網路。
1.概論 硬體與網路
第4A圖顯示熟悉技藝之人士所瞭解的範例主從式架構(client/server)系統之相關元件的方塊圖。主從式架構系統包含儲存用戶端410，透過通訊網路420(例如LAN或WAN(例如網際網路))與儲存提供者430、440、450進行通訊。儲存用戶端410為使用儲存提供者430、440、450所提供資料儲存服務的電腦。儲存用戶端410為與儲存提供者430、440、450有關的用戶，值得注意的是儲存用戶端410可以為做為其他目的之伺服器，例如可以為網路伺服器。第6圖顯示並說明一種可能的實體儲存網路420。
儲存用戶端410包含應用程式412與檔案系統414。在儲存用戶端410執行的用戶端應用程式412產生檔案操作請求，例如產生新的檔案、寫入現存檔案或是讀取現存檔案。檔案系統414管理檔案儲存並與應用程式412(例如透過應用程式介面或API)和伺服器(例如透過網路檔案通訊協定，例如NFS或CIFS)互動。在應用程式觀點，檔案系統414接收來自應用程式412的檔案操作請求，處理請求並且產生對應用程式412的回應。在伺服器觀點，檔案系統414傳送檔案操作請求至儲存提供者430、440與450並接收由儲存提供者產生的回應。應用程式412與檔案系統414通常以儲存於記憶體中的軟體實現並且於微處理器執行，值得注意的是，這樣的元件可包含於硬體以及/或軟體中，且本發明實施例並沒有限制應用程式412與檔案系統414的實現方式。
每個儲存提供者430、440、450分別包含儲存處理器432、442、452以及儲存器434、444、454。儲存處理器432、442、452處理來自儲存用戶端410的儲存操作請求並將回應回傳至儲存用戶端410。儲存處理器432、442、452分別與儲存器434、444、454互動來儲存並擷取檔案相關資料。在一般實施例中，即使可使用除了硬碟之外的其他類型儲存器(例如固態或光學儲存器)，每個儲存器434、444、454包含至少一硬碟(例如四個硬碟)。每個儲存處理器432、442、452通常以儲存於記憶體中的軟體實現，並且在其個別儲存系統430、440、450內的微處理器上執行，值得注意的是，這樣的元件也可以硬體以及/或軟體來實現，且本發明並未限定實現儲存處理器的方法。
第4B圖顯示本發明實施例主從式架構系統之相關元件的方塊圖。在此實施例中，每個儲存用戶端(包含儲存用戶端410)包含額外元件415(在此文件中又稱為FS用戶端)在邏輯上設置於檔案系統414與網路420之間。同樣的，在此實施例中，每個儲存提供者(包含儲存提供者430、440、450)分別包含額外元件431、441、451(在此文件中又稱為FS伺服器)在邏輯上設置於個別儲存處理器432、442、452與網路420之間。FS用戶端415與FS伺服器431、441、451互動而由檔案系統414與儲存處理器432、442、452提供額外的檔案儲存功能(在下文中會有詳細說明)，並使用儲存處理器提供的服務來處理檔案相關資料的儲存。實質上，FS用戶端415接收檔案系統414產生的檔案操作請求，在傳統技術系統中會被遞送至儲存處理器之一者，並與FS伺服器元件之至少一者互動來滿足檔案操作請求並提供適當的回應至檔案系統414。每個FS伺服器元件與其個別的儲存處理器接觸而根據與FS用戶端的互動來儲存並擷取資料。在一般的實施例中，FS用戶端415與FS伺服器431、441、451係以軟體實現，值得注意的是，這些元件亦可以硬體以及/或軟體實現，本發明並未限定實現這些元件的方法。
值得注意的是，在本發明實施例中，主從式架構系統可包含多個用戶端，每個用戶端皆具有FS用戶端元件，以及多個儲存提供者，每個儲存提供者皆具有FS伺服器元件。值得注意的是，在各種實施例中，儲存提供者可以單一儲存伺服器或是儲存伺服器群組來實現(例如叢集操作)並且可使用任何實體或邏輯儲存架構來實現。這樣的抽象概念允許檔案系統414與在異質儲存網路中以不同方式實現的儲存提供者互動。例如，第一儲存提供者可以為單一檔案伺服器，第二儲存提供者可以為至少兩檔案伺服器的叢集，且第三儲存提供者可以為在至少一伺服器上執行的虛擬檔案伺服器。
第5圖顯示本發明實施例儲存伺服器之相關元件的方塊圖。儲存伺服器510具有微處理器520與記憶體530。微處理器520與記憶體530可以合作來執行儲存處理器與FS伺服器。另外，儲存伺服器510包含至少一用來儲存檔案的硬碟。在本發明實施例中，儲存伺服器510包含四個硬碟540、542、544與546，然其並非用來限定本發明的範圍，在其他實施例中可以使用任何數量的硬碟。儲存伺服器510亦可包含至少一網路介面卡(network interface card,NIC)用來與儲存網路420(未圖示)進行通訊。在本發明實施例中，儲存伺服器510包含兩個NIC 550與552以提供硬體或網路失效時的冗餘度，然而在其他實施例中可以使用任何數量的NIC。
第6圖顯示第4B圖之儲存網路120的可能實體組構。在圖中係個別顯示儲存伺服器，不是儲存提供者可以為增加至儲存伺服器的儲存處理層。儲存用戶端410與儲存伺服器630、640與650進行通訊。儲存網路是由三個交換器610、620與622所組成。在此實施例中的每個儲存伺服器具有兩個NIC 550與552。每個NIC係連接至交換器。在第6圖中，標示為550的NIC皆連接至交換器620，而標示為552的NIC皆連接至交換器622。儲存用戶端410係直皆連接至交換器610，交換器610依序連接至交換器620與622。儲存用戶端410可與儲存伺服器440進行通訊，例如透過兩種不同的資料路徑：第一資料路徑通過交換器610、交換器620與儲存伺服器440上的NIC 550，而第二資料路徑通過交換器610、交換器622與儲存伺服器440上的NIC 522。
在此實施例中的架構可抵抗網路失效與硬體失效。例如，若交換器610與620之間的通訊連結中斷，儲存用戶端410仍可使用交換器622與儲存伺服器440接觸。若交換器610與儲存伺服器440上NIC 550之間的通訊連結中斷，儲存用戶端410仍可使用NIC 522與儲存伺服器440接觸。在其他實施例中，網路420可包含額外的交換器連接至交換器620與622，而儲存用戶端410係連接至該兩個交換器。在此方法中，交換器可能會失效而儲存伺服器可能仍舊有接觸。熟悉此技藝之人士皆瞭解其他保留此冗餘類型的網路組構也包含在發明範圍內。當每位元組的硬碟成本隨著時間減少時，系統變的越具有成本效益。
系統簡介
根據儲存用戶端的觀點，用戶端應用程式412(例如網路伺服器)係與儲存系統接觸來操作檔案。用戶端檔案系統414為用戶端應用程式412與其他儲存系統之間的接觸點。因此，用戶端檔案系統的目的為接收來自用戶端應用程式412的檔案系統請求並且回應檔案資料或操作結果。用戶端檔案系統414的內部運作通常回報至用戶端應用程式412。執行這樣的隔離限制有助於軟體設計與可攜性。用戶端應用程式412可使用特定介面與檔案系統414進行通訊。在此方法中，用戶端應用程式412可在不同的檔案系統414上實現。在一些實施例中，檔案系統介面是一組POSIX應用程式介面(application programming interface,API)。其他實施例可使用由儲存用戶端之作業系統所定義的其他API。
用戶端檔案系統414與FS用戶端415接面並依序與FS伺服器接面來儲存並擷取資訊。FS用戶端與FS伺服器使用各種配套技術(之後會說明)來判斷儲存資訊的位址與方法。配套技術允許FS用戶端判斷每個儲存事件與哪個儲存提供者接觸，並允許FS伺服器操控儲存資訊的位置與方法，包含平衡橫跨多儲存提供者的儲存負載，平衡橫跨多個儲存提供者的處理負載，複製多個儲存提供者中的資訊來作為冗餘，以及複製多個儲存提供者中的資訊來平衡負載等等。FS伺服器本質上可任意將檔案資訊儲存在至少一儲存提供者的任何地方並且可動態的移動檔案資訊，但是由FS用戶端與FS伺服器所使用的配套技術係確保FS用戶端可設置該檔案資訊，不論檔案資訊儲存在何處。
在本發明實施例中，FS用戶端根據由檔案系統與預定機制提供的路徑名稱判斷特定儲存事件所接觸的目標儲存提供者。例如，FS用戶端可使用應用至部分路徑名稱的預定散列函數(hash function)來判斷目標儲存提供者。FS伺服器使用相同的機制來判斷相關檔案資訊的儲存位置，使得FS用戶端可設置檔案資訊。目標儲存提供者可儲存檔案本身以及/或可儲存辨識檔案所儲存至少一其他儲存提供者的元資料(metadata)。這樣的元資料本質上提供某種等級的間接法(indirection)來允許檔案的實體位置與該檔案名稱去耦合。由於檔案可能會被複製在多個儲存提供者中，因此元資料可包含提供FS用戶端選擇(例如隨機)來存取檔案的儲存提供者列表。這樣的列表可允許用戶端對特定檔案存取的負載平衡(例如，若多個用戶端同時收看相同的電影，該電影檔案會被複製並儲存於多個儲存提供者中，且每個用戶端可從中隨機選取一個儲存提供者來存取電影，使得該存取像是從多個儲存提供者之間靜態發佈的)。
因此，在本發明實施例中，FS用戶端決定在兩步驟處理中特定儲存事件與那個提供者接觸：首先，FS用戶端可設置控制請求資料的儲存提供者列表，再來，FS用戶端可判斷這些將與檔案操作請求接觸之提供者的子集合。在第一步驟中，FS用戶端可使用散列演算法(與第8圖和第9圖一起說明)來設置與擷取相關儲存提供者列表。這種列表的結構會與第10圖一起說明。第二步驟可使用儲存系統管理者設定的儲存冗餘政策。FS用戶端可使用任何便利訊息資料格式與儲存提供者進行通訊(與第12圖一起說明)。
儲存提供者可對FS用戶端請求提供增強的服務可用性。在本發明實施例中，儲存提供者係由在各種實體伺服器執行的一些處理步驟構成，並配合來控制散落這些伺服器之間的儲存區域。這些處理步驟或節點可作為一組同級使用共用網路通訊協定與訊息格式而彼此通訊。然而，根據可攜性原則，節點不需要知道任何其他節點的內部操作。因此，當參與單一同級組時，具有不同作業系統的儲存伺服器可執行具有作業系統特定最佳化的節點。
每個節點可控制既定伺服器上的至少一儲存媒體。例如，節點可控制硬碟540與542。另外，節點可以指控制至少一硬碟的一部份或是其他持久的儲存媒體，例如快閃RAM、CD或DVD。節點可與其本身實體伺服器的作業系統進行通訊而以適用於該作業系統的方法來處理檔案系統請求。例如，節點可使用POSIX API或是其他API來要求本地作業系統執行檔案系統來回應用戶端請求。儲存元資料與檔案資料的邏輯組構使得節點可以在第13圖之伺服器中實現。
儲存提供者也可對FS用戶端的請求提供增強的資料可用性。儲存提供者僅可存取單一實體儲存伺服器(例如第5圖)。然而，若儲存提供者可存取散佈於其儲存區域的不同實體儲存伺服器，儲存抽象化具有優點。儲存提供者可調節其所監視之橫跨所有實體儲存伺服器的檔案系統請求，因此包含於儲存伺服器實體媒體中的資料係維持同步。儲存提供者也可偵測實體硬體或其伺服器軟體中的故障，並且有效修復來改善可用性。這樣的修復可包含選取其他可用的伺服器來取代當機伺服器。或是，若儲存處理器(例如處理器432故障)，儲存提供者可發佈網路訊息至受影響的伺服器來請求適當的儲存軟體或是重新啟動硬體。熟悉此技藝之人士皆瞭解，其他自我修復技術以及此處說明實現該技術的其他方法也在本發明範圍內。在本發明實施例中，使用全系統(system-wide)佇列機制(queuing mechanism)來修復可能很有效果。這樣的機制允許個別的儲存提供者來佇列資源密集任務，例如由具有備用處理電力的伺服器來實現資料複製。此佇列系統會在第14圖中討論，且自我修復同級組的處理步驟會在第15圖至第17圖中說明。
第7圖顯示在處理用戶檔案操作中邏輯元件之間相關互動的方塊圖。在儲存用戶端或其他計算裝置上執行的應用程式軟體係產生檔案操作請求。在步驟710中，檔案系統使用應用程式介面(API)(例如POSIX)來接收這些檔案操作請求。在步驟780中，檔案系統處理該請求並將操作結果回傳至使用相同API的請求應用程式軟體。由於與檔案系統操作有關的中間步驟屬於本發明實施例，因此會在下文中說明。
檔案資料可儲存於數個不同的儲存區域，每個儲存區域係由不同的儲存提供者控制。因此變的必須追蹤那個檔案資料在那個儲存區域中以確保資料的一致性。基於此理由，檔案儲存系統可建立並維持儲存元資料。儲存元資料可包含檔案資料的檔案路徑，控制檔案資料的儲存提供者列表，世代(版本)計數器以確保檔案資料在所有儲存區域中皆同步，以及其他與檔案資料儲存有關的便利或必要資訊。儲存元資料可儲存為存在於與其相關檔案資料具有相同實體媒體之檔案系統內的檔案。因此，儲存元資料也可由儲存提供者控制。
第7圖說明該方法。在步驟710中，FS用戶端415接收既定檔案的檔案操作請求。在步驟720中，FS用戶端415透過計算請求檔案之路徑散列(或是部分的路徑)來判斷那個儲存提供者(也就是那個FS伺服器)控制對該檔案(又叫做目標儲存提供者)之儲存元資料的存取。在步驟730中，FS用戶端415與目標儲存提供者(也就是儲存提供者430)中的FS伺服器接觸，在步驟732中，目標儲存提供者依序與儲存處理器432互相作用而取得對來自儲存器434之檔案的儲存元資料。在步驟734中，FS伺服器431將儲存元資料回傳至FS用戶端415。在本發明實施例中，儲存元資料包含控制對實際檔案資料存取之至少一儲存提供者列表，該列表可包含儲存提供者430本身。值得注意的是，使用第8圖的方法可使步驟720與730只包含單一網路存取來分解路徑，因而降低儲存系統的延遲時間與頻寬。
在步驟740，FS用戶端接著選擇至少一儲存提供者接觸來存取檔案資料。該選擇可使用任何標準來決定(例如隨機或根據使用者設定原則)，並且可設計這樣的標準來最佳化儲存伺服器與儲存用戶端或兩者的操作。
一旦選擇了儲存區域，在步驟750中，FS用戶端可在選取儲存提供者之至少一者中與FS伺服器接觸來開始執行檔案系統(在此實施例中，FS用戶端415係與FS伺服器441與FS伺服器451接觸)。值得注意的是，FS用戶端建立包含請求的格式化網路訊息並將其傳送至FS伺服器(在此實施例中，FS用戶端415可傳送個別訊息至FS伺服器441與451)。在步驟760中，FS伺服器441與451分別與儲存處理器442與452相互作用而分別存取來自儲存器444與454的檔案資料。在步驟770中，FS伺服器441與451將檔案資料回傳至FS用戶端415。FS用戶端可蒐集來自所有相關儲存提供者的結果，並且在步驟772中可將其聚合為適合用戶作業系統之API的結果(例如適用於POSIX的函數回傳值)。在步驟780中，此結果最後可回傳至檔案系統414來完成此處理步驟。現在將詳細說明此處理步驟。
如上所述，儲存元資料本質上提供某種等級的間接法允許檔案動態分佈於儲存提供者之間，同時仍允許FS用戶端415設置具有檔案資料的至少一儲存提供者。目標儲存提供者可儲存檔案資料來作為這樣儲存元資料的替代。例如，目標儲存提供者可儲存特定檔案的檔案資料，在這樣的例子中，FS伺服器可將檔案資料(而不是儲存元資料)回傳至FS用戶端來回應來自FS用戶端的請求。另外，目標儲存提供者可和儲存元資料一起儲存部分檔案資料並將兩者回傳至FS用戶端來回應來自FS用戶端的請求。由於FS伺服器可已在儲存提供者之間動態的複製與移動檔案資料，特定檔案的檔案資料可初始儲存於目標儲存提供者(在這樣的例子中，目標儲存提供者可將檔案資料而不是儲存元資料回傳至FS用戶端來回應來自FS用戶端的請求)，之後該檔案資料可複製於以及/或移動至至少一個其他儲存提供者(在這樣的例子中，目標儲存提供者可接著將儲存元資料與部分檔案資料回傳至FS用戶端來回應來自FS用戶端的請求)。
用於目錄名稱的散列函數
一種儲存系統實施例可根據儲存模式將檔案路徑分散橫跨整個可用儲存器。本發明實施例在假設檔案系統無法預測應用程式將選擇給檔案操作的路徑的情況下將路經分散橫跨儲存器。此分佈允許必須由儲存系統完成的工作分散於儲存提供者之中。然而，若檔案路徑為可預測，則此工作量的分佈不是最佳化的。本發明範圍內的實施例可組構給不同的提供者以符合其他應用程式的需求。
本發明實施例可使用散列函數將檔案路徑分佈橫跨不同的儲存提供者。散列函數為將輸入資料組均勻排序為輸出資料組的工具，通常為較小尺寸。因此，本發明實施例可將全部可取得的儲存器分為大致相同尺寸的一些儲存單元。該實施例接著可建立儲存單元表，並使用散列函數將檔案路徑排序為該表。為了選擇儲存區域，FS用戶端415將散列函數應用至部分檔案路徑而產生表索引。由於散列函數傾向於將其輸入均勻排序為其輸出，此處理步驟將該組檔案名稱均勻排序為該組表索引，並因此均勻排序為儲存單元。
然而，本發明實施例不使用全部檔案路徑作為散列函數的輸入。散列處理全部檔案路徑會造成某種程度上的低效率。檔案可在檔案系統內移動，並且可將目錄重新命名。在這些情況中，部分檔案路經會改變，且散列值也會因而改變。因此，至少一檔案的儲存提供者會改變，且相關資料必須在儲存提供者之間移動。重新命名或移動目錄(特別是接近檔案系統根的目錄)會造成所有下代檔案的散列改變，並且會觸發與用戶資料存取無關的特定資料傳輸。為了指出此問題，當檔案路徑與儲存提供者相關時，本發明實施例僅可散列部分檔案路徑。本發明實施例僅散列請求檔案父目錄的名稱。在此方法中，若將目錄重新命名，唯一必須移動的資料為與該目錄相關的資料。這樣的資料可包含目錄本身的儲存元資料，並且也可包含相關檔案(例如目錄的子目錄)的儲存元資料，用於有效操作某些檔案系統的儲存(例如列出目錄內容)。具有相同路徑的檔案(例如同輩份檔案)產生相同的散列值並且可儲存於相同的儲存單元。
接著考量可攜性原則。FS用戶端415與儲存提供者接觸(而非儲存單元)來存取資料。FS用戶端415不需要知道儲存單元，儲存單元應該是與儲存提供者有關。基於此理由，表的項目可包含儲存提供者的名稱(而不是儲存單元的名稱)來控制對應的儲存單元。表中的每個項目應該大致對應至相同的儲存量，但是由儲存提供者控制的儲存量可具有由其他儲存提供者控制相同或不同的儲存量。因此，表可能具有冗餘，其中儲存提供者可出現於多個表項目中。在本發明實施例中，每個儲存提供者皆具有表中約正比於其控制之儲存尺寸的一些項目。例如，若儲存提供者A控制儲存提供者B的一半儲存量，則儲存提供者A具有儲存提供者B在表中的一半項目數量。在此方法中，每個表項目約與其他表項目相同的儲存量有關，且隱藏的儲存提供者從FS用戶端415執行細節在其他實施例中，儲存系統管理者可能希望指派更多表項目給具有更強大微處理器以及更多可用頻寬等等的儲存提供者。
第8圖顯示在將檔案路徑轉換為表索引來判斷儲存提供者之處理步驟的表示法。本發明實施例開始於在步驟710期間取得的檔案路徑810。第8圖中的路徑為/doc/papers/paper.doc。在此路徑中有三個目錄：根目錄/818，第一層目錄docs 812以及第二層目錄papers 814。在路徑中有個檔案葉(file leaf)為paper.doc 816。這些元件係由路徑分隔器/來做分隔。由於在第8圖中有三個目錄，至少具有從此路徑所形成之三個不同的目錄散列。
在第一實施例中，用戶端請求目錄papers。FS用戶端415使用散列函式820對父目錄進行散列來產生十六進位值830，也就是f67eba23。接下來，藉由降低模數儲存表的尺寸而將十六進位值轉換為表索引。例如，表可具有尺寸16或是24 。在這個例子中可使用位元遮罩(bitmask)840將除了散列的四個最低有效位元(least significant bit,LSB)之外的所有位元丟棄。因此，散列值f67eba23被遮罩為3(十六進位)，標示為850。此值係對應至(十進位)表索引的3。
在第二實施例中，用戶端請求檔案paper.doc。負目錄papers 814使用相同的散列函數820來執行散列處理而產生十六進位值832，也就是8c2ab15c。使用相同的位元遮罩840係產生c(十六進位)，標示為852。此值對應至(十進位)表索引的12。同樣的，若用戶端對目錄docs 812執行檔案操作的請求，則可以將根目錄/執行散列與位元遮罩而產生第三表索引。因此，每個目錄僅與對應至特定儲存提供者的一個表索引有關聯。
本發明實施例採用的方法比先前在NFS中使用的”檔案路徑分解”通訊協定更佳。在NFS中，將檔案路徑分解為由疊代處理程序構成的檔案。首先，NFS檔案系統將檔案路徑截斷為其元件部分：根目錄、中間目錄以及資料檔案。檔案系統組構一目錄檔案給第一鑲嵌NFS的目錄(NFS根)並從網路對其進行存取。接下來，NFS組構檔案目錄給每個子目錄並從網路對其進行存取。NFS重複此處理步驟直到完全分解檔案路徑。此處理步驟會對網路進行多次存取，每個中間目錄皆會對網路進行一次存取。在此實施例中，步驟720不需要網路存取來設置檔案。由於散列函數僅應用至部分的檔案路徑，系統可在一段時間內組構檔案，該段時間非取決於檔案路徑中的目錄數量或是儲存系統中的儲存伺服器數量。為了存取需要單一網路訊息至適當儲存提供者的檔案，儲存提供者會在不存取網路的情況下察看其本地檔案系統中的特定檔案。
增加儲存量：擴充散列表
有時後儲存系統管理者會希望對系統增加額外的儲存量。管理者可購買額外的伺服器，例如顯示於第5圖中的伺服器，並將其增加至儲存系統。在本發明實施例中可以將檔案路徑平均分配至所有的儲存器，系統應該計算額外的伺服器。系統可將全面或部分之新的儲存區域交給現存的儲存提供者，或是增加用來控制新儲存區域的額外儲存提供者。在第一實施例中，區域尺寸係由每個儲存提供者的改變所控制。在第二實施例中，儲存提供者的數量改變。在兩個實施例中都可能需要改變儲存表。例如，儲存系統可開始於三個儲存提供者。管理者購買額外的實體伺服器，實體伺服器需要增加兩個儲存提供者至系統(在第9圖中的處理步驟中說明)。由開始三個儲存提供者控制的一些內容應該分配至兩個新的儲存提供者來平衡處理負載。
具有與提供者數量相同項目數量的表可能會沒有效率，考量必須降低散列值因而對表尺寸執行模數(modulo)來產生有效的表索引。若表尺寸從三改變為五，檔案系統中多數檔案的散列值將會改變(五個中只有一個會維持相同：具有散列值為0、1或2模數15)。這樣的改變通常會強制80%的儲存元資料檔案從一儲存單元傳送至另一者。此結果會造成相當大的效能損失(performance penalty)是很明顯的缺點。
本發明實施例可限制表尺寸等於整數的冪次。此限制有效的擴充儲存表，如下所述。在本發明實施例中，表尺寸等於二的冪次，但是在其他實施例中可使用不同的指數基底。選擇二當指數基底提供相當的效率，例如使用第8圖中用於大部分現代電腦結構中的硬體位元遮罩基元(primitive)。
第9圖顯示擴充控制檔案元資料之儲存提供者表的處理程序，由第8圖之處理步驟中建立的表索引來作為索引。表擴充開始於階段I中儲存提供者910的表。此處具有三個儲存提供者，具有對於A 951、B 952與C 953的表項目。提供者A 951在表中出現兩次-可能是由於具有三個伺服器的大部分儲存量。假設現在增加兩個由提供者D 954與E 955控制的儲存區域至儲存系統。系統管理者可重新組構儲存系統使系統辨認額外的儲存器。接下來，儲存系統可判斷儲存提供者表的索引數量比儲存提供者數量少並且擴充表格。
更新出現在兩階段中的表格：階段II與階段III。在階段II中，表格透過複製現存表格項目940擴張為次高的冪次，因此變為表格920。在此階段期間，將表格尺寸限制為整數的冪次是很重要的。若基底整數為N，則現存表格項目將會被複製N-1次。在第9圖的實施例中，基底整數為2，因此會將現存項目940複製一次而變為表格942。即使藉由此處理程序將此表格中任何儲存提供者的項目數量加倍，一項目在表格中的出現次數與其他的比值仍維持常數。因此，組構給每個儲存提供者之儲存器的比值固定不變。同樣的，階段II末端處的表格尺寸維持指數基底的冪次。
階段II的處理步驟不會改變那個儲存提供者控制既定目錄名稱。為了知道原因，將表格尺寸設定為NK ，並且考慮既定目錄名稱之散列值的基底N表示法。降低此散列值模數第8圖之表格尺寸的操作相同於丟棄該值之最高有效基底N位元，並僅保留K個最低有效位元。在透過係數N擴充表格之後，表格尺寸將會是NK+1 。接下來，第8圖的處理步驟將產生具有散列值之K+1個最低有效位元的表格索引。但是現存的表格項目對位置K+1處之位元的每個可能正值進行一次複製，因此此位元僅選取N個相同預擴充表格副本之一者。索引的剩餘K個最低有效位元不會改變。因此，新計算的表格索引仍對應至與先前相同的儲存提供者與儲存區域。因此，階段II中的擴充不需要在儲存區域之間移動資料。
在階段III中，一些表格930的複製項目會被新儲存提供者的項目取代。在本發明實施例中，取代會遵循表格索引與儲存空間之間的比例原則(proportionality rule)。在第9圖中，表格索引4係從提供者A 951改變為提供者D 954，且表格索引7會從提供者A 951改變為提供者E 955。此處理步驟會將某些散列值從一儲存提供者重新指派為另一者。在此，具有等於(4 modulo 8)之散列值的目錄名稱從提供者A 951重新指派至提供者D 954，而具有等於(7 modulo 8)之散列值的目錄名稱從提供者A 951重新指派至提供者E 955。
以下會對動態表格擴充的額外做詳細說明。
資料在儲存提供者之間的自動移動
在將新的儲存提供者新增置提供者表格之後，由原始儲存提供者控制之每個目錄的儲存元資料可能會移動至新的儲存區域。移動目錄的處理步驟需要一些時間，因此儲存提供者可能無法立即執行，因而可將移動項目置放於非同步佇列系統，如以下第14圖的說明。
當移動正在進行時，提供者表格可以對既定索引儲存新的提供者與舊的提供者。若檔案系統操作的檔案路徑散列至被移動的目錄，則首先會對新的儲存提供者詢問該路徑的儲存元資料。若元資料被移動至新的儲存區域，則回傳該元資料。若元資料未被移動，則詢問舊的儲存提供者並回傳儲存元資料。
首先，將移動表格本身安裝於舊的儲存提供者中(每個移動索引具有多個提供者)。當移動正在進行時，用戶端可請求產生關於新儲存提供者之散列值的檔案路徑。當發出第一次請求時，用戶端將具有舊版本的提供者表格，並且將會向舊的儲存提供者請求檔案。此儲存提供者可使用世代計數器來偵測具有舊版本表格的用戶端，並且回傳較新的表格至用戶端。(如上所述，實際的儲存元資料仍可存在於舊的儲存伺服器。在此實施例中，儲存提供者可透過將元資料立即回傳至用戶端來降低網路通訊。)必要時用戶端可使用正確的儲存提供者來重播儲存元資料擷取請求。此時，用戶端可偵測新的提供者具有舊版本的表格，並且更新提供者。在此方法中，移動表格可傳輸遍及該系統。
在完成移動之後，移動表格可以被每索引僅具有一儲存提供者的非移動表格取代。在一次，任何既定儲存提供者可使用世代計數器來判斷檔案系統操作期間用戶端的儲存區域表格為舊的並且將其更新。且用戶端可判斷提供者具有舊的表格副本(移動)並且將其更新。在此實施例中，可同時發生數個移動，其中系統可包含至少一個移動表格。然而，每個表格可具有不同的世代計數器，因此系統可維持系統的一致性。
在本發明實施例中，儲存元資料本身的儲存提供者之間的移動是緩慢的。當用戶端應用程式請求目錄的檔案系統操作時，緩慢移動(lazy migration)將目錄的儲存元資料從一儲存區域傳輸至另一者。在另一實施例中，儲存元資料在儲存區域之間即時移動。在即時移動中，當心的儲存提供者增加至表格930時，由舊的儲存提供者所控制的所有目錄會立即被舊的儲存區域重新散列來判斷是否移動。舊的儲存提供者將每個移動目錄的儲存元資料傳送至新的儲存區域，而未等待來自用戶端的檔案操作請求。
儲存元資料與多個儲存提供者
在執行步驟710所接收之檔案系統操作的處理步驟中。在步驟720中，儲存用戶端可以判斷檔案路徑以及那個儲存提供者控制該路徑的儲存雲資料。在步驟730中，儲存用戶端可使用便利資料格式建立包含此資訊的儲存元資料請求訊息，並將其傳送至儲存提供者。接下來在步驟732中，提供者可擷取檔案的儲存元資料並在步驟734中回傳。在本發明實施例中，儲存元資料擷取請求是FS用戶端需要為一的網路存取來設置控制對具有既定路徑儲存提供者的存取。
第10圖顯示儲存元資料檔案1010的內容表示法。每個儲存元資料檔案1010係屬於資料檔案。儲存提供者儲存檔案的方法對FS用戶端通來說是不透明的(opaque)。只要用戶端不處理該資料，則用戶端檔案系統仍可使用儲存提供者所使用的資料。值得注意的是，本發明實施例之儲存提供者可以不同於用戶端應用程式知道的名稱來儲存檔案資料，並且將該名稱提供至用戶端檔案系統。在第13圖中會說明一種可能的命名規約(naming convention)。若使用適當的命名規約，元資料檔案1010可包含這樣的不透明檔案名稱1012。其他實施例可使用用戶端應用程式已知的檔案名稱來儲存檔案資料。
除了檔案名稱之外，儲存元資料檔案1010也可包含控制存取檔案資料之儲存提供者的清單。在第10圖中，此清單具有四個項目1014、1016、1018與1020。儲存此清單致能系統複製四個提供者之間的資料，其他實施例可根據其資料複製的需求而具有該清單中的更多或更少項目。每個項目可至少具有控制存取檔案資料以及世代(版本)計數器或是其他有用資訊之儲存提供者的數量。一般來說，此列表的第一項目1014將包含控制存取元資料檔案本身的儲存提供者。相同的儲存提供者可控制檔案資料與其儲存元資料。其他實施例可使用不同的檔案組構。在此實施例中，項目1014顯示儲存提供者#6控制對儲存為123abd之檔案的儲存元資料的存取，並且具有對檔案資料版本1233的存取。項目1016顯示儲存提供者#18具有對檔案資料之版本1232的存取。項目1018是空白的。空白的項目可能在例如儲存提供者持有過去檔案資料的其他版本但停止執行時發生(可能起因於硬體失效)。或是，空白項目可能在儲存系統管理者改變提供者間複製策略來儲存檔案資料的三個副本(而非四個副本)時發生。熟悉此技藝之人士皆瞭解項目可能為空白的原因。項目1020顯示儲存提供者#23包含此檔案之檔案資料的版本1233。
在此實施例中，並非所有的儲存提供者皆具有相同版本的檔案資料。提供者#6與#23具有比提供者#18更新的版本。因此，檔案資料是非同步化的。控制元資料檔案的儲存提供者(在此實施例中為提供者#6)可辨識此狀態並開始執行修復。取決於這是不是唯一需要複製並修復的檔案可能需要一些時間。因此，當辨識到此狀態時，儲存提供者可以在非同步佇列系統(例如第14圖所說明的系統)中佇列檔案資料複製請求。本發明實施例的儲存提供者可以在檔案操作請求到達離開同步的檔案之前對其控制的儲存元資料檔案執行週期性掃瞄來偵測這樣的狀態。
在本發明實施例中，元資料可儲存於符號鏈接中(symbolic link)。符號鏈接是一種不包含檔案資料的特殊檔案系統，但是包含指向儲存於其他地方之檔案資料的其他資料。元資料可以儲存為任何便利格式。不同的檔案系統係以不同的符號鏈接來儲存資料並且允許存取資料。Unix系統只需要單一系統呼叫readlink()來讀取符號鏈接，取代一般檔案需要的三個系統呼叫open()、read()與close()。同樣的，Unix系統對符號鏈接比對一般檔案提供更大的檔案完整性保證。本發明實施例利用符號鏈接的優點來提升擷取儲存元資料的速度與可靠性。其他實施例可使用其他的實體方法來儲存元資料。
聚合儲存於多個儲存提供者中的檔案資料
在步驟740中，FS用戶端415可分析儲存元資料並選擇與具有檔案資料副本的儲存區域接觸。至此，儲存系統僅組構與擷取檔案儲存元資料。步驟740為處理程序的第一步驟，該處理步驟係有關於分配檔案資料。本發明實施例可以不同的方法將檔案資料分配於儲存區域之間。例如，儲存系統可使用RAID技術跨接各種儲存提供者來分配資料，例如分散連結(striping)、硬碟鏡像(mirroring)以及維持同位(parity keeping)。這些技術皆具有不同的優點與缺點，且在此實施例中的儲存系統管理者可選擇適用於即將發生之儲存問題的技術。每個這些技術皆需要儲存用戶端來存取不同的儲存提供者。例如，在硬碟鏡像技術中，每個儲存區域包含相關檔案的完整副本，使得儲存用戶端可根據係(例如伺服器負載與可用頻寬)數來選擇儲存提供者。然而，在分散連結技術中，每個儲存區域僅包含部分的相關檔案，且在任何既定檔案操作中可能會需要存取某些或所有的儲存提供者。值得注意的是，檔案可以被複製(硬碟鏡像)於多個儲存提供者上來作為冗餘、平衡負載或其他目的。為了判斷檔案應該被複製至多個儲存提供者來作為冗餘的時間，在一些上下文中可能有用的標準包含檔案類型(例如所有的文宇(text)文件或是所有的文書處理(word)文件)、檔案尺寸(例如尺寸大於1GB的所有檔案)以及檔案名稱(例如具有名稱包含字串”account”的所有檔案)。在冗餘的例子中，可以使用該間接法(indirection)技術將檔案複製於多個儲存提供者中，用戶端可具有儲存提供者列表並且於需要時可連續的與清單中的至少一儲存提供者接觸來存取檔案，在此方法中，若無法取得用戶端接觸的第一儲存提供者，則用戶端將會與其他儲存提供者接觸來存取檔案。儲存系統的實施例可包含對特定檔案偵測大量使用者存取的邏輯，並且動態且自動地將檔案複製於儲存提供者之間來提供全系統負載平衡。
給定儲存系統內檔案複製的組構，在步驟740中，檔案系統可決定與那個儲存提供者接觸來存取實體檔案資料。在本發明實施例中，檔案資料係硬碟鏡像於儲存區域之間。因此，由考量下列因素的策略引擎做決定：目前的儲存網路使用率，儲存伺服器的負載、產能與處理電力，檔案資料複製技術，以及任何其他可用與相關資訊。其他實施例可使用其他技術來決定與那個儲存提供者接觸來存取檔案資料。
值得注意的是，不論用戶端選擇與那個儲存提供者接觸，儲存提供者本身可彼此協調而在沒有用戶座標的情況下維持相關複製組構。例如，如第9圖所說明在增加儲存容量之後，儲存提供者可將資料移動於其本身之間。一旦用戶端具有一致的資料圖像來作為存取的目的，儲存提供者可執行其他實體資料的操作。
一旦FS用戶端415決定與適當的儲存提供者接觸，處理程序會繼續進行至步驟750。在步驟750中，FS用戶端415可使用儲存網路將檔案操作請求訊息遞送至各種以選取之儲存提供者。這些訊息直接符合原始的請求檔案操作：open()，close()，read()，write()或是由檔案系統API指定的其他操作，例如stat()。在步驟760中，各種儲存提供者的伺服器處理這些訊息(下文會對有詳細說明)。在步驟770中，檔案系統接收來自儲存網路的結果。
在步驟772中，FS用戶端可分析各種聚合反映來判斷動作的進一步方向。有四種可能性。第一，若所有的儲存提供者回報成功地完成檔案操作，則檔案系統414可以回傳成功值780至請求應用程式軟體412。例如，若應用程式請求目錄中所有檔案列表，每個儲存提供者會執行適當的系統呼叫或函式庫(library function)(例如opendir()與readdir())來取得目錄列表，且FS用戶端415可接著將所有這些列表設置於主要列表中而回傳至應用程式軟體412。
第二，檔案操作可能是非同步的。某些檔案系統支援以非同步、非阻塞(non-blocking)的方式將來讀取檔案中的資料或將資料寫入檔案中，使得請求應用程式在等待完成檔案的操作時可執行其他指令。應用程式中的此能力很重要，其中檔案代表通訊通道，例如網路裝置、檔案插座(socket)或導管(pipe)。完成非阻塞操作的POSlX方法為發佈具有O_NONBLOCK變數的open()或fcntl()系統呼叫。在此實施例中，檔案系統414可根據非同步檔案操作標準立即回傳一值780並且在之後使用頻外(out of band)通道(例如信號)與請求應用程式軟體412進行通訊。
第三，檔案操作可以是同步的，但是具有時間限制。一些檔案系統支援等待用於通訊通道(例如網路裝置、檔案插座或導管)之一組時間的能力來呈現或接受資料。POSIX等待檔案的方法為發佈select()系統呼叫。在本發明實施例中，FS用戶端415設定定時器並發佈select()命令至等待回覆的各種儲存裝置。若在設定時間限制內沒有回覆，則檔案系統414可自由的回傳逾時狀態780至請求應用程式軟體。本發明實施例可使用網路進行通訊，預期小於平均儲存網路延遲的等待時間應該會逾時。其他實施例可允許個別的FS伺服器執行本身的時限，但是必須仔細的監控網路延遲而允許檔案系統414適時回傳一值至請求應用程式軟體412。
第四，可以對所有的儲存提供者執行適當的檔案操作，但是至少一個儲存提供者會出現錯誤狀態。例如，將資料寫入不存在檔案的請求會產生這樣的錯誤狀態。此處，FS用戶端415具有多種選擇。檔案系統414可回傳單一錯誤780至足以摘要聚合錯誤狀態的應用程式軟體412。檔案系統414可以優先權順序來排列錯誤狀態，並回傳最嚴重的錯誤。否則檔案系統414可回傳由最大量儲存提供者所湖傳的錯誤狀態。熟悉此技藝之人士可以在不脫離本發明的範圍內發明其他方法來聚合錯誤。
另外，FS用戶端415可辨識錯誤，並且對至回傳錯誤的少一儲存提供者重播檔案操作請求。某些錯誤可能起因於檔案資料複製中的內部不一致，例如離開同步狀態。本發明實施例的儲存伺服器具有處理這種狀態的機制(以下會詳細說明)。同樣的，這些狀態隨時都有可能發生，且FS用戶端415將這些狀態視為暫時的。在這樣的例子中，FS用戶端415可以在之後重播檔案操作請求。若重播失敗，則檔案系統414可回傳錯誤狀態780至應用程式軟體412(如上所述)。
儲存提供者作為同級組
儲存提供者可以很便利的藉由將檔案資料與儲存元資料的副本儲存於不同的儲存伺服器上來防止硬體失效或網路失效。基於此理由，本發明實現的檔案儲存系統可建立與維持同級組來作為儲存提供者。同級組是在各種儲存伺服器上執行並且合作來控制對檔案或其儲存元資料之存取的一組同級服務(稱為節點)。節點可控制其操作伺服器上的至少一磁碟驅動器或是一些容量(可鑲嵌檔案系統)。根據可攜式設計原則，同級組可出現於FS用戶端415作為具有單一網路位址的單一儲存提供者。值得注意的是，在其他實施例中儲存提供者可以為單一儲存伺服器。
第11圖顯示本發明實施例之同級組的邏輯元件的示意圖。本發明實施例的每個儲存伺服器，例如第5圖中的伺服器1(1110)具有各種儲存裝置(硬碟)1120、1122、1124與1126。同級組可包含於在一些儲存伺服器上執行的處理器或節點中。在本發明實施例中，每同級組的節點數量(在此稱為”基數”)固定為三個，即使在其他實施例中每個同級組中可能具有更多或更少節點，且對特定實施例來說基數可以是固定的(例如，在一些實施例中每同級組可固定為兩節點，而在其他實施例中每同級組可固定為三個節點)，或是在特定限制內為可組構的(例如，基數可以組構為每同級組具有兩或三個節點)。在一般的實施例中，所有的同級組需要具有相同的基數，即使其他實施例可適用於支援混和基數的同級組(例如，對不同的檔案類型或檔案備份目的支援不同的儲存層(storage tier))。以下的實施例說明具有三個節點的同級組。如下所述，當同級組具有三個節點時(或是奇數節點)，當大部分的節點(例如三個節點中的兩個節點)操作彼此一致時可以便利的組織一些處理步驟。然而，當同級組僅具有兩節點時(或是偶數節點)，且在沒有克服一致性的處理步驟中，可加入外部實體(例如指定的管理節點)來解決不一致性的問題。
在第11圖三節點的實施例中，同級組1130係由在伺服器1(1110)上執行的節點1，伺服器8(1112)上的節點2以及伺服器6(1114)上的節點3所構成。每個實體伺服器可同時執行不同同級組中的數個節點，但每個節點僅可屬於一同級組。為了簡化起見，此處僅說明一同級組，即使一般的實施例可執行使用這些三個伺服器的四個同級組(用於12儲存裝置的12個節點)。
每個同級組可指定主要節點，例如在伺服器6(1114)上執行的節點3。同級組中的非主要節點為指定的第二節點。主要節點可用來調節應該出現於用戶端好像由單一儲存提供者執行的一些功能。如第12圖所示，主要節點可能是同級組中唯一與用戶端進行通訊的節點。主要節點也可以確保儲存元資料與檔案資料在同組中所有節點之間適度的同步，以維持檔案操作的一致性。根據組間(intra-set)資料複製策略，主要節點可使用RAID技術(分散連結、硬碟鏡像以及維持同位)來將檔案資料分配於同級組的伺服器之間。在該步驟740中已說明使用此策略的優點與缺點，必須瞭解的是在同級組的節點之間複製資料比在儲存提供者之間複製資料更佳。其中一樣優點為將處理步驟的細節與用戶端隔離。在第15圖中將會說明同級組內的主要節點可控制與其他節點同步的可信賴資料。
在本發明實施例中，每個同級節點接會被指定一標籤或是用來分辨在同級組中的節點與所有其他節點的其他名稱(又稱為”顏色”)。例如，如圖中分別將儲存媒體1122、1132與1134標籤為”R”、”G”與”B”，一節點可以被指定為紅色，一節點可以被指定為藍色，且第三節點可以被指定為綠色。即使顏色可用於其他目的，但是在本發明實施例中的顏色是用來仲裁必須執行既定請求之同級組數量的選擇，使得請求分佈於同級組節點之間。顏色的選擇可以是任意，只要同級組中的每個節點具有不同的顏色的。傳送至(例如使用以下將說明的IP多播)同級組的每個請求係接收同級組的每個成員的初始處理程序來判斷那個同級組成員將要控制該處理程序。此決定可使用部分請求上的散列機制(例如用戶端的訊息ID或IP位址或是這些項目的一些組合)來執行。因此，同級組的每個成員可以在不需要同級組成員之間通訊的情況下判斷那個”顏色”同級將要執行每個請求的處理程序。若由同級決定的請求為由該同級根據其顏色所執行，則同級執行該處理程序，否則同級可忽略剩餘的請求。值得注意的是，此實施例中的顏色指派與主要/次要角色的指派是分開的。節點可以轉換角色(例如從主要轉換為次要，反之亦然)，但是節點不會改變顏色。同樣的，取代同級組中的故障節點的節點會繼承故障節點的顏色但是沒有一定要繼承所取代節點的角色。
使用IP多播與同級組進行通說
本發明實施例的同級組控制三個節點。為了提供提高的可用性，本發明可以將屬於一同級組的唯一節點置放於任何特定的儲存伺服器。在此方法中，若實體伺服失效，或是若該伺服器上的節點失效，同級組仍可包含其他節點來處理檔案操作請求。根據可攜性與隔離度原則，儲存用戶端上的檔案系統414不知道實體儲存伺服器的數量。為了提供服務效率，儲存用戶端可與由具有單一網路訊息之儲存提供者控制的所有實體儲存伺服器接觸。
因此，在本發明實施例中，儲存系統可對每個儲存提供者指定一多播IP位址，且用戶端可傳送檔案操作請求至此位址。熟悉此技藝之人士都知道IP多播，在網路社會(Internet Society)RFC 1112：IP多播的主機延伸(Aug.1989)以及網路社會RFC 3170：IP多播應用程式：挑戰與解答(Sept.2001)該兩個參考文件中有說明。IP多播位址使用與單播(unicast)位址相同的格式，但具有不同的位址範圍。其他實施例可使用單播(單主機)IP位址與儲存提供者接觸，使用單播位址與由提供者控制的每個實體伺服器接觸，或是具有其他的通訊模式。
當將額外的伺服器增加至儲存系統時，可能會增加儲存或處理容量，並且有更多的同級組會增加至該系統。在本發明實施例中，系統管理者可重新組構儲存系統來辨識額外的伺服器以及增加同級組。在其他實施例中，儲存系統可自動偵測新的伺服器，並且自動的重新組構同級組清單。例如，系統可使用動態主機組構通訊協定(Dynamic Host Configuration Protocol,DHCP)。DHCP在參考文件：網路社會，請求說明(RFC)2131：動態主機組構通訊協定(Mar.1997)中有做說明。在這樣的實施例中，儲存伺服器可以在系統管理者沒有額外組構的情況下自動向DHCP伺服器請求組構參數，例如主機IP位置。使用以下說明的會員通訊協定可將同級組IP(多播)位址指派給同級組的成員。
第12圖使用第4圖的電腦網路來說明用戶端與同級組之間的通訊。儲存用戶端410可存取FS透過網路420與同級組1210進行通訊的用戶端415。值得注意的是，儲存系統管理者可指定IP多播位址給同級組1210，例如227.0.0.1。同級組中的每個節點1222、1232與1242可以被設定來聽取傳送至此多播位址的用戶端儲存訊息。然而，主要節點1242可以是組構用來回應這類訊息的唯一節點。因此，由主要節點1242傳送的單一訊息可回答由FS用戶端415傳送的每個訊息以簡化FS用戶端415與同級組之間的網路通訊。
本發明實施例的分散式處理組構是有效率且簡單的。在效率方面，用戶端只需要傳送單一訊息來執行請求。由於該群組的所有成員同時傳送訊息，多播請求允許有效率的執行每個請求類別，因此僅具有單一回應。由於只有在到達最接近節點的交換器時才會複製封包，因此第6圖的交換器組構可有效率的處理用戶端網路上的流量。由於本發明的組構避免對中央管理系統所需要精確指出故障的需求，因此本發明的組構是簡單的，此處的分散式實施利避免對集中故障偵測的需求。
接下來是一些與多播有關的額外參考文件：
[CISCO-99]Cisco系統公司在1999年所發表之”簡易多播部屬”。
http：//www.cisco.com/warp/public/cc/techno/tity/ipmu/tech/ipcas_dg.pdf。
[CISCO-02]Cisco系統公司在2003年所發表之”Cisco IOS設定檔發佈12.1(13)E7與12.2(12)b-對金融企業用戶的系統測試”。
http：//www.cisco.com/application/pdf/en/us/guest/products/ps6592/c1244/cdccont_0900aecd80310d60.pdf。
[CISCO-05]Cisco系統公司在2005年於Whitepaper所發表之”Cisco 7600路由器：對視頻部屬的彈性與可用性”。
http：//www.cisco.com/application/pdf/en/us/guest/netsol/ns610/c654/cdccpmt_0900aecd80322ce1.pdf。
[QUINN-03]Michael Jay Quinn在2003年於McGraw-Hill Professional所發表之”C語言中具有MPI以及OpenMP的平行程式”。
[DEMIRCI-02]Turan Demirci在2002年九月中東科技大學(Middle East Technical University)電機與電子工程系所發表的論文以及在2003年第八屆IEEE電腦與通訊國際研討會所發表之”對即時IP多播的效能研究”。
[GRANATH-06]Derek Granath在2006年七月網路系統設計線(Network System Design Line)所發表之”對下一代乙太網路交換器設計的最佳化”。
http：//www.networksystemsdesignline.com/showArticle.jhtml；jsessionid=2GUIWZFYBGDIOQSNDLRSKH0CJUNN2JVN？articleID=189401062。
[RFC-1112]S.Deering在1989年八月於STD 5，RFC 1112所發表之”對IP多播的主機延伸”。
[RFC-1700]J.Reynolds與J.Postel在1994年時月於ISI所發表之”指定數量”。
[RFC-2113]D.Katz在1997年二月於Standards Track所發表之”IP路由器警示選項”。
[RFC-2236]W.Fenner在1997年十一月於RFC2236所發表之”網際網路群組管理通訊協定第2版”。
[RFC-3376]B.Cain在2002年十月於RFC 3376所發表之”網際網路群組管理通訊協定第3版”。
[SSM-02]Bhattacharyya,S等人在2002年三月於Internet Draft所發表之”特定來源多播(Source-Specific Multicast,SSM)概要”。
同級組之一節點內的資料佈局
對位址的第一次發佈為儲存區域內儲存元資料檔案的名稱空間(namespace)。若兩個不同的目錄具有相同的名稱便可將其元資料儲存於相同的儲存區域。給定路徑/docs/joe/pdf/file.pdf，本發明實施例可散列父目錄名稱pdf來判斷表索引與同級組。給定路徑/apps/adobe/pdf/pdfviewer，用戶端可散列父目錄名稱pdf來尋找相同的表索引與同級組。儘管最後兩個目錄具有不同的檔案路徑，若其對散列函式使用相同的輸入”父目錄名稱pdf”，則本發明實施例可判定兩者為相同同級組。因此，目錄名稱pdf不具有足夠的資訊將/docs/joe/pdf與/apps/adobe/pdf指派於相同的儲存區域。為了避免衝突，本發明實施例可使用全路徑名稱來儲存儲存元資料。由於兩個末端為pdf的目錄可由相同同級組來控制，因此可根據其全部且絕對路徑將其儲存於同級組的儲存區域內。
此機制具有一些優點。首先，若目錄被重新命名，只需要對其與其直接的子目錄進行散列處理並將其移動至另一儲存區域。由於只需要轉移儲存元資料而不是檔案資料，因此這樣的服務分裂使用最小頻寬。接下來，每個節點可使用其原有的檔案系統來察看路徑，並保證路徑名稱衝突不會發生。同樣的，對同級組中每個節點的重新命名目錄可平行完成。然而，其他實施例可將元資料以更適合不同應用程式的其他方式儲存，且熟悉此技藝之人士應該瞭解必要時如何改變重複的名稱空間。
對位址的下一次發佈為儲存區域內資料檔案的名稱空間。檔案資料不需要使用用戶端要求的名稱來儲存。扁平(flat)目錄結構比起深層(deep)結構需要較少的目錄查找。然而，當目錄中儲存較多檔案時，由於存取相關資料檔案的機制，因此目錄內的查找速度會變的比較緩慢。因此，最快速的檔案查找出現在目錄樹中，其中每個目錄的容量是固定的並且具有有限數量的列舉子目錄，其中固定數量可根據硬體與軟體可用性調整來調整反應時間。在一般機制中會對每個檔案指派特定的檔案ID(與重新命名或透過全球檔案系統階層的移動無關)。檔案可根據特定ID儲存於目錄路徑。
第13圖顯示本發明實施例中儲存伺服器內之節點中的資料儲存區域以及元資料儲存區域。每個儲存伺服器執行至少一節點，例如節點1310。每個節點可控制至少一儲存量。節點1310分別控制兩個目錄樹1320與1330的儲存元資料與檔案資料。在一些實施例中，目錄樹1320與1330是獨立的可嵌入檔案系統，而在一些實施例中不是獨立的可嵌入檔案系統。一目錄樹可以為一根檔案系統，且其他數可以設置於根檔案系統的目錄內，或是兩個數皆可嵌入第三檔案系統中。
目錄樹1320包含儲存元資料儲存庫(metadata repository)(MDR)。在本發明實施例的儲存系統中，當用戶端檔案系統414請求檔案時，儲存元資料可設置於檔案系統中並且具有特定的相同絕對路徑。儲存元資料係以此方法儲存來促進其快速擷取。因此，當用戶端對具有指定路徑的檔案執行檔案操作請求時，儲存伺服器可透過將路徑應用至其元資料檔案系統來擷取該檔案的儲存元資料。當具有任何檔案系統時，元資料檔案系統包含根目錄1322、數個階層式設置的目錄1324以及數個檔案(例如檔案1326)。在一些實施例中，儲存元資料儲存庫不是根檔案系統，但是包含於根檔案系統中的目錄(例如/MDR)。在此方法中，儲存伺服器可將儲存元資料儲存庫與其他檔案(例如作業系統檔案與檔案資料儲存庫)分離。
目錄樹1330包含檔案資料儲存庫並且具有簡單的結構。該樹的基底為根目錄1332。列舉於十六進位00 1334至FF 1336的目錄多達256個，可包含於樹中的每個目錄。例如，目錄1338(B3)包含子目錄1340(1A)。每個葉子檔案的名稱(例如檔案1350)可包含完整的散列值，在此力中為B31A。
在一些實施例中，世代計數器可儲存為部分的檔案名稱。此計數器可由同級組使用來確保由同級組所控制的每個檔案皆適當的與每個檔案資料儲存階層同步。因此，檔案1350從儲存庫之根目錄的資料檔案全路徑可以為/B3/1A/B31A-17。每當寫入或覆寫檔案中的資料時計數器會增加。此計數器致能資料檔案一致的在同級組之間移動--當檔案複製至新的同級組，其技術器會增加，使得副本不會覆寫已儲存於新同級組中的舊檔案資料。在此方法中，儲存伺服器可將檔案資料儲存庫與其他檔案分離，例如作業系統檔案與儲存元資料儲存庫。
該世代計數器也可用來簡化其他實施例的操作。例如，使用世代計數器可完全避開執行檔案讀寫鎖定的一些挑戰。本發明實施例僅可允許新增、讀取、覆寫與刪除功能，但不具有更新功能。實際上，由於避免競賽條件，因此這些檔案操作會比包含更新的全組更容易實現。這樣的實施例可實現此功能性如下。新增操作可檢查具有任何版本之適當名稱之檔案的存在，新增版本1或是當檔案已存在時回傳錯誤。讀取操作可設置檔案的最新版本並回傳其資料。刪除操作可以在不干擾進行中讀取操作的情況下標記要刪除的元資料。覆寫操作可以在不干擾進行中讀取操作的情況下設置檔案的最新版本，建立新版本，寫入新版本，並且更新元資料(若其仍存在)。這樣的實施例可定期執行垃圾回收(garbage collector)處理步驟而對檔案系統中的檔案與其元資料做比較，並且當不具有進行中的讀/寫操作時永久刪除檔案與其元資料。
目錄樹1320中的儲存元資料與目錄樹1330中的檔案資料有關。在本發明實施例中，每當用戶端新增檔案，控制同級組對檔案指定特定檔案辨識器。例如，特定的檔案辨識器可藉由將新增檔案的同級組ID與同級組內新增的檔案計數器合併而形成。此演算法可用來新增第10圖中所討論不透明的檔案資料儲存名稱。
如第13圖所示，一旦同級組新增儲存名稱，其可建立資料檔案1350本身，並且新增與資料檔案1350有關的儲存元資料檔案1326。接下來，同級組可根據儲存元資料複製策略(硬碟鏡像)與組內檔案資料複製策略來複製本身同級組中所有儲存伺服器的儲存元資料與資料檔案。如下所述，由於複製可能為資源密集型，因此主要節點可在非同步佇列中佇列請求來執行複製。
最佳化小檔案
在一些應用程式中，儲存系統可以對小檔案提供非常快速的存取。例如，網頁佈告欄系統可允許使用者選取小圖像來顯示其線上人員，稱為虛擬使用者(avatar)。這些虛擬使用者通常不會大於幾千位元組，有些佈告欄具有最大尺寸限制。另外，在網頁佈告欄與部落格中的貼文通常是文字，且其尺寸為幾千位元組。對這些應用程式來說，提供快速存取描述貼文或虛擬使用者之小檔案的儲存系統在系統回應時間方面具有優勢，並且可具有改善的使用者滿意度。
本發明實施例可藉由使用扁平儲存來對小檔案提供快速存取。在扁平儲存的實施例中，儲存媒介(例如硬碟或硬碟區域)會被劃分為相同尺寸的儲存區域或是延伸區。每個延伸區可以為例如一千位元組、四千位元組或其他適當的尺寸。例如，延伸區可與實體硬碟區塊具有相同的尺寸。”小檔案”為資料佔據有限數量延伸區直至罪大檔案尺寸的任何檔案。在這樣的實施例中，特定延伸區的數量可透過簡單的乘法映射至實體位置。因此，若延伸區為四千位元組(十六進位的0*1000)，第一延伸區開始於儲存媒體的位元組0*0000，第二延伸區開始於儲存媒體的位元組0*1000，諸如此類。在其他實施例中，至少一延伸區可作為儲存系統的位元映象(bitmap)，使得其可判斷哪些剩餘延伸區包含小檔案資料。在此實施例中，可在加法(用來偏移位元映象尺寸)之後的乘法中找到實體位置。因此，若前兩個延伸區作為位元映象，則第二檔案資料可設置於例如0*1000(第二檔案)+0*2000(偏移)=0*3000。加法之後的乘法存在於一些先進電腦結構中作為低階硬體基元，使用時可增加硬碟上組構檔案之儲存系統的速度。本發明實施例可以在系統管理者請求時或是根據系統組構資料指示新增小檔案儲存區域。
對不直接與檔案儲存之實體位置有關的小檔案使用命名機制在很多方面是有利的。若延伸區數量直接使用命名機制，不論資料是否儲存於實體儲存器，應用程式可直接存取實體儲存器。這類型的存起可能造成資料損壞。同樣的，若在適當的地方使用相同的名稱來修改檔案，則不具有與檔案資料先前板本有關的歷史資料。且若檔案名稱連結至實體儲存偏移，則難以辨識那個伺服器管理保留此特定檔案的小檔案儲存庫。因此，每個小檔案在儲存系統實施例內應該具有全域唯一ID。
因此，儲存系統內的小檔案可根據下列範例機制來命名。檔案名稱可包含新增該檔案之同級組的ID。在本發明實施例中，儘管此ID將不會為檔案的葉而改變，然其他同級組可接管管理檔案。在其他實施例中，僅有新增檔案的同級組可以管理檔案。檔案名稱亦可於其開始處包含磁碟上延伸區的數量。在包含此命名元件的實施例中，檔案必須常駐於磁碟的固定位置，並且無法移動(例如對磁碟執行解片段(defragment))。檔案名稱可包含佔據磁碟之連續延伸區的數量。在包含此命名元件的實施例中，檔案尺寸的增加不可以超過此延伸區數量。這樣的實施例可儲存由實體磁碟之特定部分或是儲存元資料檔案中的檔案所消耗的實際位元組數量。同樣的，檔案名稱可包含檔案的世代編號，以確保可以辨識在不同時候使用相同延伸區的兩個檔案。完整檔案名稱可與任何或所有的此資訊結合，例如將其連結在一起。完整檔案名稱可嵌入URL中而由網路瀏覽器或是其他應用程式直接存取來擷取小檔案。
本發明實施例可處理大量的小檔案，並且為了方便起見可使用子母字串、十六進位字串或是其他命名規約來命名。本發明實施例的小檔案可使用人造路徑來進行存取。例如，可以指定虛擬目錄作為小檔案的存取定。這樣的目錄可以命名為例如/smallfiles。因此，對嵌入儲存用戶端之儲存檔案系統/storage上命名為XYZ之小檔案的請求可以透過用戶端應用程式作為/storage/smallfiles/XYZ來存取。然而，此檔案路徑不可對應至儲存系統中的實際目錄結構，本發明實施例可將路徑/smallfiles/CD3A解釋為”從平坦儲存媒體之起始位元組0*0CD3A000處存取四千位元組的資料”作為代替。另外，本發明實施例可以將CD3A作為包含儲存媒體上小檔案之起始實體偏移之表的表索引。
這些小檔案的最佳化可以與進一步的最佳化合併於本發明實施例中。任何特定磁碟驅動器具有可達到每秒最大量的I/O操作。此數量通常與讀取或寫入驅動器的資料量無關。由於重新設置驅動總數的個別請求係作為獨立操作，並且開始執行驅動存取時間最相關的部分，可以在單一操作中讀取連續檔案(而不是透過多次請求)是有利的。一般來說，大部分的檔案系統首先需要請求存取參考檔案的目錄，接下來另一者存取檔案元資料，因此可以知道要在哪裡找到檔案資料並且請求存取資料。這是單一讀取必要的三個操作。若檔案元資料與資料相鄰，且檔案的位置嵌入於檔案名稱中，則前面兩個操作不必要並且可以在單一I/O操作中讀取元資料+資料。這會使每次驅動的I/O數量至少降低3，並因此允許驅動來供應更多的請求。這對每個隨機存取的小檔案來說是很重要的，因為隨機性無法儲存於快取記憶體中。對這樣的檔案(也就是小型檔案等等)來說，降低I/O操作的數量會降低驅動需要達到特定流通量之儲存基礎結構的數量。例如，節點可接收對某些檔案之元資料的請求。對該檔案的儲存元資料可包含指示器來只是此檔案為小檔案，並且亦包含小檔案的路徑，例如/smallfiles/CD3A。接下來，節點可使用此路徑從其本地儲存媒體擷取檔案並且透過儲存元資料將其回傳。此最佳化要避開第7圖的步驟740至772，以降低反應時間與網路頻寬來增加效能。在其他實施例中，節點可具有判斷是否立即回傳該檔案之小檔案或儲存元資料的邏輯。這樣的邏輯可能會在例如當小檔案快速改變時有用，且任何特定節點可能無法判斷其是否包含最新版本的特定檔案。
在其他實施例中，小檔案的最佳化可與讀寫鎖定迴避功能合併。本發明實施例可簡單對檔案指定新名稱而不是在如第13圖所示在寫入每個特定小檔案時建立新的世代編碼。在此實施例中，節點可更新具有新的延伸區來使用之小檔案的位元映象，並且標記要刪除之舊的延伸區。
以下將會說明本發明實施例的小檔案儲存庫。
非同步佇列
本發明實施例的儲存系統可包含可高度擴充、全系統、非同步、基元佇列機制的永久儲存。有時後，儲存系統可執行資源密集操作。這些操作包含，例如附至檔案資料、複製儲存元資料並且解決檔案資料差異以確保資料的一致性。藉由降低對用戶端的處理電力、頻寬或是可用儲存器來執行這樣的操作不應該顯著降低儲存系統的效能。當可以使用足夠的處理能力時，藉由在永久佇列中設置這樣的資源密集操作使得儲存伺服器可有利的執行這些操作。因此，不會顯著的降低系統效能。
第14圖顯示本發明實施例與佇列通訊之元件的方塊圖。熟悉此技藝之人士知道佇列是以先進先出(First In First Out,FIFO)方式來執行資料記錄的機制。範例佇列1410包含第一記錄1420、第二記錄1430以及第三記錄1440。佇列可以不包含記錄或是包含任何數量的記錄，且佇列中的紀錄數量可隨著時間根據儲存系統需求而改變。如圖所示，可以從佇列頂部(箭頭1412)取出記錄進行處理，並且將紀錄增加至從佇列底部(箭頭1414)。因此，第一記錄1420是在第二記錄1430之前加入佇列，而第二記錄1430是在第三記錄1440之前加入佇列。
本發明實施例之佇列允許系統元件使記錄進入佇列，並可允許任何系統元件將記錄離開佇列。在此方法中，記錄製造者可與記錄消費者去耦合。在本發明實施例中，同級組的一節點管理同級組的佇列操作。此節點可以為主要節點，或是可以為特定顏色的成員。這樣的組構對於在任何既定時間點處具有多個佇列請求的佇列是有利的，且處理這些請求可能消耗相當多的系統資源。在其他實施例中可允許同級組中的每個節點與佇列互動。
佇列系統可支援新增、維持與刪除至少一佇列1410。佇列系統中的每個佇列皆可具有名稱。在本發明實施例中，佇列名稱可由檔案路徑名稱元件組成。這樣的命名機制在具有與路徑有關之任務的儲存系統中是有利的，例如將目錄中的儲存元資料或檔案資料從同級組中的一節點複製至另一節點。其他佇列系統的實施例可以對獨特的識別佇列使用任何相容的命名，例如POSIX ftok()功能。
佇列系統可使用租賃系統。若一節點從佇列取出一任務(例如資料移動任務)，而該佇列在任務完成前故障，如此一來會造成資料不一致。因此，佇列租賃可保證在任務離開佇列之前完成該任務。在第14圖中，將第一記錄1420租賃1422至在伺服器1424上執行的第一節點，並且將第三任務1440租賃1422至在伺服器1444上執行的第二節點。由於佇列中的紀錄係以FIFO順序進行處理，此圖示係與在允許租賃1442之前對第二記錄1430進行租賃的第三節點(未圖示)一致，但是無法完成此任務。記錄1430因此留在佇列中在之後讓其他節點進行處理。佇列租賃可包含資訊，例如記錄與租賃碼的識別，租賃時間以及租賃持續期間。
佇列系統可具有多種能力。此系統可允許使用者新增具有特定名稱的新佇列。此系統可允許使用者將佇列的所有就項目清空。或者，此系統可允許使用者完全地刪除佇列。一旦設置適當的佇列，系統可允許使用者非破壞性的讀取佇列中的紀錄，並且當佇列為空佇列時選擇等待一段時間來等待記錄變為可使用的。或者，此系統可允許使用者製造佇列記錄並且藉由取得租賃而使其他使用者無法看到，選擇等待一段時間來等待記錄變為可使用的。當租賃過期時可藉由其他節點進行處理使得紀錄變為可見的。此系統亦可允許使用者調整租賃時間長短。若處理記錄的時間比使用者預期的更長時便可使用這樣的功能。系統可允許使用者將記錄附加至佇列末端，選擇等待值到記錄轉移至永久儲存器。
使用儲存系統本身的永久儲存器提供者可有利的儲存佇列紀錄。在此方法中，一旦某些實體儲存伺服器基於某些原因故障了仍可保存記錄。若實體儲存伺服器發生故障的情況，如第15圖所示，儲存系統可將佇列記錄視為任何其他形式的資料檔案，並排程將其複製至其他節點。在本發明實施例中，為了避免系統因為伺服器故障而遺失與該同級組有關的佇列任務，因此與特定同級組有關的佇列記錄不應該由該同級組來儲存。佇列記錄可儲存於檔案系統階層中並且與儲存元資料與檔案資料分隔。佇列可以任何便利的方法來命名。
在一些實施例中，特定路徑的紀錄係儲存於僅能附加(append only)的檔案中。由於該路徑的紀錄已進入佇列，因此該記錄的資料係附加至檔案。記錄檔案可包含與設置於該檔案中紀錄有關的索引項目以及包含資訊。索引項目可包含，例如每個記錄的名稱、在檔案中的偏移，建立時間、租賃的開始時間以及租賃長度。藉由附加具有更新資訊的新索引項目可更新或刪除佇列中的紀錄。再者，每個目錄可包含一索引項目，用來保持在該目錄之子目錄之記錄檔案中的索引項目偏移軌跡。當新的索引儲存至記錄檔案的末端處時，新的索引項目會新增至具有此新資訊的父目錄記錄末端。由於父檔案之索引記錄的偏移已改變，其父檔案以及階層根部等等可以被更新。在此方法中，不需要刪除任何檔案或任何檔案中的資料即可將記錄從佇列移除。在這樣的觀點，當記錄檔案變大並且充滿超過特定百分比的舊資料時，佇列系統可建立新的紀錄檔案並且更新父記錄檔案來反應新紀錄檔案的名稱。
以下會說明範例的佇列系統。
節點故障與自行復原
基於一些理由，儲存節點可能會無法執行所有功能，包含硬體故障、軟體故障、網路中斷或是電力故障。若有適當的硬體，則當發生故障時，同級組可自動置換故障的節點而不需要管理者的介入。本發明實施例的儲存系統可採取四步驟來回復故障的儲存節點：偵測、選取、複製與置換。由於複製可能為資源密集，非同步佇列可用來分散負載。
第15圖顯示在修復遺失第二節點期間由同級組節點與非同步佇列所採取的相關動作以及在兩者之間傳遞訊息的時序圖。在發生故障之前，儲存系統必定是穩定的。儲存系統管理者於時序圖頂部啟動系統。佇列系統首先初始1510包含驗證儲存於全儲存系統之佇列資料的一致性。每個伺服器初始1512一處理程序包，包含啟動作業系統，驗證網路連接性，初始儲存軟體或硬體以及其他例行任務。儲存系統形成同級組，且三個節點皆加入1514相同的同級組。加入同級組可包含在不同同級之間傳送非同步訊息以及健康訊息。值得注意的是，每個同級可接受來自至少一其他同級的租賃，如下所述。一旦節點建立穩定的同級組，便可開始1516操作來自儲存用戶端之檔案系統的請求，如較粗的時間軸所示。
經過一些時間之後，第二節點之一者經歷1520系統故障。節點故障的偵測在回復處理步驟中是很重要的第一步。藉由增加或移除節點，儲存系統造成對重建同級組的本質損失。任何僅儲存於該節點伺服器的資料遺失了。最終必須使用組構檔案複製政策來重置由節點所控制的所有儲存元資料與檔案資料。在磁碟I/O、網路流量與延遲時間方面，選擇重置節點、資料複製與回復服務是相當昂貴的操作。
儲存系統可使用與佇列租賃系統相似的健康租賃系統來分辨暫時性的故障與永久故障。租賃期間可由儲存管理者根據例如伺服器故障的平均時間、系統中的伺服器數量、平均網路延遲時間、所需要的系統回應時間以及其他相關因素等標準的調整而將系統效能最佳化。或者，可由儲存系統使用關於系統的動態效能例如目前的系統負載、實際網路延遲時間以及其他相關因素自動地判斷租賃期間。
同級組的每個主要節點可請求對每個第二節點進行一段時間的租賃。在本發明實施例中，每個第二節點僅請求對主要節點的租賃。在其他實施例中，同級組中的每個節點可請求對所有其他節點的租賃。當租賃時間經過一半時，每個節點可企圖更新其租賃。因此會在租賃時間結束之前對租賃進行更新。若租賃在執行更新之前結束，租賃持有者可企圖使用標準網路查詢工具(例如ping或tranceroute)或是使用特別為此目的撰寫的軟體直接與租賃授與者接觸。這樣的軟體可具有簡單的設計，且熟悉此技藝之人士應該瞭解如何實現。若幾次連結再試不成功，則租賃持有者可推斷無法到達租賃授與者或是租賃授與者故障，並且完成第一步驟的修復與偵測。接下來，節點可進行至第二步驟：選擇重置節點。
在處理程序1522中選取重置節點。在這四個步驟中的第二步驟針對遺失節點判斷適當的重置點。在此步驟中的原則考量為避免特定的競賽條件。假設主要節點與第二節點因為網路中斷而無法彼此接觸，但兩節點皆可完全地作用。每個節點將假設另一節點是故障的，並且希望選取新的節點來取代故障節點。若每個節點皆順利進行，儲存系統將具有兩個同級組，每個同級組皆請求第三可用節點。然而，這樣的狀態是無法被接受的，因為一節點僅可加入一同級組。因此可使用仲裁系統(arbitration system)。
在本發明實施例中，每個同級組皆具有以循環法指派的監督同級組，作為節點重置期間的仲裁者。同級組#0監督同級組#1，而同級組#1依序監督同級組#2，依此類推。新增至的最後同級組係監督同級組#0。在步驟1522中，當節點判斷另一節點為無反應，其可與監督同級組接觸以取得重置其他節點的許可。監督同級的主要節點可判斷重置節點並且回應，然其僅可回應所接收的第一請求。因此，監督同級僅可回應中斷的同級組中剩餘節點之一者。接著，此節點可成為該同級組的主要節點。
在本發明實施例中，若請求節點為第二節點，則另一節點為主要節點，並且需要新的主要節點。在此實施例中，與監督同級組接觸的第一節點變為新的主要節點。(由於所有的第二節點皆持有來自主要節點的過期租賃，因此所有的第二節點皆應發出請求。)若若發出請求的節點為主要節點，則另一節點為第二節點，因此新節點將會是第二節點。(在此實施例中，只有主要節點會發出請求。在其他實施例中，所有的節點皆可發出請求，且第二節點可勝過主要節點。在這樣的例子中，對請求者而言主要節點變為第二節點。)
在此實施例中，第二節點故障，使得原始主要節點依然為主要節點。一旦取得許可，主要節點可傳送1524加入訊息至新節點。接下來，備用節點可加入1526該同級組。由於備用節點不包含任何同級組資料，因此不是該同級組的全功能成員。因此，主要節點可傳送1528複製任務至佇列，該任務接著會進入佇列1529。同級組的主要節點亦可對世代計數器增量來對任何用戶或伺服器發出成員改變的警示。該節點現在可繼續進行至第三步驟：複製。
當主要節點通知1530剩餘第二節點開始進行複製時適合開始複製步驟。儘管範例同級組包含三個節點，然在其他實施例中可包含更多的節點，且在這樣的實施例中，主要節點可藉由任何適當的標準(例如計算負載)選取第二節點來控制複製步驟。被選取的第二節點可接著向佇列查詢1532適當的任務來執行。將會找到透過主要節點進入佇列的任務，並且也可找到其他任務。接下來，如第14圖的所述，第二節點可從佇列租賃1534同步任務。不夠長的租賃可能會在同步完成之前過期。因此，節點可根據任務尺寸判斷租賃長度。或者，節點僅可採取相對短的初始租賃，並於每次需要更新時更新租賃來避免租賃失效。
一旦節點從佇列租賃任務，則必須開始與加入節點上的儲存元資料以及檔案資料同步1536。複製儲存元資料與複製檔案資料之間的進行有些許不同。本發明實施例中的每個節點可包含尤其同級組控制之檔案的完整、鏡像、元資料儲存庫。這個策略比較少冗餘策略需要更多的空間，但基於兩個理由因此比較少冗餘策略更佳：第一，儲存元資料檔案很小，因此儲存需求中的差異極小；第二，此策略致能較快速的重建新節點上的儲存元資料。當建立一加入節點時，主要節點可因此指示第二節點將其本身的元資料儲存庫(應該是完整且最新的)複製至新節點。這種授權可有力的平衡主要節點與第二節點之間的負載，降低全系統反應時間。在本發明實施例中，由於加入節點應具有完整的元資料儲存庫，因此移動同級組中節點之間的儲存元資料是立即的，而非懶散的。
當進行元資料移動時可由節點來接收更新儲存元資料的請求(例如檔案重新命名操作)。透過遞迴的遍歷元資料儲存庫可完成移動。遍歷可透過執行縱向優先(depth first)或橫向優先(breadth first)達成--唯一的需求是複製節點必須追蹤哪些元資料是已處理的以及哪些元資料是未處理的。若接收改變元資料的請求，複製節點可進行檢查來判斷是否已將此元資料複製至加入節點。若否，可以簡單的改變本身的元資料-其最終會將更新的元資料複製至加入節點。若已複製元資料，複製節點可將改變傳送至加入節點，之後該節點便可自我更新。
相比之下，檔案資料比儲存元資料大個幾千或幾百萬位元組。對儲存效能來說，檔案資料可儲存於小於充滿加入同級組中的伺服器上。檔案資料複製與儲存元資料複製類似，但是複製節點不需要總是複製檔案資料。只有儲存於無反應節點上的檔案資料需要被複製至加入節點。因此，當主動式(active)節點遍歷其元資料樹，其亦可檢查指示該檔案的儲存元資料是否儲存於遺失的節點中。若是，複製節點亦將檔案資料複製至被動式(passive)節點。若複製節點不具有該檔案資料，其可以對具有檔案資料的其他節點發出請求。若其他節點皆不具有該檔案資料，則將該資料標記為遺失，且用戶端儲存器對該資料所發出的其他請求將會失效。因此，本發明實施例胃了確保檔案資料的可用性，資料至少儲存於兩個節點中，或使用冗餘技術(例如RAID)進行跨同級組的複製。
若基於某些理由導致複製失敗，對該任務的佇列租賃將會過期且佇列中的該任務在之後的再試會再次變得可見。同樣的，若複製失敗發生於第二節點，則主要節點會透過健康租賃系統偵測此狀態，並且將其他節點加入該同級組。假設沒有發生複製失敗，經過一段時間之後複製將會完成，且第二節點可傳送1538完成訊息至佇列。此訊息可指示佇列資料結構使已完成任務離開佇列1539。
一旦將儲存元資料與檔案資料複製至加入節點，則該同級組進入最後階段：重置。在這個時間點之前，加入節點不會回應元資料改變請求或是檔案資料存取請求以避免競賽條件。然而其他節點會代替回應這些請求。當加入節點的元資料與檔案資料為目前的資料時，第二節點可通知1540主要節點已完成複製程序。接下來，主要節點自由的發佈1542啟動訊息至加入節點，加入節點接著開始1546提供檔案系統服務。一旦啟動加入節點，加入節點就是同級組的正式成員，並且代替遺失節點的全部功能。特別注意的是，新節點可對主要節點或其他節點之任一者進行至少一次的健康租賃。因此，兩個原始節點可繼續1544提供檔案系統服務，並且加入第三節點而形成完整的同級組。
為了促進重置步驟，系統中的節點可持續追蹤其同級組的世代計數器。若用戶端對使用過時計數器的同級組發出請求，則同級組中的主要節點可將同級組成員資訊當時的副本傳送至用戶端。另外，若用戶端接收來自具有較新計數器之同級組的檔案操作回應，則用戶端可請求較新的同級組成員副本。
第16A圖與第16B圖分別顯示在第二儲存節點故障期間第11圖的同級組以及在經過第15圖之處理程序修復之後的同級組。第16A圖顯示與第11圖相同的伺服器1110、1112與1114以及同級組1130。然而，節點2(伺服器8)遭受故障(以陰影表示)。一旦同級組偵測到故障狀態，則會選取重置伺服器1610(第16B圖的伺服器3)。此”加入”伺服器執行新節點2。新伺服器中任何未使用的硬碟或儲存空間可以被同級組控制。舊節點之一者將儲存元資料與檔案資料複製至新節點。在本發明實施例中，第二節點執行這些處理程序以有效率的平衡同級組中節點之間的負載。一旦複製了所有的資料，新節點可以作為同級組1130A的正式會員開始回應用戶端檔案操作請求。新節點採用遺失節點的顏色。在第16A圖中係遺失”綠色”節點，因此第16B圖中的新節點為”綠色”。
第17A圖與第17B圖分別顯示第11圖中主要儲存節點故障期間的同級組以及修復過後的同級組。除了目前伺服器6(1114)上的主要節點為無反應(以陰影表示)之外，第17A圖與第16A圖是相同的。除了透過該步驟1522中所描述的選取步驟選擇其他節點之一者為新的主要節點之外，取代主要節點的處理步驟與第16B圖是相同的。在第17B圖中，在伺服器1110上執行的舊節點1變為新的主要節點。並且會新增儲存系統的新伺服器1710(伺服器4)。在此實施例中遺失”藍色”節點，因此在新伺服器1410上執行的節點被指定為”藍色”節點(如圖所示)。此節點加入新組成的同級組1130B。
範例儲存情境
由該儲存系統執行的各種操作係與根據第4B圖的範例儲存系統的各種範例儲存情境有關。在這些情況中，儲存提供者430為該檔案的目標儲存提供者。
儲存於目標儲存提供者中的檔案資料 。在這樣的情況下，該檔案的檔案資料係儲存於目標儲存提供者中。當接收來自FS用戶端的請求時，FS伺服器431可回傳檔案資料或可回傳顯示負責檔案資料之儲存提供者430的儲存元資料。
從目標移動至提供者440的檔案資料 。在這樣的情況下，該檔案的檔案資料係從目標儲存提供者移動至儲存提供者440。FS伺服器431保留標示檔案資料儲存於儲存提供者440中的儲存元資料。當接收來自FS用戶端的請求時，FS伺服器431回傳標示儲存提供者440儲存檔案資料的元資料。接下來，FS用戶端與位於儲存提供者440中的FS伺服器441接觸來取得檔案資料。
從提供者440移動至提供者450的檔案資料 。在這樣的情況下，藉由複製儲存提供者450中的檔案資料而將該檔案的檔案資料從儲存提供者440移動至儲存提供者450。接下來，更新由FS伺服器431保留的儲存元資料，以反應儲存提供者450負責該檔案資料。當接收來自FS用戶端的請求時，FS伺服器431回傳標示儲存提供者450儲存該檔案資料的儲存元資料。接下來，FS用戶端與儲存提供者450中的FS伺服器451接觸來存取檔案資料。標示儲存於儲存提供者440中的檔案資料副本為可刪除。
複製於多個儲存提供者中的檔案資料 。在這樣的情況下，檔案資料被複製至多個儲存提供者中(例如：為了冗餘性或負載平衡而複製在儲存提供者430與440中，在儲存提供者440與450中，在儲存提供者430與450中或是在儲存提供者430、440與450中)。由FS伺服器431保留的儲存元資料包含檔案資料所儲存之所有儲存提供者的清單。當接收來自FS用戶端的請求時，FS伺服器431可回傳顯示儲存該檔案資料之至少一儲存提供者的儲存元資料。若僅顯示一個儲存提供者，則FS用戶端係與所顯示的儲存提供者接觸來存取檔案資料；若顯示多個儲存提供者，則FS用戶端從顯示的儲存提供者中選取一者(例如隨機選取或根據預定策略選取)並且與該所選取的儲存提供者接觸來存取檔案資料。
藉由重置來修改檔案資料 。在這樣的情況下，檔案版本1的檔案資料係儲存於儲存提供者440中。FS用戶端431保留顯示作為負責該檔案資料之儲存提供者440的儲存元資料。當接收來自FS用戶端415的請求時，FS伺服器431將儲存元資料回傳至FS用戶端415，且FS用戶端415與FS伺服器441接觸來存取具有寫入存取的檔案資料。當FS用戶端415持有具有寫入存取的檔案資料時，FS伺服器441允許其他FS用戶端存取該檔案資料，但是僅能存取版本1並且僅能執行讀取存取。在這樣的實施例中，儲存系統不需要複雜的分散式檔案鎖定機制。FS用戶端415修改檔案資料並且將經過修改的檔案資料傳送至FS伺服器441。FS伺服器441將已修改的檔案資料儲存為標示為版本2的個別檔案。對於接下來的請求，FS伺服器441提供對檔案資料版本2的存取。並且將檔案資料版本1標示為可刪除。
藉由附加來修改檔案資料 。在這樣的情況下，檔案本版1的檔案資料係儲存於儲存提供者440中。FS用戶端431保留顯示作為負責該檔案資料之儲存提供者440的儲存元資料。當接收來自FS用戶端415的請求時，FS伺服器431將儲存元資料回傳至FS用戶端415，且FS用戶端415係與FS伺服器441接觸來存取具有寫入存取的檔案資料。當FS用戶端415持有具有寫入存取的檔案資料時，FS伺服器441允許其他FS用戶端存取該檔案資料，但是僅能存取版本1並且僅能執行讀取存取。在這樣的實施例中，儲存系統不需要複雜的分散式檔案鎖定機制。FS用戶端415更改檔案資料並將已更改的檔案資料傳送至FS伺服器441。FS伺服器441將檔案資料附加至現存檔案資料並且將該檔案資料標示為版本2。對於接下來的請求，FS伺服器441提供對檔案資料版本2的存取。
增加儲存提供者 。如上所述，可視需求來增加儲存提供者。該的散列機制在不需要橫跨全名稱空間執行再散列(rehash)與重新儲存資料的情況下就可以進行擴充。
II.針對特定實施例的說明
以下會針對特定實施例做說明，以下稱為MaxiFS。
1.概論
MaxiFS 為Web 2.0公司之檔案儲存基礎結構的名稱。MaxiFS是為了實現作為用1U伺服器商品製造的單一儲存池頂部之純軟體解法的高效能、高彈性、可無限擴充的檔案系統而設計。在預想實施例中之1U伺服器的特徵如下：
1.雙核心CPU
2.4GB的隨機存取記憶體(RAM)
3.4個具有750GB容量的SATA驅動器
4.內建於主機板之雙重1 Gb/s乙太網路NIC花費約$3000可購買具有此特性的系統。
在此實施例中，每個這樣的伺服器節點執行FreeBSD 6.2或是更新的系統(例如FreeBSD 7.0)，並且採用UFS2檔案系統。後者具有非常令人滿意的特性，由於其支援軟體更新[1]，提供對系統資料結構的同步寫入速度，保證該檔案系統同時從一致的狀態轉變為一致的狀態。因此，如果發生系統故障，可以在系統重新啟動後立即存取檔案系統，且其應該在背景中對孤立檔案磁碟區塊進行垃圾回收(garbage collection)。用戶端基礎結構與伺服器節點之間以及伺服器節點之間的所有通訊會發生於IP網路，不論是儲存取向的請求或是管理者查詢或命令。在以下討論通常使用”用戶端”與”伺服器”的用法。對於此討論，用法伺服器(或伺服器節點)識別作為部分檔案儲存陣列的任何1U伺服器，而用法用戶端代表檔案儲存基礎結構的用戶端。期望採用設置於目標市場中的系統，用戶端不是網路用戶端而是客戶所使用的網路伺服器或是應用程式伺服器。下列MaxiFS系統的特性係介於允許可擴充性之間：
1.實現基礎結構的伺服器彼此鬆散的耦合，代替建立於分散是鎖定管理者周圍的部分叢集檔案系統。
2.增加至系統的每個伺服器係以三個方向來擴充系統：儲存量、處理電力以及聚合網路頻寬。
3.在每個基礎結構用戶端上執行的MaxiFS軟體係與基礎結構本身接合並且直接與伺服器互相作用。此用戶端元件可藉由直接與適當數量的伺服器節點交互作用聚合其所需的頻寬，而不需要在用戶端與伺服器之間設置額外的裝置。
以下為MaxiFS結構中的一些主要驅動原則：系統必定為輕型，且系統支援的一致性機制為最終一致性 。這意味著不保證特定檔案的所有冗餘版本皆相同，只要：1.所有的副本將會在有限的時間內收斂為相同版本。2.MaxiFS總是可以分辨檔案的較新版本與先前版本。3.用戶端處理程序不會同時存取相同檔案的不一致副本。4.被用戶端以讀取模式存取的檔案總是可以被用戶端使用直到用戶端關閉該檔案為止，即使檔案的該版本已被較新的版本取代。
由於伺服器的故障與系統故障，不一致性會隨著時間而擴大。然而，期望系統在偵測到不一致時藉由適當的處理這樣的不一致性(也就是避免恐慌或系統故障)並且藉由記錄與修復系統而具有自我修復功能。
MaxiFS實現POSIX檔案系統介面。一些API可根據其他API來進行最佳化，以保證對目標市場區段MaxiFS位址之應用程式的最佳效能，所以被認為很少在感興趣市場區段中所使用的允許其他API具有較低效能。若當API應用會對需要最佳化的部分系統造成負面的效能影響時可以僅實現部分極度受限的API。另外，系統必須具有自我修復功能。這意味著當系統執行時所偵測到的任何不一致應該由系統立即更正而不會影響到用戶端。檔案用戶端的新增與存取係儲存於個別伺服器節點的檔案系統中並且根據用戶設定來進行複製。
2.網路基礎結構
儘管MaxiFS的設計是提供擴充性與可用性，適當的網路佈線必須完全達到這些能力。理想上，MaxiFS係建立於自己的子網路中。在這子網路中，每個伺服器節點中可用的兩個NIC介面應該連接至個別的交換器。不論交換器或一些電纜纜線是否被中斷，這會增加每個節點的冗餘性。很清楚的，當交換器結構為階層式結構時，總是期望確定在相同節點中的NIC係附接至數的獨立分支。伺服器節點中兩個NIC的存在應該可使管線達到最大可用度。這可可能會與具有附接至不同交換器的NIC不一致。然而，由於MaxiFS的網路結構為部分的MaxiFS安裝，因此應該提供適當的詳細指令來確定達到與網路基礎結構相容之可用性的最高可達到等級。
3.MaxiFS名稱空間的結構
文件的這個部分說明MaxiFS提供其用戶端的名稱空間結構，和此抽象作用應用於多個伺服器節點的方式一樣。MaxiFS基礎結構新增分散於構成基礎結構之所有伺服器的總體名稱空間。此名稱空間具有總體根目錄(global root)。MaxiFS用戶端使用MaxiFS軟體來安裝MaxiFS名稱空間中感興趣樹的根目錄。
安裝操作是主要操作，其建立用戶端與MaxiFS基礎結構之間的連結。值得注意的是，此係藉由指定基礎結構名稱而完成，使得相同用戶端可能存取多個MaxiFS基礎結構以及相關名稱空間。此亦擷取用戶端需要在基礎結構內操作的所有相關資訊。這是用戶端學習將儲存於基礎結構中檔案的請求定址於何處的方法。
基礎結構的使用者不需要被限制為僅輸出總體根目錄。其應該具有彈性輸出至其想要輸出之名稱空間的任何子樹(subtree)。本質上，關於MaxiFS唯一的限制為若兩個目錄的其中一者為另一者的上代(也就是若兩樹的交集不是空集合)，則任何MaxiFS用戶端不應該在本地安裝這樣的兩個輸出目錄。
第18圖的實施例中具有兩個用戶端MaxiFS基礎結構與NFS伺服器。MaxiFS基礎結構輸出目錄”dirx”與”a”至其用戶端。NFS伺服器”Z”輸出目錄”z0”至其用戶端。
第19圖顯示當用戶端1透過MaxiFS基礎結構分別將目錄”dirx”與目錄”a”輸出至其本身的目錄”/d1”與”d2”時所發生的事情。目錄”/d1”與”d2”為”用戶端安裝點”。在安裝操作之後，用戶端1可以看見可邏輯作為目錄”d1”的內容來存取之輸出目錄”dirx”下的全原始檔案系統階層。同樣的，在輸出目錄”a”下的階層出現在目錄”d2”之下。因此，路徑名稱”d1/dirz/fileb”係以完全透明的方式代表MaxiFS基礎結構中的”fileb”。對於檔案”/d2/b/d”來說也有相同的考量。
在第19圖中，用戶端2分別從MaxiScale基礎結構將輸出目錄”a”安裝至其本身的目錄”/W”，並且一起從NFS伺服器”Z”將輸出目錄”z0”安裝至其本身的目錄”/T”。在此例子中的安裝結果為用戶端2之檔案系統中的”/W/b/d”代表用戶端1之檔案系統”/d2/b/d”中的相同檔案，而/T/z2/z3代表NFS伺服器上的檔案”z3”。
特別注意下列事項：只要在總體名稱空間中不要重疊，用戶端可選擇性的僅安裝其想要存取的目錄。安裝由MaxiFS輸出之目錄的能力不排除對在MaxiFS之前所安裝的其他檔案伺服器進行存取，例如此範例中的NFS伺服器”Z”。所執行的與MaxiFS以及FS伺服器有關的安裝操作係透過用戶端所執行不同的軟體模組來實現。
從在用戶端之一者上所執行的應用程式的觀點來看，一旦執行適當的安裝操作，存取MaxiFS基礎結構(而不是NFS伺服器)上的檔案是絕對透明的。換句話說，不需要以特別的方式來撰寫應用程式，也不需要調用特別的API。接下來如同在NFS中一樣，繼續透過檔案系統存取遠端檔案。每當應用程式指定的路徑名稱超過與MaxiFS輸出目錄有關之用戶端安裝點的範圍時，會自動包含用來存取MaxiFS的適當MaxiFS軟體層，如同發生於NFS輸出目錄一樣。
然而在NFS伺服器的例子中，用戶端知道如何與伺服器互動來安裝其輸出目錄，在分散式基礎結構(像是MaxiFS)的例子中，比較不容易看到用戶端如何處理請求即將安裝的輸出目錄。為了簡化圖片，假設MaxiFS池中的所有伺服器具有100%的可用性。很清楚的這樣是不真實的，但是在接下來的討論中會將該限制移除。
以下說明選擇橫跨伺服器節點分配名稱空間的解決分法，使用第20圖中的名稱空間來說明所提出的機制。MaxiFS透過散列目錄路徑名稱橫跨伺服器節點來分配檔案系統階層。這可以透過用戶端對儲存對應檔案系統物件之特定伺服器的安裝點下的散列路徑名稱來完成。不論實現名稱空間的伺服器數量以及路徑名稱的深度，這樣的機制的優點為對伺服器名稱之路徑名稱的解析度可發生於常數時間。而缺點為對路徑名稱中之中間目錄的任何重新命名會產生不同的散列值，這意味著需要對所有子目錄(直接或非直接的)進行重新散列並且必須將其移動至與新散列碼有關的位置。因此，這將會是極度破壞性的操作，包含大量的網路流量。
考慮Amazon S3(Amazon S3目標的市場區段係與由MaxiFS提出之一者類似，即使其功能性在服務形式中為可用的，而不是作為產品)中的事實是相當有趣的，物件完全不可改變(即使是改變名稱)且其階層被限制為兩階層。這完全避免了關於散列機制的問題。GoogleFS也發生類似的事情，基於相同的理由其中的檔案係由不可改變的數字ID來辨識。在特定市場區段MaxiFS目標中不需要有效的處理重新命名操作。然而，即使這是一個案例，特定MaxiFS支援POSIX語意(semantic)，至少期望重新命名操作對全系統為非破壞性的。因此，散列機制應該具有下列特徵：
1.應該橫跨所有伺服器一致的分配檔案與目錄。
2.當對目錄重新命名時，由於重新散列路徑名稱會突然造成系統活動的主要叢發(burst)並且會完全中斷用戶端感知的系統效能，應該避免對被重新命名且即將移動至新位置的目錄之直接或非直接子目錄之所有檔案與目錄的需求。
3.當改變系統中的伺服器數量時必須避免重新散列與移動全檔案系統樹。
該第一點可透過適當的選取散列演算法來處理並應該簡單明瞭。當使用檔案或目錄的路徑名稱來產生散列時第二點難以固定。第三點亦難以解決散列機制的內容。在特定散列表中的每個散列桶(hash bucket)係映射至同級組，一旦計算出散列，用於每個檔案或目錄的伺服器節點會是固定的。若節點數量改變時(且散列表的尺寸因而改變)，檔案/目錄與節點之間的映射也會改變。如該第二點，必須移動所有的檔案與目錄來實現新的映射。接下來的兩個子區段係解決後面的兩個問題。
3.1散列與重新命名
這個段落係處理該第二點。要解決的問題包含尋找當路徑名稱改變時避免重新分配映射至伺服器節點之檔案與目錄的方法。必須考量的一些問題包含：
a)第一考量為避免重新設置大量檔案的需求，由於這會吸收大部分的頻寬以及與內部MasiFS簿記緊密相關之伺服器節點的計算資源，並且當執行有用的工作時客戶會察覺。因此，較佳為排除所有這類的工作。所需考量最具破壞性的案例為在上層目錄中的名稱改變。這將會影響其下方的所有檔案系統階層。這代表階層的下部盡量不要依賴其父目錄的路徑名稱。
b)期望所使用的任何機制，所列舉的目錄不應該為非常昂貴的操作。根據路徑名稱的純散列機制會使目錄列舉非常沒效率。
c)不期望因為檔案名稱的改變而必須移動檔案。即使對檔案與目錄重新命名不是非常常見的活動，必須確定相對較常執行的動作應該比較不常執行的動作具有較少的影響。因此，由於對檔案重新命名比對目錄重新命名常發生，因此此例子應該對重新命名目錄相關的動作最佳化。
若僅對檔案或目錄名稱進行散列處理來取代對全檔案名稱進行散列處理，所取得之散列值將會與剩下的路徑名稱無關。這使橫跨伺服器節點所分佈的檔案系統物件對由於對其父目錄或上代目錄重新命名所發生的事情不敏感，並且會排除該主要考量(該幾個項目)。
然而，這將會產生與項目b的問題。包含於單一目錄中的檔案將會散佈於整個分散式系統中。這會使目錄列舉變為非常沒效率的操作。
由於重新命名檔案可能會使檔案被移動至別處，因此這也會產生項目c的問題。較佳的替代方案是僅對目錄名稱(而不是全路徑名稱)執行散列處理。這代表被用戶端當作相同目錄之子目錄的所有檔案也可以儲存於該目錄存在之相同伺服器的單一目錄中。
關聯如下：由於每個目錄將包含其所有的子目錄，因此目錄列舉仍是有效率的。這解決了與項目b有關的問題。由於改變檔案名稱會發生於任何時間點，這僅相當於相同目錄中的名稱改變，這也會解決項目c中的任何問題。
此方法的結果為由於目錄總是根據其散列碼來設置，因此子目錄通常不與全名稱空間中其父目錄一起儲存：這通常設置於別處(即使當其儲存於相同的伺服器節點)。為了繼續滿足項目b，應該存在對於其父目錄中之該目錄的至少一佔位符號(placeholder)。具有其代表之目錄名稱的此佔位符號將會指出實際目錄設置的位置。
我們暫時忽略所使用的散列功能以及散列所產生映射至伺服器的方法。以下會有詳細的討論。接下來，我們更詳細的研究此機制。
進一步考慮散列碼映射至特定伺服器的目錄應該如何儲存於該伺服器中。這必定不方便，也不可能只儲存相同父目錄內所有的散列目錄。原因有兩個，這會產生大量的目錄，具有非常大量的子目錄並且將會影響存取任何子目錄的速度，且名稱衝突(name collision)的可能性會增加。
由於該原因，因此可以不同的方法來處理：被散列至特定伺服器的每個目錄將會儲存於子目錄中，其名稱係取決於父目錄之全路徑名稱的散列(實際上，散列可能會產生代表十六進位字串的數值。之後，可以將其分割為組成實際目錄階層的固定長度區段而達到目標目錄來代替作為目錄名稱。這種方法若實現於兩個或更多階層，可明顯的降低父目錄中的項目數量。)。這允許名稱空間的較佳分割。這意味著散列目錄不完全不受其所屬階層的控制，且因此重新命名路徑名稱中的中間目錄仍具有相同的影響。然而，在此實施例中，當對中間目錄進行重新命名時，由於其所屬伺服器僅由目錄名稱來決定，因此不需要將目錄從一伺服器移動至另一伺服器。
然而，所有被重新命名之該目錄的子目錄(直接或非直接的)必須根據新路徑名稱的散列碼結束於相同伺服器上的不同目錄。這需要遞迴地掃瞄被重新命名之該目錄的所有子目錄。當操作正在進行時，必須特別注意確定整體用戶端關點的目錄已被重新命名，且其所有的子目錄皆保持一致。
上面所提議的剩餘目錄很清楚的不像橫跨分散式系統重新設置全部目錄一樣的具有破壞性。然而，這可能造成一些負面的副作用。根據名稱空間的結構，必要的重新調整可能仍需要一些時間，由於其必須遞迴地掃瞄被重新命名目錄的全子樹，因此可以更新對目錄路徑的散列。這樣的調整對每個伺服器來說是局部的，換句話說，其僅包含對相同伺服器中的目錄重新命名，而不包含移動檔案。然而，該活動可能影響所有的伺服器並且必須依序地執行。當執行重新散列與重新命名時，包含被重新命名之目錄的檔案路徑之用戶端請求必須延遲直到完成調整為止。
在此機制中，目前為止已適當的指出一個問題：具有相同名稱與不同路徑名稱的兩個目錄會被散列出相同的值，因此被散列為相同伺服器。因此兩個目錄應該出現在伺服器的相同父目錄中。但由於目錄名稱是相同的因此無法這麼做。因此需要想出處理這樣名稱衝突的策略。
可能的名稱衝突處理策略可由新增具有碰撞名稱的單一目錄所構成，其係由不能作為目錄名稱中第一字元的字元來作為前置(prefix)，例如空白(這個”特別的”字元應該被適當的處理，藉由允許用於使用者使用特定字元對目錄命名的不可能例子中的逸出序列(escape sequence)設置於其第一位置)。在此，這個”衝突目錄”可包含可與不同名稱以及額外資訊一起儲存的碰撞目錄，並且允許識別這些目錄(例如，儲存元件數量與路徑名稱的字串長度)。然而，如下所述，此機制無法完全解決問題。實際的問題係取決於所選擇的名稱衝突策略必須處理下列限制：
1.如上所述，當用戶端嘗試存取檔案或目錄時，其提供給系統的唯一資訊為其想要動作之物件的路徑名稱。
2.為了根據來自用戶端之資訊使名稱空間中兩個檔案系統物件的意義清楚，唯一的可能性為使用檔案系統物件的絕對路徑名稱。
3.散列機制期望對越少的路徑名稱進行散列越好，由於這限制了目錄重新命名之後重新調整散列的範圍。
由於僅對目錄名稱進行散列處理，在散列應用至較大部分路徑名稱的例子中可能會潛在的增加名稱衝突。因此，每個目錄應該儲存於其絕對路徑名稱用來處理名稱衝突的位置。這使得對部分的路徑名稱進行散列處理不是非常有利，即使重新調整僅包含被重新命名之目錄的直接子目錄，但是必須更新與被重新命名之目錄的所有直接與非直接子目一起儲存的路徑名稱。因此，應該回到初始的散列策略及其缺點。
由於透過用戶端提供之資訊使檔案系統物件意義清楚唯一有效率的方法為透過絕對路徑，可以想像在目前所說明的各種機制中仍舊根據其名稱而將目錄散列至伺服器節點，且其中儲存目錄之伺服器節點內的實際路徑名稱為目錄的絕對路徑名稱。
該機制仍舊具有對目錄重新命名僅移動重新命名的目錄以及其中的檔案(由於被移動的檔案為遠小於一般檔案的元資料，因此不如聽到的如此具有破壞性)而不會影響其子目錄的特性。因此，對目錄重新命名對全系統來說並不是破壞性的操作。
由於在每個伺服器中，目錄之間可透過階層中的絕對路徑名稱而達到，因次不在具有名稱衝突。因此，對每個目錄的檔案路徑不需要具有個別的儲存庫來處理名稱衝突。
對目錄重新命名最多需要對每個伺服器上的單一目錄重新命名，為了反映新的階層，這可以在本地的每個伺服器中執行並且平行橫跨所有伺服器，因而最小化對需要延緩的目錄之下之操作的時間間隔。
然而，必須通知所有伺服器關於目錄的重新命名，且許多伺服器可能需要根據名稱空間中目錄的相對位置進行重新命名的操作。
名稱空間中有意義的部分係複製至所有伺服器中。儘管檔案僅儲存於目錄被散列的節點中，目錄仍具有副本。
當需要新增不存在於伺服器中的路徑名稱分支時，可能需要新增一些中間佔位符號目錄。
對伺服器節點內目錄的存取可能根據階層中目錄的位置不再是包含非常短本地階層的操作。
然而，此最後的機制滿足所有的需求。其最負面的方面為該前兩點。然而，由於對所有伺服器重新命名可能橫跨所有伺服器平行地執行可以使時間錯位(time disruption)維持最小。這必須透過單一實體來協調(最有可能的候選者為被散列之目錄所存在的節點)。
目錄重新命名的傳送不需要是即時的，也不是橫跨所有同級組的基元。實際上，若需要存取重新命名物件之目錄中的檔案，只有所有者的同級組需要處理這樣的請求。該同級組知道重新命名並且可一致的操作。不論目錄具有舊的或新的名稱，在重新命名目錄以及具有其他同級組下之子樹中的任何其他路徑名稱操作可安全地執行。若請求對未接收改變之同級組的操作，所有的事情表現為發佈重新命名之前所執行的最後請求，否則，所請求的操作可能如同在新請求之前接收重新命名一樣的發生。對其他同級組之改變的傳遞的處理如下：
1.請求原始重新命名之同級組係執行重新命名操作。
2.當完成重新命名時，具有該目錄的同級組係將重新命名的請求傳送至具有在被重新命名之原始目錄直接下方之目錄的所有同級組。
3.對所有下方的目錄遞迴執行這樣的操作。
這樣的操作具有一些正面的特性。由於操作速度係正比於每個目錄之平均子目錄數量的對數，因此改變與由被原始重新命名之目錄的平均散出所意味之平行一同傳播並且可能確保清楚的快速傳播。同樣的，這也可確保只有在目錄的父目錄知道改變時才會通知該目錄。
另一方面(名稱空間的部分複製)具有浪費地執行此操作之儲存空間中的主要關聯。然而，複製目錄代表使用每個目錄的一個i節點以及取決於目錄尺寸的可變量磁碟區塊。由於”佔位符號”目錄不需要儲存檔案，而僅儲存其他目錄名稱，因此所使用的儲存量可能為可用儲存器的一小部分。再者，每個節點共用其使用者資料檔案與名稱空間結構之間容量的儲存空間。前者可透過移動使用者資料檔案而降低。後者可透過增加作為部分系統的節點數量以及根據新的散列移動目錄而降低。為了澄清該機制，全面考慮一實施例是值得的。
第21圖顯示如何使用該最新的機制將第20圖中的階層分佈至三個伺服器節點(X、Y與Z)。為了瞭解該圖片，應該記住下列事項：標示為”散列至”的粗箭頭代表散列函式應用至該列表之目錄名稱的散列函式，並且將名稱映射至特定伺服器。粗的虛線橢圓包含每個伺服器所實現的階層。直得注意的是，此階層係與階層用戶端(參考第20圖)相似，儘管遺失了其中的一些項目。具有底線的名稱(也就是在節點X中的”docs”、”docs”與”java”具有底線，在節點Y中的”a”、”powerpoints”與”perl”具有底線，在節點Z中的”papers”與”source”具有底線)為儲存於其主機伺服器中的目錄。顯示為斜體宇的名稱(也就是，節點X中的”a”、”powerpoint”、”papers”與”source”為斜體字，節點Y中的”docs”與”source”為斜體宇，節點Z中的”a”、”docs”、”docs”、”perl”與”java”為斜體字)為目錄佔位符號(這些是每個伺服器中的實際目錄，但其角色為實際目錄的佔位符號，以允許將檔案系統的底線部分與其路徑名稱一起儲存)。其永遠不包含檔案，因為檔案係儲存於該目錄所散列至的目錄副本，因此可以作為實際目錄的參考。這些參考顯示為標示名稱以及指向目標目錄的虛線箭頭。
假設用戶端在安裝點”/mnt/shared”處安裝MaxiFS，並且請求開啟檔案”/mnt/shared/a/source/java/y.java”。要執行的步驟順序如下：
1.首先，對在執行該請求之用戶端處執行的MaxiFS發出執行開啟安裝點之外路徑名稱的請求，在此實施例中為”a/source/java/y.java”。
2.用戶端模組應該做的第一件事情為對路徑名稱中的葉節點之父目錄名稱進行散列處理。這將會是h(“java”)。根據圖片假設這會產生映射至伺服器節點X。
3.用戶端模組的下一步驟為與節點X對話，請求存取”a/source/java/y.java”。接下來，伺服器節點會執行本地檔案系統樹遍歷來取得”a/source/java”，並接著查找與開啟”y.java”。
此例子說明此處所顯示的機制如何透過避免多個網路躍程(hop)或查找而允許對檔案的快速存取。同樣的，看看用戶端請求對目錄重新命名的例子。假設用戶端請求將”a/docs/powerpoint”重新命名為”a/docs/presentations”，因此”powerpoint”散列至節點Y，”presentations”散列至節點Z。需要執行的步驟順序如下：
1.在執行請求之用戶端處執行的MaxiFS模組應發佈請求”rename(“a/docs/powerpoint”,”a/docs/presentations”)”。
2.接下來，用戶端應該將該來源目錄散列至其目標節點Y。
3.接下來，用戶端應請求節點Y執行重新命名(以及重新設置)至節點Z。
4.節點Y應該重新設置該目錄，並且將檔案劃底線至Z，並且應該對所有節點發佈平行請求來更新目錄名稱。
5.最後應回應用戶端請求。
第22圖顯示檔案系統的結果狀態(在節點X中，”docs”、”docs”與”java”被劃底線，且”a”、”presentations”、”papers”與”source”為斜體字；在節點Y中，”a”與”perl”被劃底線，且”docs”、”presentations”與”source”為斜體字，在節點Z中，”presentations”、”papers”與”source”被劃底線，且”a”、”docs”、”docs”、”perl”與”java”為斜體字)。原則上不再需要目錄佔位符號”docs”與”presentations”。然而，由於該目錄佔位符號已經存在並且不會造成傷害，並且可簡化之後可能對新增額外分支的需求。值得注意的是，之前在”powerpoints”下的檔案現在位於節點Z的”presentations”下。
必須強調的事實為，重新設置每個伺服器的目錄與被劃底線的檔案不需要很大的頻寬，因為這些檔案不是實際資料而是指向實際資料的小元資料檔案。
值得注意的是，在請求用戶端開啟特定目錄的例子中，如同在目錄列舉的例子中，用戶端應該散列該目錄名稱而非散列其父目錄名稱。例如當開啟”a/source/java”時，應該對”java”執行散列而不是對”source”執行散列操作。然而，對像是作為請求路徑名稱之樹葉的目錄”java”來說，這會是兩步驟處理程序。在此例子中，應該對父目錄進行散列處理，且用戶端應該存取適當的伺服器節點來開啟目錄。知道被開啟項目為目錄的伺服器應該知道所使用的伺服器應該是”目錄java”所在的伺服器，並應該回傳錯誤指示至會在之後使用適當節點重複先前步驟的用戶端。我們不期望發生額外的存取。與對每個路徑名稱元件需要來回交互作用的NFS存取相比，這種操作方法顯然更佳流暢且有效率。
3.2散列與動態縮放
這個段落討論該三個項目，並且對所使用的散列機制做更深入的討論。此機制是很簡單易懂的，對此機制的說明如下：給定M個伺服器節點，建立具有T個項目的散列表，M<=T。每個表項目儲存指向與項目有關的伺服器節點。選擇適當的功能對檔案名稱提供散列值的平均分佈。若這樣的功能為f()，則對字串s的散列值被計算為h(s)=f(s)mod T。所計算之值h(s)將會作為指向字串s所使用伺服器之散列表項目的索引。
這個方法的困難在於，在像是MaxiFS的系統中，伺服器的數量可以動態的成長。因此，若伺服器數量成長超過T，就必須新增一個新的更大的表，並且必須再次初始其項目來指向伺服器節點。然而，一般來說，這可能需要根據新的散列值來移動所有的目錄，對於MaxiFS來說這樣的考量是無法被接受的。
因此，在MaxiFS中係使用動態縮放散列機制來避開此限制。假設T為2的乘冪。同樣的，假設h為用於持定檔案或目錄名稱的散列值。一般來說，任何這樣的數字可以表示為：h=q．2n +r。因此：h mod 2n =(q．2n +r)mod 2n =r。
h mod 2n 之值與h mod 2n+1 之值之間具有一致的關聯。需要考慮兩種情況：第一種情況為q是偶數值，第二種情況為q是奇數值。對於偶數的q來說：
因此，對偶數的q來說。
對奇數的q來說：
因此，對奇數的q來說。
因此，
使用這些關係式，便可透過將散列表的尺寸加倍以及將散列表的第一半複製至新增散列表的第二半而動態地擴充散列表(假設散列表的尺寸為2的乘冪，則係透過加倍散列表尺寸而擴充)。
因此，假設第23圖的實施例具有三個伺服器且散列表具有四個項目(階段I)。值得注意的是，具有三個伺服器與四個擴充槽，最後一個擴充槽跟第一擴充槽一樣指向伺服器A。
若需要將伺服器數量增加為具有五個伺服器，原始散列表不再適用。因此，散列表的下一個可能尺寸為8。為了新增不會影響任何原始映射的情況，擴充表的第二半應與第一半具有相同的內容(第23圖的階段II)。值得注意的是，伺服器A現在出現於四個表擴充槽中，然而其他伺服器僅出現兩次。
以下步驟係將新的伺服器(D與E)包含於圖中。這可以藉由使用這些新的伺服器取代擴充槽4與7(第23圖的階段III)。然而，這無法在此處停止，否則將再也無法找到散列至擴充槽4與7的所有名稱。
因此，階段II是完全良性的，其中不具有任何不想要的副作用，階段III必須透過其他動作來完成以維持映射至相同的名稱空間。
要執行的額外動作包含將先前在伺服器A上映射至散列表之項目4的所有目錄移動至伺服器D。同樣的，伺服器A上名稱映射至項目7的所有目錄將會被移動至伺服器E。要遵循的演算法係用來處理伺服器A上的每個目錄，檢查其散列值，因而驗證其應該指向散列表的哪一個擴充槽。當擴充槽4與7為目標項目時，對應的目錄應移動至適當的伺服器。由於當移動所有目錄時這可能無法停止操作，因此舊的伺服器與新的伺服器皆儲存於被影響地擴充槽中。在此方法中，移動期間將會先對新的伺服器進行任何存取，而當未找到目標時才會接著對舊的伺服器進行存取。
由於基礎結構的每個用戶端皆需要一個這樣的表格，因此對散列表的更新將會傳遞至整個基礎結構。藉由允許散列表項目共同具有被改變之表擴充槽內舊的與新的伺服器，在結論出該項目不存在之前，用戶端應具有查找對兩個位置皆感興趣的項目之選擇。這會降低取代關於在允許新的請求之前等待更新整個基礎結構之表項目的時間。當需要這樣的更新時，基礎結構應知道此。然而，節點首先必須知道的是被取代的節點以及取代的節點。在這樣的方法中，當發生移動時，用戶端第一次嘗試存取舊的節點，或是在執行移動之後，告知用戶端以在被影響擴充槽中共同具有舊的節點與新的節點之新表格取代其表格。基於此理由，對所使用表格增加一世代數是有用的。用戶端會將表格的世代數儲存至其所有的請求，因此當存取包含於更新中的兩個伺服器之一者時，將會發現表格不是最新的並且將會告知用戶端使用新的表格。在移動完成時需要再次增加世代數。這將會取代在以新伺服器ID修改之擴充槽中的兩個共用主機項目。系統將會注意串聯這樣的改變，因此一次僅允許一種改變。這不表示改變僅可包含於單一擴充槽。然而，透過阻擋新的改變可將個別的改變串聯化直到完成先前的改變為止。在任何例子中，不需要更新用戶端表格直到其嘗試存取對應至被改變擴充槽之伺服器之一者。再者，一旦其不需要存取被改變的項目，由於在懶散的方法中足以更新最新版本(即使是跳過中間者)，因此所有的用戶端不需要接收所有的更新。為了藉由最小化交換資訊量來最佳化表格的共用，可能期望所有伺服器與所有用戶端共用相同的演算法，並且僅將最小必要資訊推向用戶端以於本地更新其表格。
若散列表中的散列桶數量遠大於系統中的伺服器數量，此資料結構使其本身可以漂亮的平衡橫跨伺服器的運算/網路負載與容量。如第23圖所示，相同表格內的好幾個散列桶可能參考相同的伺服器。若這樣散列桶的數量遠大於伺服器數量，每個伺服器將會出現於許多散列桶中，且僅特定伺服器所擁有相對小部分的目錄會被散列至特定散列桶。這允許系統監控對每個這樣散列桶的參考數量。每個伺服器的總計數值亦可以被計算為與每個伺服器相關之散列桶的計數值總和，因此被參考的伺服器通常可以非常輕易的被看出來。一旦完成，可以注意具有大量負載之伺服器的個別散列桶，並且可以決定將與特定散列桶相關的目錄透過使散列桶指向較少負載的伺服器而移動至較少負載的伺服器。這會達成該目的。
注意下列事項：使用可計算最常使用伺服器的”MapReduce”演算法[6]是有利的，如同其以分散式的方式執行計算。系統應該確定移動目錄具有一些磁滯現象(hysteresis)，因此MaxiFS不會浪費週期而繼續來回移動目錄。實際的目錄移動不會影響最常使用伺服器的計數值，否則所有的統計量將會不精確。
到目前為止，假設散列表所具有的項目數量為2的乘冪。將散列表的尺寸限制為2的乘冪被視為是局部最佳化(suboptimal)的。熟悉此技藝之人士皆知道，當散列表包含質數(prime)數量的一些散列桶且散列值為對該數值執行模數計算時，這會產生擴充槽間的最佳分佈。然而，必須知道不像一般的散列表。用來實現分散式名稱空間的散列表不包含對碰撞(colliding)項目之鏈接串列(linked list)的指標。其包含對伺服器的參考。如上所述，使用中的伺服器數量遠小於散列表尺寸會比較便利，因此在第23圖的例子中，一些伺服器會不止一次出現在散列表中。必要時藉由透過一些適當的演算法取代散列表中的項目，透過藉由誘發散列表尺寸之散列表的局部最佳化項目分佈將會平衡。
目前所說明的機制相當具有彈性。然而，在其呈現的形式中，不允許目錄映射至橫跨伺服器節點分佈的相同散列桶。同樣的，在特定節點之儲存空間用盡的例子中僅可藉由嘗試改變個別表格項目的內容來處理，因此其可映射至不同的伺服器。然而，由於已存在當移動目錄時處理從一伺服器至另一伺服器的傳輸機制，這是由允許用戶端存取被移動目錄的伺服器以及作為移動目標的伺服器所構成，同樣的機制也可用於儲存溢位。換句話說，若目前在伺服器A上的目錄X無法具有任何更多檔案，則可指定備份伺服器B，因此至少一目錄可以被移動至伺服器B，而不需要移動可能散列至特定散列表項目的所有目錄。在任何例子中，不允許目錄橫跨不同伺服器而分開。其係全部位於一伺服器或另一伺服器上。
在此方法中，若用戶端無法透過該目錄所散列至的散列桶存取應開在伺服器A上的目錄(這樣的散列桶現在應顯示主要伺服器A與備份伺服器B)，其總是可以查找在伺服器B中未找到的目錄。這只有當備用伺服器用於極端例子時才會有良好的操作，其中直到透過增加更多伺服器節點來擴充基礎結構才可取得小的另一部份。然而，更期望對效能的影響是適度的降級而不是完全的失效。
3.3伺服器與容量
MaxiFS中的伺服器節點具有四個可用實體驅動器。可以透過RAID-5將其聚合為單一邏輯容量。這具有一些正面的觀點。移除實體容量之間的邊界允許如同單一儲存庫一般的使用所取得之邏輯容量。邏輯容量具有內見冗餘性並且resilient to遺失一個磁碟驅動器。
另一方面，這也具有一些缺點：RAID-5組所需要的冗餘性係有效移除可用總儲存器的1/4。遺失兩個磁碟驅動器將使整個伺服器不可用，然而若個別管理容量，只有在遺失四個驅動器時會造成伺服器完全不可用。
值的注意的是，若CPU、電力供應或是任何其他單一故障停止運作，則透過RAID-5所取得對一伺服器的冗餘內部將不會避免對橫跨伺服器的冗餘需求，因此不論如何都無法存取儲存於冗餘邏輯驅動器上的資料。因此，MaxiFS使用個別驅動裝置(drive)會比使用單一RAID-5驅動裝置更便利。
3.4 MaxiFS中的冗餘性
上一個段落僅說明如何架構MaxiFS的名稱空間，並提供如何存取資料的邏輯觀點。
關於對MaxiFS之期望存取模式的一項重要的事實為在不改變本質的情況下來處理所有檔案(單一例外為無法藉由附加新的紀錄來修改作為log的檔案)。換句話說，可新增檔案來覆寫之。然而，當檔案存在時，無法對檔案進行部分更新，而是必須刪除檔案或完全取代檔案。這就是Web 2.0應用程式的運作方式，且該限制明顯簡化MaxiFS的複雜度。在上個段落中假設伺服器節點為100%可用的。這很明顯不是該例子。以下說明冗餘性因素對該圖片的影響。MaxiFS是藉由整合多個伺服器的本地檔案系統而建立的一種分散式檔案系統。原則上，一旦可以將名稱空間分配至多個節點(如上個段落說明的方法)，則檔案本身可以包含使用者資料。然而，MaxiFS所解決的問題為透過根據檔案特性以及存取頻率等等設定的冗餘等級建立可用性與縮放性。這使檔案可存在於單一位置，且MaxiFS必須確認即使少了多個節點仍不會使系統突然停止。更重要的是，由於個別MaxiFS節點為低成本，商品伺服器，並且不具有固有的(intrinsic)硬體冗餘性。
因此，MaxiFS必須依賴說明檔案冗餘副本保存位置的額外資料結構。在一般檔案系統中，必須支援檔案抽象化(abstraction)的資料結構為檔案系統元資料。在MaxiFS中，除了原有檔案系統的元資料(這是每個節點之本地檔案系統的責任)支援還必須儲存MaxiFS元資料。由於MaxiFS建立於本地檔案系統上，此元資料僅可保留於檔案中(事實上在這之前說明了更佳的方法，然而這不會改變目前討論的本質)。
這代表具有兩種選擇：元資料可與檔案本身一起儲存於與使用者資料相鄰的特定MaxiFS區域。元資料可儲存於指向儲存使用者資料之實際檔案的檔案中。因此，儲存於MaxiFS內之檔案的用戶端觀點與現實中不一樣，其中該檔案包含資料，當多個硬碟鏡像存在時，亦必須包含指向保留額外硬碟鏡像位置的”指標”。
這可藉由用於每個伺服器節點上的遠端檔案存取服務(Remote File Access Service)來實現。這目的是雙重的(two-fold)：其支援讀取或寫入使用者資料的能力。這也代表允許用戶端存取分散式基礎結構中檔案或目錄儲存的位置。在每個伺服器上使用本地檔案系統階層的服務是為了實現MaxiFS階層(如同在”MaxiFS名稱空間的結構”中的說明)。這代表用戶端可看見的任何目錄為存在作為至少一伺服器上本地檔案系統之階層中的目錄。任何的使用者可見檔案係顯示為具有相同名稱的元資料檔案，其包含MaxiFS與檔案資料一起使用的元資料(包含與元資料檔案有關之資料檔案的位置以及其他相關特性)。
因此，在MaxiFS中，個別用戶端所查覺的目錄包含具有用戶端所察覺名稱的檔案。這些檔案必定包含MaxiFS元資料(指向儲存使用者資料副本的指標)。為了達到適當的可用性等級必須複製檔案系統階層、MaxiFS元資料以及使用者資料。藉由確定存在固定與預定數量的副本來複製檔案系統階層與元資料。然而，假定使用者資料的冗餘等級是由系統的終端使用者來選取。
這允許以下的可能性：一些檔案無法被複製。因此可輕易的重建檔案，例如暫存檔案。一些檔案可具有固定程度的複製，例如執行等級3的硬碟鏡像。一些檔案可具有最低等級的複製以及動態複製機制，因此副本數量係根據需求而增加或減少。這對串流媒體檔案特別有用，藉由利用每個伺服器維持可增加一副本的額外處理電力與網路頻寬執行多次的複製可以使其更容易被更多使用者存取。
因此，有鑑於對該檔案系統階層與元資料檔案的副本數量是固定的，個別的檔案可具有一些副本，其可少於等於或大於用於MaxiFS元資料的複製係數。原則上，可允許元資料檔案包含使用者資料，後果將會是：在對檔案的複製係數小於對元資料之標準副本數量的例子中，一些元資料檔案將會只包含元資料而不包含使用者資料。當對元資料檔案與使用者檔案的複製係數相同時，所以的元資料檔案可包含使用者資料。且當對使用者資料的複製係數大於對元資料檔案的複製係數時，將會具有儲存使用者資料的額外檔案。這意味著除了保留檔案系統階層與MaxiFS元資料的部分本地檔案系統之外也需要存在可儲存元資料之複製係數之外之檔案副本的其他區域。
然而，若不允許元資料檔案包含使用者資料，則名稱空間的元資料部分完全與處理使用者資料的副本解耦合。後者為在MaxiFS中遵循的模型。這建議任何伺服器應具有彼此獨立之階層/元資料儲存庫以及資料儲存庫結構的本地檔案系統。以下會將其分別標記為MDR與DR。
3.4.1伺服器節點與同級組
MaxiFS用戶端傳送至MaxiFS伺服器的請求具有下列目的：
1.查找檔案與目錄名稱
2.目錄列舉
3.設定並擷取檔案與目錄的屬性以及防護
4.新增或刪除檔案、目錄與符號鏈接(symbolic link)
5.檔案的讀取與寫入
所有這樣的請求開始於透過路徑名稱來識別感興趣的檔案系統物件。因此，所有這樣的請求是源於一些路徑名稱請求。路徑名稱請求係映射至在一些伺服器節點之MDR上執行的操作。在前面段落中已討論名稱空間的結構，假設個別伺服器實現部分的名稱空間。可以說明所依據的整體架構與概念。然而，為了使MaxiFS具有高度可用性，其服務必須再伺服器當機或故障時維持可用性。因此，必須透過使用硬碟鏡像節點產生冗餘的功能性。對MDR來說這特別重要，因為其構成實現檔案系統階層的儲存庫。因此失去部分的MDR意味著再也無法存取或接受名稱空間的一些部分。
在MaxiFS中，複製相同MDR的伺服器為實現MDR的同級組成員。因此，MaxiFS的基礎建立區塊變為同級組而不是個別伺服器節點，且現在必須藉由以同級組取代伺服器節點的概念重新翻譯關於實現分散式名稱空間的所有考量。作為同級組成員的節點數量(同級組基數)為這種集合的主要屬性。其係於具有較少成員(其簡化對該集合的管理並且降低成員之間的交互作用)與具有較多成員(其增加元資料同級組支援的冗餘性)之間取得平衡。即使假設使用雙向冗餘對個別節點具有非常低的可靠度位數0.99，對同級組的結果可靠度將會是0.9999。對三向冗餘而言，可靠度增加至0.999999。這足以滿足大部分企業等級的需求。因此，必定期望以3來複製MDR(以及相關同級組資格)，且即使這不需要是個嚴密的需求，然而MaxiFS係使用3作為對分散式檔案系統名稱空間與相關元資料的同級組基數。
3.4.1.1同級組的性質
必須執行一項重要的決定來判斷同級組成員應該為個別伺服器或<伺服器，容量>對或是<伺服器，子樹>對，因此每個子樹為整體容量的子集合。無論該選擇為何，特定同級組的三個成員必須管理獨立的儲存資源，否則將會遺失必須完成的高冗餘性同級組。現在檢查該選擇方案。
若同級組成員為全部伺服器，則會明顯降低複雜度與簿記，且在成員上的所有資源屬於該伺服器所屬的同級組。同級組的數量將會較低並且具有被指定至同級組的多播位址(或是虛擬IP位址)數量。然而，在此例子中的同級組成員可同時屬於唯一的一個集合。其中一項很清楚的缺點為除非具有適當數量的伺服器，否則其難以使用一些伺服器。
如果選擇較良好顆粒性作為同級組成員(<伺服器，容量>，或<伺服器，目錄子樹>)，則與不同的容量或子樹相關的相同伺服器可同時屬於至少一同級組。這需要更多的簿記，但其優點為較少數量的伺服器可構成有用的冗餘組構，且若驅動裝置變為不可用，則可以更容易的管理關於同級組應該轉變為降低特性之形式的狀態。
為了說明該兩個例子如何實現額外伺服器的效能，假設每個伺服器具有四個驅動裝置並且總共具有三個可用伺服器。第一機制僅可建立單一同級組。在相同的狀態中，使用第二機制具有<伺服器，容量>對作為同級組成員，可以新增四個同級組，且名稱空間可分佈於四個同級組。因此，儘管第二機制具有一些額外的複雜度，然其允許建立更有彈性的架構且其名稱空間可較佳的分佈至所有伺服器。若系統是由較少伺服器組成則可採用第二模式，然而當節點數量超過臨界值時可使用第一模式。然而這將會導致進一步的複雜度，因此不是個便利的方法。
一般來說，用於MaxiFS之伺服器具有M個磁碟驅動裝置，且選擇在每個同級組中具有三個成員，使用定義為伺服器/容量對的集合成員，並且可以從N個伺服器中產生p個同級組：
關於每個同級組具有兩個成員的例子，具有三個成員的缺點為對所有要使用的伺服器/容量對來說，伺服器數量與每個伺服器的驅動裝置數量之乘機應該要可以被三整除。如果不是這樣，可能為同級組成員的一個或甚至兩個伺服器/容量的組合便無法實現此作用。
然而，由於其可永遠具有使用者資料即使不儲存元資料，因此這不表示這樣的”備件”是未使用的。另外，其可永遠維持在備份狀態，準備好在伺服器/容量對進入離線狀態時取代之。屬於該同級組的容量同級組成員的結構非常相似並且具有結構相同於所有同級組成員的MDR。
此概念可包含允許多個MDR共同存在於相同實體容量內。這概念是非常的有用，如果沒有這樣的概念，當基於容量一同級組僅包含一節點時，則每個節點最多可以作為四個同級組(磁碟驅動裝置的數量)的成員。即使每個節點已具有4個成員資格並且假設其他節點故障，允許多個”邏輯容量”共同存在於相同驅動裝置內(該系統避免相同同級組的成員應用於相同節點)仍可以將故障節點的角色重新指派給良好的節點。
3.4.1.2同級組中的成員復原與置換
特別當考慮MaxiFS執行於便宜的伺服器時，同級組成員損壞或變得無法達到的可能性並不低。因此其將不會提供任何類型的硬體冗餘性。這個概念為當伺服器節點損壞或是其一些重要的元件故障時，必須置換伺服器，但這必須不影響MaxiFS的操作。有許多原因會造成同級組成員停止正常運作，包含硬體故障、軟體錯誤以及網路中斷。MaxiFS必須可以處理確保資料冗餘中的還原僅可持續有限的時間，以避免無法存取資源。因此，適當處理這個問題的必要步驟如下：
偵測 。MaxiFS必須知道系統不再可用，如此一來便可採取適當的動作。此處的難題為可靠的偵測故障節點，因為過早置換節點會影響重建損失冗餘性所需的負載與網路流量的成本(當由於診斷未成熟與不精確而在一開始不需要重建時)。這代表對認為節點故障之後之時間期間的選擇必須使執行無用工作與時間視窗的可能性最小化來降低資料冗餘性。
選擇 。一旦系統不再是同級組的成員時，必須選擇新的節點來接替故障成員的角色。該節點不應該是已經過載的節點，並且可能與剩餘同級組成員的效能與性能非常相似。剩餘的同級組成員應該在被同級組管理者授權執行選取時盡快執行選取。
複製 。這個階段意味著將被選取的節點與同級組之存活成員的元資料同步。這個階段非常的複雜且關鍵。必須將由同級組所管理的總體MDR複製至候選成員。由於MDR被限制為僅包含MaxiFS元資料(不是使用者資料)，因此被複製的資訊量將不會是大量。換句話說，這是個元資料驅動活動，因此將會包含合理的I/O操作量。
置換 。一旦完成資料複製，同級組的新成員應該作為同級組的正式成員而開始操作。
一旦確定同級組的成員不可用時必須執行該程序。然而，在得到結論之前，可以試圖簡化修復策略，例如重新啟動在伺服器上執行的MaxiFS子系統。若未成功，則可以重新啟動伺服器。然而，盡快執行該程序是值得的，以避免降低顯著時間量的冗餘性。
3.4.1.3同級組識別碼
對每個加入基礎結構的伺服器節點指派一獨一無二且永久性的ID。同樣的，對每個新增的同級組會指派一個獨一無二的ID，這個ID在同級組成員改變時也不會改變(這個同級組ID可與同級組的多播位址相關(若使用多播)，或是可以為指定給主要同級組成員的虛擬IP位址並且隨著主要角色而轉移。獨一無二的同級組ID也可以作為多播(或虛擬)IP位址的最低有效部分)。節點ID與同級組ID的名稱空間是不相交的。同樣的，對每個同級組來說會指派其他同級組作為其管理者。以下將會說明其角色。用來選擇管理者同級組的演算法很簡單。若系統中具有N個同級組，同級組i的管理者為同級組i-1。同級組0的管理者為同級組N-1。這意味著單一同級組不容許MaxiFS系統運行：至少需要兩個同級組。當建立同級組時係將計數器初始為0。這個數自稱為同級組世代計數器 。相同同級組的成員總是必須具有相同的世代計數器並且將其嵌入於傳送至用戶端或其他伺服器節點任何訊息內。在這方法中，用戶端可以偵測同級組上的資訊是否是舊的並且可請求更新。同級組之三成員的其中一者會被認為是主要成員。其他成員則是次要成員。主要成員為可信賴的節點，代表其狀態與MDR總是全體同級組的參考點。同級組成員執行一種心跳(heartbeating)，因此不論其是否全部可達到總是眾所皆知。不像是傳統叢集中的純心跳，在該機制中為租賃的。除了叢集心跳通常在冗餘連結下執行之外，一些冗餘連結係作為此功能，因此這僅與許多傳統心跳實現有些微的不同。同級組的主要成員請求對次要成員的租賃。次要成員僅請求對主要成員的租賃，但並不是彼此租賃。在經過一半的租賃時間之後，任何成員必須更新其租賃。若未在租賃期間內執行更新，則未接收到租賃請求的成員會試圖直接詢問其同級。若重試幾次都不成功，則該成員推論其同級為故障或無法取得。
當後者發生時，同級組處於退化狀態並且必須藉由增加新成員來重新建立其原始基數。此特性的情況通常是，若由於節點的硬體故障或由於失去連接性可能造成相同的問題發生於所有該節點所屬的同級組中。
在連接性議題的例子中(若包含使節點退化的硬體故障，則將會是該原始同級組的僅一或兩個子集合)，同級組可能會分裂為兩個或甚至三個子集合(在第一例子中，一個子集合僅可包含一個成員)。任何子集合可接著嘗試增加新成員至該同級組。為了避免競賽，已偵測失去同級的成員請求其管理者同級組提供刪除該同級組之不可用成員並且增加其他成員的許可。管理者同級組將僅授權子集合之一者從該同級組中刪除其同級節點並且以其他節點取代之。最快到達管理者的子集合(實際上，較慢的節點可能故障或重新啟動)獲勝。授權獲勝的成員選擇新同級的動作也允許其取消該同級組的世代計數器。從那時開始，該同級組其他舊成員傳送至伺服器或用戶端的任何封包被標示為舊世代計數器並且這允許刪除舊的伺服器。新的主要成員知道其他次要成員的存在並且將其更新為新的狀態(包含其新的角色與新的世代編號)。在此該同級組享有正式會籍，但需要透過以與該同級組相關之MDR來更新新的同級組成員來重建該同級組的基數。當完成更新時，心跳會完全回復且該同級組不再退化。不再與該同級進行通訊的伺服器可能會故障或中斷連結。不論其是否可與管理者同級組進行通訊以及是否看見其作為新主要成員的請求被拒絕，或是不論其是否完全無法與其管理者進行通訊，應該考慮其本身加入需要新成員之其他同級組的自由與可用性。在任何例子中，不應該刪除其舊的MDR直到加入其他的同級組為止。如果被授權作為主要成員的成員曾經是次要成員，則先前的主要成員會變為不可用。其他可能性為其他次要成員消失。在原先的例子中，前主要節點的角色現在轉為次要成員。
3.4.1.4同級組成員的”顏色”屬性
與同級組中的主要與次要角色無關，每個同級組成員皆被指定一個顏色屬性 (color property)。假設為三種數值：紅色、綠色或藍色。顏色完全與同級組中的主要或次要角色無關。當一成員加入一同級組時即被指定顏色並且永遠不會改變，即使成員從主要角色轉移為次要角色，反之亦然。當一節點離開一同級組時顏色屬性會失去其值。同樣的，當新成員取代先前的同級組成員時會接收被取代成員的顏色屬性。
顏色屬性的目的為允許分配僅由一或兩個同級組成員待實現的任務，在這樣方法中的任務會透過散列來指定顏色。例如，當需要根據檔案名稱將檔案新增至單一副本中時，檔案可能僅被儲存於具有該檔案名稱被散列之顏色的同級組成員中。同樣的，在讀取時不需要具有同級組成員互相作用來證明那個成員應服務該檔案，因為這已經透過將名稱散列至適當的顏色而決定。同樣的，特別的節點管理任務可能永遠透過具有特定顏色的節點來實現。
3.4.1.5用戶端與同級組之間的交互作用
用戶端與同級組之間的交互作用可以兩種方法之任一種來實現：A)藉由依賴多播以及指定永久多播位址至每個同級組。B)藉由指定虛擬IP位址至同級組的主要節點。此IP位址應該隨著同級組主要成員的角色而轉移。第一選擇較有吸引力，因為其中簡化了通訊協定並且大量簡化具有固定IP位址之同級組的處理程序。對多播來說，同級組的新成員應該只加入與該同級組相關的多播群組且離開該群組的成員應自行脫離群組。然而，若採用第二選擇，必須依賴舊的主要成員確實停止主要成員角色之明確指示，以確保對該群組的虛擬IP限制給新的主要成員。
同樣的，多播藉由將封包的副本留在網路基礎結構中的適當節點而降低用戶端與伺服器之間的大量訊息流量。另一方面，多播可能對用戶端的網路造成影響或是可以察覺額外與不期望流量的潛在來源。MaxiFS的設計依賴基於多播的機制。除了以上描述的優點之外，多播的缺點(透過網路交換機對封包複製的依賴)並未限定複製僅可發生於MaxiFS基礎結構內而不可發生於用戶端與基礎結構之間。可選取多播位址的範圍，以避免與用戶端之網路基礎結構的不期望交互作用。每個同級組將會有效的與多播位址相關，且同級組的成員將會在加入或離開同級組時加入或離開與同級組相關的多播群組。提供同級組對多播位址的一對一映射，用戶端可有效的僅需要根據多播位址與基礎結構進行交互作用。因此，用戶端的請求將不會傳送至伺服器而是傳送至同級組。值得注意的是，同級組中的成員必須具有較接近的整合等級，並且必須知道彼此的辨識碼與IP位址，以適當的調整被要求實現的活動同級組。
對同級組的非破壞性操作(破壞性操作是用來辨識改變名稱空間或是檔案內容的任何操作)請求可分配至所有成員。這允許成員一起分擔負載。為了公平的將請求分配至所有的同級組成員，同級組的主要成員必須對同級組成員預先組構訊標(token)，使得每個成員知道應該處理哪些請求，或是應定義適當的演算法來取得相同的效果。這比同級組成員協商來決定每個請求應由那個成員來處理更佳有效率。當執行破壞性操作時必須確保同級組之成員狀態的演化發生於鎖步(lockstep)，因此根據與用戶端進行交互作用的節點之請求不可能得到不同的結果。應用程式通常使用檔案作為信號標(semaphore)。這依靠路徑名稱操作的原子性強調所有破壞性路徑名稱操作的需求總是在同級組的所有成員之間一致的操作。
允許在同級組的所有成員之間在鎖步中執行破壞性操作的一種可能選擇為明顯的管理冗餘性，藉由新增保證彼此硬碟鏡像的伺服器總是同步的服務階層。這需要硬碟鏡像的邏輯形式，其中必須且足以僅複製所需要的，以確保一起工作之伺服器群組成員之間的用戶端觀點是一致的。這個方法的缺點為此機制非常依賴MaxiFS架構，因此這是個必須從零開始實現的特定設計。這個機制是特別用於MaxiFS架構的事實也是個優點，因為其提供整體的邏輯關點而不是實際觀點。因此，這可以將帶傳送的資訊量最小化並且使伺服器的交互作用有效率。由於這是基於邏輯觀點，因此更加的考慮伺服器中的實體差異(由於隨著時間會逐漸取代伺服器，因此無疑的在任何系統中這樣的差異將會擴大)。
其他選擇為使用自動區塊複製機制，其中可以將對一節點的實際磁碟寫入自動向前遞送至其他節點使其維持同步。此機制操作於實體階層並且可用於對Linux與其他作業系統的標準封包(例如參考NBD(http：//nbd.sourceforge.net/)，DR：BD(http：//www.drbd.org/start.html)以及DoubleTake(http：//www.doubletake.com/))。
此處主要的優點包含此軟體是現成用的並且不需要特別的改寫。這個方法所包含伺服器的組構不相同，則其組構必須非常匹配。按磁區的複製可能必須複製與用戶端觀點無關的資料結構。這可能需要比其他例子更多的頻寬與處理。基於這種機制的封包需要傳統的叢集基礎結構，其中可以透過冗餘網路連結偵測叢集之其他成員的狀態，至少一冗餘網路連結被指定此功能。
事實上第二機制可能過猶不及，由於其可能需要比其確實需要更多的資訊，因此會導致浪費網路頻寬。因此，MaxiFS使用第一機制。如同一般的標準，期望使MaxiFS用戶端執行與該伺服器節點相關的越多工作越好，無論如何其具有直接的知識。這具有兩種正面的影響。假使伺服器節點可能必須採用一般行為，則允許最瞭解特定議題的個體練習做適當的決定。且其降低伺服器節點的負載量。
當用戶端請求同級組執行破壞性操作時，同級組的主要成員藉由接收對用戶端請求的任何操作之確認來調節與其同級一起執行的動作。假使同級組的一或兩個次要成員無法成功完成，這也管理重試與錯誤回復。最後，主要成員為該同級組中將確認封包回傳至用戶端的唯一成員。在其他的例子中，由於伺服器節點可能是最有知識的實體，因此其為應該執行必要動作的節點。關於同級組之再同步等等的所有動作皆屬於此種類。
具有適當的系統管理服務與主要成員一起執行(其子集合之)次要成員之檔案系統的再同步。由於在進行再同步時無法預期系統維持閒置，至少在已被再同步的部分階層中應該仍可以在被重新產生的同級組中執行破壞性操作。若主動同級記錄再同步發生於樹中的什麼位置，則相對更容易做到。
該演算法操作如下：將其MDR複製至其他加入成員(被動成員)的同級組成員(主動成員，其可以為管理重建之同級組的任何成員，且其不需要是主要成員)對即將複製的MDR樹執行遞回遍歷並且一次一個的複製其掃瞄的項目。當其處理檔案與目錄時會記錄其在樹中的那個位置。無論其在什麼時候接收用戶端對改變MDR之任何部分的請求，主動成員檢查是否已處理關於該樹之一部份的項目。若是，則將請求向前遞送至被更新的成員。若否，由於更新版本將會在掃瞄到該項目時進行複製，因此僅對該成員的MDR執行更新。主動成員不需要是主要成員。事實上，避免主要成員為主動成員比較容易避免主要成員過載。
3.4.2元資料檔案的MDR與結構
MDR總是與同級組有關，期望同級組的所有成員一直具有相同的MDR，這總是包含在所步中。若情況非如此，則必須立即修復這樣的不一致。
MDR僅存在於作為同級組之成員的這些伺服器/容量對中。然而，可以想像具有多個MDR同時存在於相同的容量中。這可能會非常有用，因為如果沒有MDR，若一節點僅根據容量與一同級組相關，則每個節點至多可以作為四個同級組(硬碟驅動裝置的數量)的成員。允許多個同級組共同存在於相同容量內(系統會避免相同同級組的成員實現於相同節點)，即使每個節點已具有四個會員身份，若其他節點故障，仍可重新指派其角色給健康節點之一者。MDR中的元資料檔案係用來說明與檔案相關的資料儲存於基礎結構中的什麼位置。這樣的檔案可以只包含元資料或是又包含使用者資料。然而，由於MaxiFS在橫跨全基礎結構的每個檔案中可具有變數量的硬碟鏡像，即使使用者資料係儲存於元資料檔案中，當其數量超過該同級組的基數時需要將硬碟鏡像分開。
因此具有兩種選擇：將使用者資料儲存在元資料檔案中直到超過同級組基數，以及總是將檔案與元資料分開儲存。第一選擇的優點是(特別是針對小檔案)一旦開啟元資料，用戶端可讀取使用者資料而不用開啟不同的資料檔案。另一方面，兩個方面承受：產品必須具有更高的複雜度來處理兩個個別的例子，以及將部分檔案系統階層複製至其他節點的處理步驟在時間與複雜度方面都更昂貴。對該所討論的理由來說，第二選擇似乎更具吸引力。因此，元資料檔案將僅為實際使用者資料儲存位置的描述符(descriptor)。
當新增一檔案時，其元資料檔案係由該同級組所擁有，該同級組也具有該父目錄。若檔案具有多個硬碟鏡像，則硬碟鏡像也可存在於其他同級組中。然而，後者同級組僅可儲存該檔案而不是其元資料。就某種意義來說，第一同級組為具有該檔案的同級組。
即將討論的第二方面為其是否應該可以橫跨多個節點條帶(stripe)檔案。此處的優點為允許最有效的使用空間。而缺點就是所造成的複雜度。由於後者至少在產品的首次發佈中，儘管此這種演變開放此架構，仍不支援橫跨節點的檔案條帶化。
元資料檔案包含兩種資訊。第一種資訊為該元資料檔案的世代編號。當新增檔案時編號從0開始，並且在每次改變元資料檔案內容時增加1，以允許驗證橫跨同級組成員之元資料檔案的一致性。第二種資訊為<同級組ID，檔案名稱>對的列表，用來辨識檔案副本的儲存位置。檔案名稱指出對儲存資料檔案副本處之每個同級組之DR中檔案的參考方法。
如上所述，顯示於元資料檔案中的第一同級組一直是具有該檔案的同級組。資料檔案的實際名稱不需要與元資料檔案的名稱相關。後者為名稱，基礎結構的用戶端可藉由名稱知道檔案。前者為用來存取特定同級組之適當成員中檔案的名稱。全基礎結構必須具有一致的命名機制以確保檔案名稱是唯一的，因此將檔案從一同級組移動至其他同級組不會負擔名稱名稱衝突的風險。
因此，名稱可由兩成分所組成：第一為表示為十六進位字串的唯一每檔案ID。此ID應可由與新增檔案初始位置之同級組相關的部分所構成，並且每當該同級組新增檔案時增加計數器值。名稱的同級組ID成分只是用來隔開唯一ID空間，以避免在不同同級組上同時產生相同的名稱。然而，一旦新增檔案，便可於必要時將其移動至其他同級組，而不需要改變其名稱的該部分。第二成份為世代編號，當初始新增檔案時該編號從0開始，並且在每次覆寫檔案時增加。對任何包含該檔案的處理皆需要將世代編號回傳至用戶端(以下會有詳細說明)。
每個這種檔案儲存位置處之目錄的全路徑名稱不需要直接顯示於元資料檔案中，因此其可以被選擇為DR的根目錄，接下來是透過將代表該檔案之唯一ID的十六進位字串分割為幾個區段所取得之子目錄名稱，以限制DR中的每個目錄中的資料檔案數量(例如，所給的ID為十六進位字串，若每個區段為8位元長，則對應至區段的每個目錄至多可包含256個子目錄)。例如，假設察看一特定檔案，其元資料檔案包含下列資訊：
代表資料儲存庫中檔案名稱為”12ab34cd56ed”的檔案儲存在四個可能同級組之三者(該列表不限制為四個同級組)。
同級組6、18與23具有該檔案的副本。對每個包含該檔案的同級組來說，同級組ID係與其儲存副本的世代編號一起顯示。列表中的第一同級組也是檔案的擁有者(值得注意的是，在接近飽和的同級組中騰出空間並且”擁有”一些檔案，可能需要將資料檔案移動至遠離其擁有者同級組。在這個例子中，表格中適當的標記將會標示該狀態)，也就是儲存該檔案元資料的同級組。其他同級組僅具有該資料檔案(非元資料)的額外副本。在此實施例中，給定檔案名稱(“12ab34cd56ef”)，由於其包含最新的世代編號(1233)，因此在同級組6與23中的副本是最新的，然而在同級組18上的副本落後一個世代並且需要更新。假設該同級組的DR具有路徑名稱”/DR”，且該中間目錄係藉由分割ID字串而選擇，因此每個目錄會包含獨特ID的一個位元組，該檔案的實際路徑名稱將會是：對同級組6與23來說為”/DR/12/ab/34/cd/56/ef/12ab34cd56ef-1233”，而對同級組18來說為”/DR/12/ab/34/cd/56/ef/12ab34cd56ef-1232”。
當需要新增檔案時，該檔案將新增的識別碼將會是請求該檔案的用戶端處理程序。這代表元資料檔案的所有權將會與用戶端處理程序執行每個請求所使用的識別碼有關(這允許用戶端依賴每個本地系統的防護子系統來驗證所請求的操作，而不是強迫重新實現MaxiFS階層中的防護機制)。處理開啟檔案請求的方法如下。每當請求同級組開啟檔案時，其開啟對應的元資料檔案。接下來，檢查<同級組ID，檔案名稱>對中世代碼編號的一致性。換句話說，其確認對所有硬碟鏡像的世代碼編號皆相同。若非如此，同級組係負責對該副本的再同步。在此例子中，同級組應該只回傳同步之硬碟鏡像列表之成員的子集合，並且開始離線操作來對舊的副本執行再同步。同級組將<同級組ID，檔案名稱>對列表回傳至用戶端。接下來，後者決定應該以及如何存取哪一個同級組。
使用一般檔案作為元資料檔案的假設必定是可以接受的。換句話說，可能具有一定優勢的其他可能性：可以將儲存於元資料檔案中的資訊編碼並儲存在符號鏈接中。符號鏈接係簡單的實現為檔案，其特殊類型係藉由檔案系統來識別。其包含路徑名稱，指向本地檔案系統階層中的節點。符號鏈接不具有硬鏈接(hard link)的相同限制。值得注意的是，不會限制其僅說明所屬檔案系統容量範圍內，並且可指向目錄(而不是僅指向檔案)。其亦具有特徵，不像是硬鏈接所使用的引用計數，當所指的目標物件被刪除時可變為虛引用(dangling reference)。
由於虛引用是正常的，因此可能考慮將元資料資訊編碼於其中。如同任何其他路徑名稱，儲存在符號鏈接中的路徑名稱可能由不包含斜線號與空字元(C語言之字串中止符)的元件所構成，不超過255位元組並且由斜線符所分開。對系統依賴之符號鏈接的長度亦有所限制。
不論任何資訊MaxiFS需要保留在元資料檔案中，儲存在符號鏈接中的路徑名稱可用來執行編碼操作。然而，長度限制可能是個問題，特別是對具有許多硬碟鏡像的檔案。在任何例子中，可藉由編程的最低限度來延伸長度限制。因此，假設符號鏈接係作為元資料檔案，同級組成員將會藉由透過”symlink()”系統呼叫新增檔案來設定內容，並且將會藉由”readlink()”系統呼叫來讀取內容。
將符號鏈接當作元資料資訊的儲存庫是具有吸引力的。符號鏈接使用所需要的小空間。若所儲存的字串長度是短的，則可以完全包含於顯示於磁碟上的i節點內。否則，其可擴展至與該符號鏈接有關的直接資料區塊。這代表對具有有限元資料量的檔案來說，可以限制作為一i節點尺寸的儲存量，其通常遠小於資料區塊的尺寸。由於符號鏈接為系統檔案，因此保證系統提供其內容的完整性大於對任何使用者資料檔案的完整性。且新增、寫入與讀取符號鏈接內容所需要的系統呼叫數量被限制為一次。”symlink()”呼叫新增與特定內容的連結。”readlink()”呼叫擷取該內容。在該兩種呼叫之前皆不需要”open()”呼叫或是其後不需要”close()”呼叫。
基於該的所有原因，MaxiFS元資料係儲存於符號鏈接中。下個段落會說明如管理DR中的檔案。
3.4.3使用者資料檔案的DR與結構
DR的概念在邏輯上與MDR以及同級組皆不相關。必定可以使DR與個別伺服器/容量對相關。然而，這會使與MDR有關的DR更不穩固。原因是MDR與同級組有關。這是與在任何時間點處為同級組之成員的實體節點無關的抽象概念。因此，當引用特定同級組中的MDR時，不論同級會員可能如何的發展，隨著時間的過去此引用總是精確的。另外，由於在新成員加入同級組之前所有同級組成員皆故障的可能性非常低，因此同級組的概念使得MDR具有更好的可用性。在DR依附至個別伺服器的例子中，這將不是個案。除此之外，MDR階層處的交互作用可能永遠透過同級組進行抽象管理，然而對DR來說，用戶端將必須與個別節點交談。然而，若引發一些次要的限制，DR可使用同級組的大部分優點。為了避免產生全新的抽象概念，可以將DR依附至同級組。也就是說，接下來每個同級組將管理一個MDR以及一個DR。原則上，當硬碟鏡像的基數被限制為同級組尺寸的倍數時這變得更容易(也就是，當檔案儲存於特定同級組中時，檔案的副本係儲存於該同級組的每個節點)。給定由3個成員構成的同級組，這將表示檔案可存在於3、6、9...3*N個副本中，其中N為該檔案所儲存之同級組的數量，並且可根據各種規則或政策來選取N，且對不同的檔案類型可具有不同的N。具有此限制可具有較佳的經濟概念並且簡化系統。此機制明顯的缺點為將至少係數3所使用的儲存量有系統的加倍，這樣的情況可能是不期望發生的，特別是當必須儲存不需要硬體鏡像的檔案或是經過兩次硬碟鏡像之檔案的MaxiFS基礎架構較合適時。
僅允許具有檔案的同級組儲存等於同級組基數的一些硬碟鏡像以及單一或兩個副本的一種方法(這是不需要實現的選擇性最佳化)。這破壞與同級組有關之全對稱DR的一個位元，然而若遺失同級組成員，則剩餘的成員將會取得新的成員並且將會確認該新成員中的MDR與DR皆為最新的。總是存在檔案的唯一副本儲存於停止運轉成員的例子。然而，若其存在於單一副本中，用戶必須判斷這些檔案確實是可拋棄的。對檔案應具有多少硬碟鏡像的判斷為根據檔案後置、檔案尺寸、目錄儲存位置等等的組構決定。大檔案係與其元資料副本去耦合並且可具有如所需要一樣少或一樣多的硬碟鏡像。在任何例子中，將會在DR中管理這些檔案。
當伺服器/容量故障時，MaxiFS之第一責任之一者為重新儲存在故障伺服器/容量中之檔案的冗餘性。掃瞄整個全域名稱空間階層將會是浪費時間的並且將產生額外的負載，且故障可能會引起可觀的負載。然而，由於同級組管理MDR與DR，在成員離開同級組並且選擇新的成員作為代替之後，當繼續MDR複製時，每當遇到在故障節點上具有硬碟鏡像的元資料檔案時，複製MDR的主動成員應觸發檔案複製。很清楚的，對僅存在於故障節點上的檔案來說是不可能的，但是若因為檔案被視為不重要而未被複製時會出現這種情況。每個資料檔案本身在檔案的開始處具有一標頭。該標頭包含下列內容：
儲存實際使用者資料處的偏移係於該標頭之後。用戶等級的讀取與寫入操作僅可於該偏移處開始執行。在用戶端指定的檔案偏移應在執行讀取、寫入或截斷之前由資料偏移進行遞增。
同級組的ID與用戶端用來引用檔案的路徑名稱(若MaxiFS必須支援硬鏈接這將會造成問題)。這允許系統找出哪個元資料檔案指向該資料檔案並且在必要時存取該檔案的其他副本。然而，值得注意的是，此路徑名稱被視為一種暗示，而不是絕對精確的參考。原因為若此參考是精確的，則對該檔案之路徑名稱中目錄的任何重新命名應該會造成對在該重新命名目錄下之所有資料檔案中的所有路徑名稱的更新。這是不期望發生的情況。換句話說，由於重新命名不常發生，因此可於第一次更新檔案本身時更新路徑名稱。
如先前所述，資料檔案是不可改變的(唯一的例外為作為日誌的資料檔案，以下會有詳細的說明)。因此，具有新世代編號的檔案會在被修改過後之新檔案關閉時自動取代舊的版本。當開啟檔案要執行寫入操作時，擁有該檔案的同級組可選取該檔案的世代編號。該同級組之次要成員將使用相同的編號且對任何其他的硬碟鏡像皆為如此。必須提出的一個疑問為應該如何處理寫入操作。由於該方法允許馬上產生平行與冗餘性並且可將智慧集中於最瞭解該檔案的成分中(用戶端)，因此用戶端直接寫入假設用來儲存檔案之硬碟鏡像副本的所有伺服器被認為是最好的方法。
另一方面，當檔案所需要的硬碟鏡像數量大於3時這將不是最佳的方法。在這個例子中，寫入將不僅影響同級組更會影響外部成員，且寫入操作的協調性可能會變得有問題。然而，若僅對擁有該檔案的同級組成員執行寫入操作(檔案為散列至該同級組的部分目錄)，該同級組具有允許寫入操作進行於鎖步中的內部機制。在MaxiFS中所選擇的妥協為，由於DR緊連著同級組，當要更新檔案時，用戶端會直接與該檔案之父目錄所儲存處的該同級組成員(包含高達三個成員)進行相互作用。若硬碟鏡像的數量超過三，當用戶端關閉檔案時同級組將會以非同步的方法新增(或更新)額外的副本。
值得注意的是，寫入操作與元資料操作非常相似。在這兩個例子中，用戶端僅傳送其請求至該同級組的主要成員。不論元資料操作通常具有最小資料負載這是適當的，然而資料寫入封包可能具有更大的負載。在元資料操作的例子中，同級組的所有成員需要接收該請求。在寫入操作的例子中，即使負載很大並且僅存在該檔案的一個副本(這表示只需要一個伺服器來執行寫入操作)，藉由最後的交換器複製該封包並因此應包含了該影響。此外，一般的例子為具有至少一副本的檔案，在這樣的例子中大於一個單一伺服器必須執行寫入操作。讀取操作的例子有一些不同。多播讀取請求具有最小負載。因此，即使封包的副本具有最小的影響。在任何例子中，藉由讀取請求達到同級組中的所有伺服器，同級組內部的機制可適當的將讀取存取分配至具有該檔案副本的伺服器(其他將忽視之)。想要執行操作的用戶端將對在至少兩同級組中具有硬碟鏡像的檔案藉由從多個檔案執行條帶讀取來執行操作，並將適當的分割多播讀取請求。
3.5小檔案的特殊處理
在MaxiFS目標這種應用程式環境中具有許多情況，其中強制提供對小檔案的極快速存取能力。這通常是對包含短文或小圖片之檔案的例子。在這樣的例子中負擔意味著存取這樣的檔案是過渡的。為了開啟一個這樣的檔案，即使減少了NFS查找路徑名稱之中間成分的時間，仍必須從目錄中查找檔案i節點來讀取該檔案的i節點，並最終讀取該檔案的資料區塊。這需要至少三個I/O操作。在許多系統中，大部分的存取具有這樣的特性並且隨機存取檔案，因此藉由使用前端快取記憶體(front end cache)無法取得任何好處。因此，期望具有特殊的設備將存取這種小檔案的I/O操作數量最小化。
當所有的延伸陣列皆為相同尺寸時，執行此的方法為將檔案維持於在伺服器節點上實現之檔案系統內的這種等級中(在實際應用中，可藉由允許檔案跨距於容量中的多個固定尺寸延伸區，多達預先設定的最大值)(參考第24圖)。藉由將陣列簡單的索引可對個別延伸區進行存取。位元映象可持續追蹤已組構的延伸區。
為了知道如何實現此，假設指定MaxiFS之名稱空間中的特定上層目錄具有此功能性。假設此目錄實際上未存在於任何本地檔案系統中但是由用戶端軟體來說明，在這樣的方法中所有對在目錄編碼索引之名稱的存取被當作透過其索引對短檔案進行特殊存取。例如，假設”sfr”是這樣的目錄。則開啟”/sfr/CD3A”將會實際上請求具有十六進位索引為0xCD3A之最佳化儲存庫上的小檔案進行存取。這將會實現於必須預先組構的指定容量中。指定容量的理由為可實現非常簡單的檔案系統來處理這樣的容量，或是可透過將這些容量作為原始設備來存取的專門服務來使用容量本身。
第24圖顯示被指定為此功能之容量的可能佈局，其中位元映象(也可設計不具有位元映象的替代結構)係儲存於容量以及其後延伸區陣列的初始部分。第24圖中的紅色是用來標示已組構延伸區(以及位元映象中的對應位元)。其他的延伸區是未使用的。
用戶端透過其索引直接存取小檔案將是不實際的。索引本身總是提供對延伸區的存取，不論其為以組構或是未使用的。無法區分儲存在相同位置中的連續小檔案。分辨那個伺服器管理儲存感興趣小檔案之特定小檔案儲存庫將會是困難的。
基於這些理由，每個這樣的檔案應在MaxiFS中具有全域唯一ID來取代索引。唯一小檔案ID(Unique Small File ID,USFID)的結構為四種成分的串接，例如USFID=<ps><s><b><g>。唯一ID每個成分係於尖括號(angle bracket)內。其意義如下：<ps>這個欄位為儲存小檔案之同級組的ID。值得注意的是，藉由將同級組ID嵌入USFID內，檔案係永久依附至該同級組，並且無法從一同級組自由地重新組構至其他同級組。<s>為插槽ID或是儲存該檔案之邏輯容量區塊的索引。藉由使此資訊為部分的USFID，檔案僅可存在於容量中的特定邏輯偏移處。<b>為該檔案所使用之邏輯區塊的編號。藉由將此資訊嵌入USFID中，則檔案無法改變長度。值得注意的是，該檔案的實際長度位元組係儲存於磁碟上實際使用者資料之前的檔案元資料區域中。<g>為該檔案的世代編號。這是用來確認在不同時間點處佔據相同插槽的兩個不同檔案不會彼此混淆。由於此功能具有夠大量的位元組，因此幾乎無法在特定時間框架內達成再利用。
因此，關於第24圖，假設<ps>為0*ABCD(“0000ABCD”,4位元組)，<s>為5(“00000000005”,6位元組)，<b>為16(“10”,1位元組)，且世代編號為0*B87F81692(“B87F81692”,5位元組)，則對該檔案之USFID的十六進位表示法將會是：0000ABCD 00000000 000510B8 7F181692。
應用程式可透過stat()家族的系統呼叫取得此資訊，分割為兩個成分：裝置編號以及i節點編號(在唯一ID中個別欄位的長度完全顯示。這可以減少、增加或分割為欄位來滿足用戶端OS目標以及個別欄位之期望最大值的限制在任何例子中，一旦選擇欄位的邊界就不可以改變)。
例如世代編號的資訊應該與其他資訊例如實際檔案長度(用於該檔案的儲存空間量可小於整體延伸區)、所有權資料、存取權限、新增時間等等共同儲存為檔案元資料。此元資料可儲存於延伸區的第一部份，接著是實際資料。
POSIX檔案介面不具有新增不具名檔案然候之後再對不具名檔案指定名稱的方法。然而，MaxiFS透過和下列類似的連續POSIX呼叫可以達到新增不具名檔案然候之後再對不具名檔案指定名稱：
在敘述1中所提供的名稱是很傳統的。這是由請求新增檔案處之用戶端上的MaxiFS安裝點(在此例子中為”/MaxiFS_mp”)以及與安裝點(“sfr/smallfile”)相關的路徑名稱所構成。後者辨識遍及MaxiFS的小檔案目錄(“sfr”)以及慣用名稱(“smallfile”)。使用目錄(特定目錄”sfr”為可存取所有小檔案的目錄。這個特定目錄中部具有子目錄也不可以在該特定目錄中新增任何子目錄)通知MaxiFS的用戶端成分我們正在處理小檔案以及接下來應該以特定方法處理什麼。慣用名稱告知MaxiFS的用戶端元件這是新增新的小檔案的請求，其USFID在該時間點是未知的。
在敘述2中，呼叫者將資料寫入新的小檔案。在敘述5中，用戶端引用MaxiFS的特定操作fcntl()操作(“MAXIFS_GETUSFID”)。執行此呼叫需要如下：
1.用戶端通知MaxiFS小檔案現在已完成複製。
2.用戶端請求系統產生給該檔案的USFID。檔案名稱會被回傳為儲存於資料結構中的字串，fcntl()將其視為參數(“sfn”)。基於此理由，呼叫者設定儲存該名稱的緩衝區並且在敘述4中設定緩衝區的長度。
3.用戶端通知MaxiFS在引用fcntl()之後將無法對該檔案執行寫入操作，且MaxiFS將會強制執行此。值得注意的是，這點很重要，因為USFID將會安裝檔案的長度及其容量偏移。因此，若允許於此點擴充檔案，則可能會改變檔案的長度及其儲存位置。
最後，在敘述6中用戶端關閉檔案。此後便可透過期名稱來存取該檔案。假設fcntl()引用回傳USFID”0000ABCD00000000000510B87F181692”，新的小檔案將會被開啟為”/MaxiFS_mp/sfr/0000ABCD00000000000510B87F181692”(為了使應用程式階層支援此功能性，必須發展普遍程式語言用於Web 2.0應用程式(Java、Perl、Python等等)的封包、函式庫等等)。
一般來說係開啟這樣的檔案來執行讀取操作。然而，開啟這樣的檔案來執行寫入操作是個重要的例子。若必須從備份中重新建立該檔案，備份應用程式應該透過期USFID來新增該檔案並且對其執行寫入操作。在執行遠端複製的例子中需要執行該相同的操作。然而，這只會在可取得USFID所指之小檔案容量與同級組中的位置時發生。若其在使用中，則嘗試新增這樣的檔案將會被拒絕。同樣的，需要儲存該檔案之邏輯區塊的數量係安裝於USFID內，因此當新增該檔案時MaxiFS必須確認可取得所需要的延伸區。
在任何例子中，在新增小檔案之後，MaxiFS透過單一I/O操作支援讀取存取。由於這樣的USFID可成為部分的URL，因此存取這樣的檔案(即使是隨機存取)也不會使伺服器執行大量的I/O操作。
包含於特定名稱空間目錄中的小檔案列舉僅需要辨識所組構的延伸區(在此例子中係從位元映象)並且重建其唯一ID。為了列舉全MaxiFS基礎結構中的所有這類檔案，應該在系統的每個同級組中的小檔案容量內執行一次這樣的列舉。
透過期USFID可以將小檔案刪除。
這樣的檔案將必須具有冗餘性。為了簡單，將會確認任何這樣的檔案具有三個副本：設置於該檔案所屬之同級組的每個成員中的每個小檔案容量。
此類型檔案系統的副本以及該討論的副本之間的橫距為先前的討論集中於邏輯副本，其中橫跨副本之檔案的實際佈局是完全不重要的。唯一要緊的事情是對於即將同步的副本。
在此例子中，不僅需要複製該檔案，也必須精確的將每個檔案儲存於小檔案容量之每個副本中的相同位置。若非如此，相同ID不可應用至相同檔案的不同副本。
將小檔案容量組構為作為同級組成員之每個節點上之每個驅動裝置的子分區。當設置伺服器時將會新增這些分區。具有分區的困難為分區會限制驅動裝置上可使用之儲存器的彈性。一旦組構了分區，對於相同驅動裝置上的剩餘儲存量來說不論其是否為未使用、空的、僅使用部分或是完全滿的是沒有差別的。因此，即使一區域是空的而另一區域是滿的也無法在執行中做改變。這取決於在單一操作中進行存取之保證的事實，該存取必須是對實體容量而不是邏輯容量進行存取，邏輯容量可能需要額外的I/O操作來查找該分區之特定邏輯區塊的實際位置(若在伺服器節點上執行的檔案系統為ZFS，則由於這種形式的分區所引起的部分限制是很容易規避的。在這個例子中，由於ZFS將允許這樣的分區是無縫的並且動態的增加至執行中的ZFS檔案系統，因此每當分區未使用並且需要額外空間時，可以總是組構這樣的分區並且將其包含於ZFS檔案系統中)。
3.6系統、節點與用戶端初始化
由於多個MaxiFS基礎結構可能會共同存在於相同的網路中，必須假設每個這樣的基礎結構將具有其本身的名稱與辨識器。當其安裝輸出MaxiFS目錄至本地檔案系統時這將會被用戶端所使用。基礎結構的名稱及其ID係儲存於作為基礎結構之成員的所有伺服器中。
3.6.1 MaxiFS基礎結構的初始設定
具有多個節點之MaxiFS基礎結構的初始設定為疊代處理程序(iterative process)。在系統管理者辨識應作為部分基礎結構的伺服器之後這個任務是由系統管理來處理。這包含新增初始同級組。即將新增的第一同級組應為同級組0。這是個特別的同級組，其初始設定的處理程序不是標準處理程序。這是因為標準自動處理程序需要管理者同級組，然而對於初始的同級組0來說不具有管理者同級組。此後的其他節點/容量組合可使用標準處理程序一起集合為同級組。
3.6.2新增節點至MaxiFS基礎結構
當伺服器節點初始加入基礎結構時具有下列可能性，每種皆必須以不同的方式來處理：
1.在故障之後，節點可以重新加入基礎結構。
2.在正常關閉基礎結構並接著重新開啟之後，節點可重新加入基礎結構。
3.節點可以是第一次加入基礎結構。
在狀況1中，當節點在故障之後重新加入基礎結構，在重新開機時期必須辨識其所屬之基礎結構。假設是這種情況(若否，則作為狀況3來處理)，則對每個容量來說，節點應該在故障之前先辨識其是否為同級組的成員。
若其為同級組的成員，則應該傳送訊息至同級組的主要成員，請求重新加入同級組作為次要成員。若主要成員拒絕請求，則節點應該刪除與其先前同級組有關的資訊以及與該同級組有關的MDR，並應該使系統管理知道該節點本身可作為DR伺服器(應該包含重新獲得對不再使用之舊DR資料之儲存空間的機制)與同級組成員。若其不是同級組成員，則應讓系統管理知道其存在並等待同級組的請求或是DR請求。
在狀況2中，當節點在正常關機之後重新啟動時，應儲存此資訊以及關機時間。因此，在重新啟動時，應具有所需要的所有資訊，包含該節點為哪一個同級組的成員。若節點為一同級組成員，應該嘗試並重建同級組或是應該嘗試重新加入同級組。在正常情況下，這是有可能的並且一切都應該相當順利。然而，若重新啟動整個基礎結構，則必須管理一些關鍵的議題。例如，重建一同級組需要被重建同級組之管理者同級組的許可，然後可能無法取得後者。因此，節點應該瞭解狀況並且應週期性的詢問其管理者直到取得許可或是直到重新裝配之該同級組的其他成員與該節點接觸並邀請其加入該同級組。如上所述，若節點不是同級組的成員，則應該讓系統管理知道其可作為DR伺服器與同級組成員。
在狀況3中具有兩個可能的子例子。然而，在這兩個例子中，操作者必須直接請求獨立節點成為基礎結構的一部份。這可透過GUI介面而完成，GUI介面將辨識網路中可取得並且不屬於MaxiFS基礎結構的伺服器節點(這代表”執行MaxiFS軟體的伺服器節點”)並且將這些節點顯示於獨立池中。操作者應選取至少一這類節點並請求其加入現存的MaxiFS基礎結構。
若該節點從未屬於MaxiFS基礎結構，應該讓系統管理瞭解其本身，在必要時更新在基礎結構碼儲存庫上所執行軟體的版本，並且使系統管理可取得其作為可能的DR伺服器與同級組成員。若該節點從未屬於即將加入的MaxiFS基礎結構，但是是其他基礎結構的成員，在進入先前的子例子之前，系統管理者應提供明確的確認來執行此。換句話說，將節點從MaxiFS基礎結構移動至其他基礎結構僅可藉由直接的操作者請求之許可。
3.6.3 MaxiFS用戶端的初始設定
MaxiFS基礎結構之初始化的其他部分為用戶端的初始化。為了取得此，應遵循下列步驟：
1.首先，應該設定並執行用戶端即將加入的MaxiFS基礎結構。
2.接下來，系統管理者應使用MaxiFS節點管理GUI並且指出想成為部分基礎結構的用戶端節點。接下來將會將軟體封包上載至這樣的用戶端。
3.接下來，封包的設定功能將在用戶端上執行，並將會給定待使用之MaxiFS基礎結構的ID。這將允許包含設定輸出MaxiFS目錄的安裝點。
4.此時用戶端應使用MaxiFS用戶端加載模組來安裝與載入。這可能包含重新啟動用戶端。
5.最後，用戶端應安裝感興趣之輸出目錄並且開始操作。
4.執行檔案操作的詳細說明
文件的這個章節提供基於用戶端請求執行檔案操作的更多詳細說明。
4.1非破壞性操作的詳細說明 4.1.1檔案查找、狀態、開啟、讀取以及寫入操作
檔案查找操作不是由應用程式直接使用。在一般應用程式中係對由成功的開啟呼叫回傳之檔案描述符執行操作或是執行基於路徑名稱的系統呼叫。傳統網路檔案系統設計係依賴將路徑名稱轉換為某種不透明處理的查找操作。大部分的這種檔案系統需要以一次一個成分的方式來轉換路徑名稱，也就是逐步的將全路徑名稱轉換為辨識路徑名稱之葉子(leaf)的處理。一般來說，每個這樣的轉換需要用戶端與伺服器之間的網路往返時間。
為了使MaxiFS有效率並且避免不期望的網路往返時間，因此藉由執行單一網路互動的方法來解析相對路徑名稱(“相對路徑名稱”是用來強調這不是需要被查找的絕對路徑名稱，但是僅需要對代表MaxiFS名稱空間內檔案系統物件的部分路徑名稱執行查找操作，也就是下列的MaxiFS安裝點)。這是對路徑名稱解析之散列方法的核心。
根據在”MaxiFS名稱空間的結構”中敘述的機制這是可以達到的，由於MaxiFS名稱空間是獨立的(self contained)且MaxiFS係以硬體或軟體的方式操作於同質的伺服器上，因此MaxiFS可以比其他類型的分散式檔案系統做更有力的假設。例如，可以假設每個伺服器輸出的容量不包含對其他檔案系統的安裝點，並且假設目錄邊界所使用的檔案系統類型不會改變。查找操作的結果為，若成功，則發出請求的用戶端對接著用來存取該檔案之感興趣檔案系統物件進行處理。用戶端亦接收對應資料檔案所在位置的同級組列表。
然而MaxiFS的內部行為與可能建議的應用模式不同。MaxiFS藉由先擷取檔案處置(file handle)並接著透過其他基元操作該處置或是直接請求伺服器即將執行之基於路徑名稱的操作來執行一些檔案系統操作。根據MaxiFS的觀點，需要開啟檔案的功能性與需要聚集關於檔案之檔案系統元資料的功能性類似(這透常介由系統呼叫的stat()家族來完成)。會如此是因為MaxiFS用戶端需要於開啟時擷取感興趣檔案的檔案系統元資料如同其對stat執行的一樣。因此，單一類型的請求係執行兩種活動。唯一的不同在於開啟需要用戶端可取得對檔案的參考，因此可已在該檔案上執行接下來之讀取或寫入呼叫的操作，而stat不行。
若為了開啟檔案而執行請求，則建立介於用戶端與同級組之間的有狀態通信期(stateful session)。此通信期具有與其有關的過期(time out)並且有效率的表現為租賃。具有檔案元資料所在目錄的同級組係開啟關於感興趣檔案之元資料檔案並回傳作為該通信期之特徵的處置。該處置是有效的直到用戶端藉由關閉該檔案放棄其為止。然而，具有在開啟檔案後用戶端故障的可能性。在這樣的例子中，在適當的過期之後，同級組發送PING命令至用戶端來檢查後者是否仍然繼續存在。若其不再存在，則關閉該處置。用戶端亦接收多至四個同級組的清單，其中包含與元資料檔案有關的資料檔案副本。接下來，允許用戶端在任何具有可用檔案副本之同級組上使用該處置。該處置足以使伺服器存取可用的資料檔案。用戶端亦可決定分散來自多個同級組的讀取操作，以於必要時增加可用頻寬。若同級組中正在讀取資料檔案的伺服器超載或故障時，其亦可利用資料檔案冗餘性繼續讀取不同的同級組。在唯獨模式中開啟檔案清楚的辨識非破壞性操作。若用戶端離開或故障，同級組可取回檔案處置。當檔案開啟於唯寫或讀寫模式時，MaxiFS會採用一些限制。對該檔案的查找處理程序與對在唯獨模式中開啟的檔案執行查找處理是相同的。然而，若沒有其他用戶端存取寫入模式中的相同檔案時，允許用戶端存取唯寫檔案。這有效率的強迫一種型式的鎖定，因此對檔案的改變僅可透過串聯化的開啟-(讀取)-寫入-關閉通信期來執行。被修改的檔案是只有寫入者可以看到的有效私人副本。這允許目前的檔案副本滿足其他讀取請求。只有在通信期中止時，被修改的檔案才會取代原始檔案。然而，具有較舊檔案開啟之用戶端將持續存取相同的檔案直到其關閉檔案。這與一般檔案系統的語意不同。然而，這在在多個處理程序寫入相同檔案的可能性是微乎其微的市場區段MaxiFS目標中是完全可接受的。MaxiFS亦支援特別在處理記錄檔案中非常有用的其他操作模式，其中可具有多個讀取者與多個寫入者，且資料僅依附至檔案末端。由於檔案必須與讀取者以及附加模式的寫入者共用，因此此行為不同於前述的例子。
為了利用這樣的行為，因此總是允許在讀取模式中開啟的檔案。然而，若處理程序在附加模式中開啟檔案(使用POSIX開啟旗標O_APPEND)，則不允許其他處理程序在寫入模式中開啟該檔案，除非其亦設定附加模式旗標。相反的，若檔案已在寫入模式中開啟，則其無法在附加模式中開啟。
在任何例子中，在附加模式中開啟檔案的用戶端(在上下文中，用戶端不是請求開啟檔案的實體機器，而是請求開啟檔案之任何機器的實際處理程序)必須保證每個高達系統定義長度(期望附加模式的最大長度寫入為1 Mbyte)的個別寫入將自動依附至該檔案。這表示部分的寫入操作不會與來自其他用戶端的寫入操作交錯，並且將會連續的執行附加模式之寫入操作，即使未預先定義序列化的順序。在任何例子中，當在附加模式中開啟檔案且其具有硬碟鏡像時，保證所有的硬碟鏡像皆是相同的，也就是檔案中所附加個別記錄的順序總是相同的。檔案本身並不可使用於附加模式或寫入模式。任何檔案皆可以在寫入模式或附加模式中開啟。然而，若在附加模式中開啟檔案，則不可以被其他用戶端在寫入模式中開啟，而若其開啟於寫入模式，則其他用戶端無法在附加模式中開啟該檔案。不像是在寫入模式中開啟的檔案，每個附加模式的寫入者皆將其記錄依附至相同的實體檔案。
4.1.2檔案關閉操作
對於在唯讀或附加模式中所開啟檔案之關閉操作具有最小的語意。基本上，關閉具有檔案所在目錄之同級組，且後者使有關的處置無效。然而，在檔案開啟於寫入或讀寫模式的例子中，關閉操作也具有增加檔案的世代碼以及以新世代取代舊世代的影響。在任何例子中，由於傳送至擁有者同級組之關閉操作將會處理元資料檔案，因此關閉檔案的用戶端不需要執行關閉資料檔案的操作。服務該資料檔案的伺服器將會自動關閉該資料檔案。
4.1.3寫回模式(write-back)、寫透模式(write-through)以及Fsync
用於開啟呼叫(O_SYNC)的標準POSIX旗標允許用戶端選擇在寫透模式中執行寫入操作來取代在預設寫回模式中執行寫入操作。寫透模式允許應用程式較佳的控制磁碟中的檔案，其中用戶端僅在資料寫出提交(commit)至磁碟之後接收控制回(control back)。這樣的缺點為用戶端察覺遠大於寫回模式中的寫入延遲(write latency)。然而，更期望需要實現檢查點(checkpointing)以及相同機制的特定應用程式。POSIX也支援檔案系統基元呼叫fsync()。這對通常操作於寫回模式中的檔案很有用。每當呼叫後者的基元時，將感興趣之開啟檔案的檔案描述符作為參數來傳遞，呼叫者會被封鎖直到系統回應系統中所有的緩衝檔案寫入已經被提交至磁碟中。當開啟檔案執行寫入操作時(在一般寫入模式或附加模式中)，除了寫回模式之外，MaxiFS亦實現寫透模式以及fsync()。
4.1.4檔案鎖定
當檔案開啟執行寫入操作時，MaxiFS支援全檔案暗鎖(implicit locking)。對於執行寫入操作的有效率檔案開啟係以O_EXCL POSIX旗標暗中開啟。由於只有被多個用戶端共用的檔案才會在唯讀模式與附加模式中開啟，因此在MaxiFS中不支援明確檔案(explicit file)或是位元組範圍鎖定基元，因為其沒有用處。由於用戶端的個別寫入是依序附加的，因此在附加模式中開啟的檔案提供暗鎖。
4.1.5屬性設定
關於檔案屬性、檔案擁有者、存取位元等等的明確設定不具有特定習性。
4.1.6檔案擴充與截斷(truncation)
檔案擴充與截斷為必須實現適當語意的基礎操作。永遠滿足垃圾資料永遠不會回到使用者的需求是很重要的。這代表當擴充檔案時，首先應組構用於該檔案的額外區塊(通常使用被歸零的區塊)，接下來應該更新該檔案的長度。反之亦然，對截斷來說：首先應縮短檔案的長度，並且接下來應該釋放資料檔案的區塊。由於這些操作警告檔案其暗中操作於檔案的私人副本。在這樣修改的最後，在關閉檔案時，已更新檔案取代原始版本並增加世代編號。
4.1.7檔案重新命名
檔案重新命名原則上是不重要的。不像是目錄重新命名(如下所述)，其不需要對名稱進行重新散列或是檔案重置，並且對具有該父目錄之同級族的檔案系統來說是完全的本地操作。對於所有與路徑名稱相關的操作，唯一複雜的部分在於該同級組的主要成員必須協調跨同級組的更新來避免成員間的不一致。
4.1.8目錄的新增與刪除
新增與刪除目錄具有相當簡單的語意。然而，特別是當根據散列機制分配名稱空間時會涉及某些警告，因為在此例子中這些操作總是跨距兩同級組。
藉由同級組的主要成員橫跨所有成員來協調這樣的操作，因為任何的不一致(即使是暫時的)將可能造成不正確的應用程式行為。
新增目錄的處理程序會影響父目錄(以及其所屬之同級組)以及將儲存該目錄位置的MDR。具有將要新增之該目錄之同級組的主要成員係負責協調具有新目錄之父目錄的同級組。若請求失敗，則系統應藉由回傳錯誤訊息至用戶端來執行適當的語意。若系統偵測到任何的不一致，則應該嘗試並立即修復。
若所有的檢查順利進行，則操作將發生於兩個步驟：首先將必須在父目錄中新增新目錄的參考，接下來應於目標MDR內新增該目錄。由於在新增階段中係以相同順序執行檢查，因此儘管操作跨距兩個同級組，請求之間將不會發生衝突。
若刪除目錄，則檢查的順序應與新增目錄的順序相反，並且必須在刪除父目錄中的參考之前移除目標目錄。
4.1.9硬鏈接的新增與刪除
在MaxiFS中不支援硬鏈接，但在必要時或是期望特定應用時可以增加硬鏈接。
4.1.10符號鏈接的新增與刪除
不像是硬鏈接，MaxiFS可根據產品需求的演化支援符號鏈接。在任例子中，支援符號鏈接的用戶端平台總是可新增符號鏈接至儲存在MaxiFS中的檔案或目錄。
4.1.11目錄的重新命名
目錄的重新命名原則上是複雜的，因為在一般例子中其包含四種物件：舊的與新的父目錄以及舊的與新的名稱。這裡有三種類型的目錄重新命名。
若目錄重新命名不改變目錄的名稱，但僅將目錄移動至檔案系統名稱空間的其他區域，則目錄必須僅於相同本地檔案系統內移動。這不需要其他同級組並且可以藉由引用該檔案系統下的重新命名基數在同級組內部進行處理。然而，由於部分的名稱空間係改變外型，這些改變必須反應於包含該部分名稱空間的所有同級組(如該)。基於該原因，這可與重新命名平行完成。
若重新命名改變目錄名稱，其新的散列值仍將新的名稱映射至相同的同級組，則操作為檔案系統與同級組的內部操作。這可以簡單的藉由使用檔案系統下的重新命名而實現。在任何例子中，若目錄的新增或刪除改變需要改變父目錄的參考，則可使用該與目錄新增與刪除的相同方法來處理。
若重新命名造成目錄散列至不同的同級組，則操作會更加複雜，由於其需要橫跨兩個同級組的協調。在這樣的例子中，需要選擇用於重新命名的協調器(coordinator)，且其將是具有舊目錄名稱的同級組。當進行重新命名時，目錄中的所有檔案需要與其父目錄共同實體移動至新同級組。然而，協調器必須擷取與被移動目錄相關的所有操作，以確保一致的管理目錄項目(例如，當在被移動的目錄中接收刪除檔案的請求時，檔案本身已經被重置至新的同級組。若僅在舊目錄中查找檔案，則刪除操作將會失敗。相反的，用戶端可新增已經存在但是已被移動至新同級組的目錄項目。很清楚的，所有這樣的檢查必須自動管理，並因此需要單一參考點(也就是重新命名協調器))。在任何例子中，必須知道即使對大目錄進行重新命名，在這樣的狀況中不會花費過多的時間，因為實際上這不是資料檔案，但僅需要移動較小的元資料檔案，而這樣操作的花費比較不昂貴。當完成重新命名時，至於該的第一例子，協調器也必須通知包含名稱空間子樹的所有同級組，在子樹中對目錄的重新命名包含改變，使得同級組可以將改變列入考量並且改正子樹的外型。如同在目錄重新命名的第一例子中，這不需要在重新命名回傳成功訊息之前完成(如上所述)。
關於傳統的重新命名，大部分的複雜度來自於需要更新知道該目錄的同級組。然而，在目標市場MaxiFS中不期望目錄重新命名是個經常執行的操作。因此這是個可接受的花費。
5.故障回復的議題
這個段落簡單的探索用來管理節點與系統故障的一些一般標準MaxiFS。一般包含的標準如下：
1.系統必須盡可能的自我修復。
2.每個節點與每個同級組必須盡可能的獨立。
3.決策不可集中於單一實體。
4.除了災難復原(disaster recovery)的例子之外永遠不需要對全名稱空間進行完整的不一致檢查/修復。
5.若同級組中產生不一致，則主要成員為權威實體(authoritative entity)。
5.1重新審視同級組成員的再同步
每當同級組成員進入離線狀態，其MDR、DR與小檔案儲存庫的狀態不在忠實反應其他同級組成員的狀態。然而，這樣的斷電特徵係屬於不同的等級：
1.間歇性斷電：這種斷電持續不超過S秒，並且在時間窗W內重複超過N次。
2.瞬間斷電：這種斷電偶爾發生並且持續不超過S秒。
3.永久性斷電：這種斷電會使節點故障超過S秒。
基於該分類，MaxiFS實現下列策略。若同級組成員經歷被分類為間歇性的斷電，則該同級組的其他成員將故障成員從其他同級組排除並使其他成員加入該同級組。在這樣的例子中，這些斷電的責任可能為網路連線或節點硬體本身的斷電。若同級組經歷瞬間斷電，則其他成員記錄斷電期間所執行的操作，並且在還原其功能時對該成員播放執行操作的記錄。若同級組成員經歷永久性斷電，則將該成員從同級組中移除並替換。
這代表當同級組成員之一者發生斷電時，同級組的操作成員必須記錄其操作。所記錄的操作應持續不超過S秒，因為該限制將持續超過S秒的斷電視為永久性斷電。
若即將被取代的同級組成員為主要成員時，則必須推選新的主要成員。在選擇新成員之後，其接收離開同級組之成員的顏色屬性。那時，從剩下的的第二成員中將同級組的MDR複製至新的成員。當完成MDR複製時(由於僅需新增目錄並複製小的元資料檔案，因此花費相對短暫的時間)，則複製了DR中的檔案。同時可藉由容量對容量複製來複製小檔案儲存庫。為了最佳化，可於用戶端請求破壞性操作時執行MDR的複製，新的成員接收該請求並當操作物件在已被複製的部分MDR中時執行所請求的操作。否則，請求會被忽略並且當更新物件所在的MDR區域時發生改變。
5.2在完成系統故障或重新啟動之後的再初始化
永遠不應該發生毀滅性的系統故障。然而，MaxiFS必須準備好對付這樣不太可能的事件。可以相同於完成系統重新啟動的方法來處理之。MaxiFS實現可對該系統之最後有效狀態重建全系統組構(包含同級組成員)的聯盟協定(federal protocol)。重建同級組0以及接下來重組所有同級組係逐步的發生。若同級組的一個成員不再可用，則剩下的成員將會選出新的成員。
5.3 MaxiFS的完整性與檢驗
由於可能發生一些不期望的事件，因此一同級組成員的MDR可能變的不準確。同樣的DR也可能變的不準確。MaxiFS的實施為當執行時偵測到不一致時，會採取下列選擇之一者。若被偵測到不一致的實體具有足夠的冗餘資訊來回復有限時間內所遺失的資料，則其會馬上執行回復操作。但若在偵測到不一致時可用的資訊不足以回復其完整性，或是若這就時間而言被認為是昂貴的操作，則被偵測出有問題的實體將該檔案系統物件標記為部分不一致，並且排隊等待請求透過下述的佇列機制(queuing mechanism)來修復該物件。這將會觸發系統常駐程式(daemon)的介入來回復一致性。
5.4功率耗損以及磁碟區段損毀
如同交換器的例子，任何MaxiFS節點上的根檔案系統在本質上是不可改變的，其中被修改的區域在本質上是暫時的。系統亦強迫對檔案系統容量的週期性快照(snapshot)。若容量因為儲存檔案系統資料結構之區域的損毀磁區而損毀，則以最後有效快照的影像重新建立該容量。使用ZFS將使該議題成為有爭議的問題。
參考
[1]McKusick,M.,K.,Ganger,G.在Usenix 99程序http：//www.usenix.org/publications/library/proceedings/useni x99/mckusick.html中發表的”軟體修正：排除在快速檔案系統中大部分同步寫入的方法”。
[3]Knuth,D.在”先進計算機編程卷1：基礎演算法”的第二版第435-455頁。國際標準書號(ISBN)0-201-89683-4。
[6]Dean,J.,Ghemawat,S.於2004年在Google(http：//209.85.163.132/papers/mapreduce-osdi04.pdf)中發表的”映射化簡：在大叢集上的簡化資料處理”。
III MAXIFS的佇列服務 1.前言
這個章節說明範例用於MaxiFS的穩健佇列伺服器，此後稱為MaxiQ。MaxiQ係承受個別伺服器故障並允許將消費者從生產者中去耦合。在MaxiFS中對於佇列設備的需求來自於例如這些非同步複製檔案的服務且管理基礎結構必須與請求這樣服務的元件非同步運作。佇列服務也必須是穩健的，即使跨系統的故障也不會遺失已進入佇列的紀錄，並且必須可根據基礎結構本身來縮放。此處說明的佇列設備為真正的佇列設備，也就是不會與資料儲存庫或是資料庫管理系統混淆。其目標為允許生產者佇列記錄使得消費者可在之後將記錄從佇列中取出(dequeue)來對其進行操作。消費者與生產者的術語係不嚴格的使用於本文件中。生產者或消費者可以為在MaxiFS環境中任何伺服器節點內執行的任何執行序(thread)或是處理程序，其存取佇列設備來將記錄加入佇列或從佇列中取出。接下來的章節著重於對此設備的需求，所提議可能實施的高階語意以及簡短描述。
2.需求
對MaxiQ的需求如下：
1.不管佇列記錄實際儲存的位置，佇列為可由MaxiFS之任何伺服器節點部分存取的全域資料結構。
2.即使在伺服器故障的情況下，將被插入佇列設備的紀錄應該被永久的儲存，直到記錄被直接擷取或移除，或直到其壽命(life span)過期。
3.依附至該佇列的每個記錄係被依附至佇列末端。
4.不允許以FIFO順序從佇列中擷取記錄。
5.記錄係與辨識其特性的規格有關。基於消費者提供的規格從佇列中擷取記錄。
6.依附至該佇列的每個記錄應保留其身份，也就是其應該可以獨立的處理個別的記錄，而不需要跨越記錄之間的邊界。
7.將記錄依附至佇列或從佇列中移除的動作應是原子的，也就是增加部分記錄、移除部分記錄以及/或交錯部分的個別記錄是不可能的。
8.在具有多個生產者與多個消費者的情況下，應保證將個別記錄增加至或從佇列移除的原子性，而不需要任何生產者或消費者明顯的鎖定。
9.若記錄已被執行，則消費者應從佇列中刪除該記錄。節點故障不應該允許遺失插入佇列的資料。
10.佇列的實現應具有高度的縮放性。
3.操作理論
在提議操作於佇列的可能基元之前，至少必須提出該設備應如何操作的高階圖片。這是這個章節的目的。MaxiQ設備應允許任何系統元件使記錄離開佇列，因此每當可取得記錄的消費者時，其可將記錄從佇列中移除並處理之。期望接下來在這樣佇列設備上的一般操作應如下：
1.將記錄從佇列中取出。
2.再不將記錄從佇列中移除的情況下讀取記錄，也就是從佇列中複製記錄。
3.從佇列中擷取記錄並刪除之。
必須處理的難題為，若消費者執行序從佇列中取出記錄，而接下來執行執行序的伺服器發生故障或停擺，則將會有效的遺失記錄。因此，應以這樣的方法建立設備及其基元，使得節點的故障不會造成佇列中任何記錄的遺失。除此之外，為了達到將佇列設備分配至多個節點的能力並且達到縮放性，可以辨識保留某些記錄之佇列設備的子集合。關於每個插入佇列之記錄的”規格”具有此目的。
4.基元佇列操作
為了以該方法操作佇列，必須取得適當的基元操作。Linda核心[1]使這些在設備上鬆散模型的佇列可使用。首先必須企圖達到提供下列基元的需求：
mq_put(record)-此基元係將所傳遞之記錄作為參數插入佇列中。值得注意的是，記錄不需要皆為相同的尺寸，也不需要共用一些抽象類型定義。引用此基數不會封鎖呼叫者。
mq_read(spec,record)-此基元從佇列中讀取符合規格(spec)的一項記錄而不需要擷取之。此基元可以被封鎖或否。若用戶端指定的過期時間為0，則基元立即回傳所擷取的可用記錄或是當蜂巢為空的時不回傳任何東西。若過期時間為正，則呼叫者等待直到一項這樣的記錄變為可用或是呼叫者設定的過期時間到期為止。過期時間不可以是無限的並且具有最大值(參考附件)。
mq_take(spec,record)-此基元從佇列中讀取符合規格的一項記錄並將其從佇列中移除。如同該例子，此基元可以被封鎖或否。若用戶端設定的過期時間為0，則基元立即回傳所擷取的可用記錄或是當蜂巢為空的時不回傳任何東西。若過期時間為正，則呼叫者等待直到一項這樣的記錄變為可用或是呼叫者設定的過期時間到期為止。過期時間不可以是無限的並且具有最大值(參考附件)。
基元已列舉如上，理論上，允許適當管理佇列記錄。然而，在消費者使用mq_take()基元從佇列中擷取並讀取一項記錄並且接著在其可張貼執行操作的結果之前死亡的例子中，則有效率的喪失該記錄。解決此問題的方法為對前述之同級組基元進行下列優化處理：
佇列中的每個記錄係指派至唯一ID。透過佇列基礎結構可自動的指派此ID，並且回傳成功的mq_read()或mq_take()呼叫。
mq_take()基元採用一項額外強制參數來指定呼叫者期望需要處理記錄的時間。此時間應超過實際所需的時間，以處理可能的延遲。這是有效率的租賃。若租賃到期而沒有更新，則該記錄會再次被所有其他消費者看見。
額外的基元(mq_reset(ID,lease))對佇列中的記錄進行操作，其ID係根據租賃值具有不同的特性。這裡有三種例子：
1.若將租賃設定為常數MQ_TMINFINITE，”接收者”通知佇列系統被指定ID的記錄已完全地處理。因此，該記錄可以被刪除。
2.若租賃值被設定為0，則”接收者”會通知佇列系統被指定ID的記錄尚未被處理，且呼叫者再也不需要該記錄，因此該記錄可再次被所有人看見。
3.若租賃值為正，則”接收者”通知佇列系統被指定ID的記錄需要延長租賃。因此，在請求延期的時間仍無法看見該記錄。
使用該改變將可避免消費者可能的損失，如下：
1.消費者將引用mq_take從佇列中擷取記錄，指定需要用來處理記錄的時間。此時間將會被系統轉換為租賃。
2.此時消費者將存取將被租賃的記錄存取將被租賃的記錄，並因此僅邏輯的從佇列中刪除該記錄。採用這種方法將沒有任何消費者可接收或讀取該記錄直到其租賃到期。
3.若租賃過期，則該記錄復活並且可再次為任何其他消費者使用。若舊的消費者在處理記錄時故障會出現這種狀況。
4.在消費者決定其無法或不想完成處理的例子中，其應引用mq_reset(ID,0)。這將使其他消費者可再次使用佇列中的該記錄來進行處理。
5.在消費者完成其處理的例子中，其應藉由引用mq_reset(ID,MQ_TMINFINITE)指出其處理程序的完成。已處理的記錄應從佇列中永久移除。
6.在消費者需要額外時間來處理記錄的例子中，在其租賃過期之前，將引用mq_reset(ID,extension)，因此租賃將會被延長相當於參數extension的額外時間，且與租賃相關的記錄將繼續在請求時間內維持隱藏。
仍然被指出的是插入佇列中之記錄的規格應該為如何。規格係使用名稱來顯示，表示為可變長度且由個別子字串組成之空中止字串(null-terminated string)，子字串之間係以斜線(‘/’)隔開。每個這樣的子字串僅可包含任何8位元字元(除了’/’與以及用來中止C語言字串的空字元)並且不可超過225字元。
辨識”蜂巢”的規格：包含同質記錄(這部代表蜂巢中的所有記錄皆具有相同尺寸)的部分佇列系統儲存庫可藉由規格本身來說明。規格需遵守一些規則：
1.其為蜂巢的名稱，非樣板，且其存在於相同的名稱空間中。
2.規格長度不超過1024字元。
3.規格不可以是不完整的，且蜂巢之規格的前置不可以為其他可用規格。例如，若”a/b/c”代表蜂巢，則”a/b”不可以為蜂巢，但是”a/b/d”與”a/b/e/f”可以。
4.在規格中不支援任何形式的圖型匹配或不使用萬用字元。
5.按字面意思來看規格，代表任何按字母順序之字元是重要的，且蜂巢名稱可因規格而有所不同。此外，嵌入於規格中的空白是有效的並且不可以被MaxiQ分散連結。
6.蜂巢規格可選擇性的為形式N：/a/b/c...，其中在’：’字元之前的前置N為代表同級組ID的十進位字串並且告知MaxiQ蜂巢儲存了同級組N的重要資訊。如果是這種情況，蜂巢本身將不會儲存於同級組”N”中(如下述)。前置”N：”為蜂巢名稱的主要部分。關於不包過這樣前置一名稱的唯一不同在於MaxiQ系統的語意係與”N：”前置有關。例如，729：marketing/inquiries/log代表名稱為”729：marketing/inquiries/log”(注意冒號後面的空白)的蜂巢係與同級組729相關。一個或多個這樣空白是名稱的有效部分。因此，”729：marketing/inquiries/log”係與”729：marketing/inquiries/log”不同。然而，在冒號之前的非十進位制字串或空白字元將不會堅持以往的語法。因此，”729：marketing/inquiries/log”將代表蜂巢名稱，但是冒號前面的空白字元避免此蜂巢被視為與同級組729有關。
將指出關於在消費者想要經歷佇列中記錄之例子中的額外議題，由於mq_read()不會造成佇列的任何改變，因此接下來的讀取將重複回傳相同的記錄，直到執行mq_take()操作為止。為了列舉佇列記錄，因此有必要對mq_read()呼叫做稍微的改變。這包含增加一參數至mq_read()，其為應被略過的佇列記錄ID。藉由有效的將ID設定至MQ_NULLID，基元將讀取可用的第一記錄。藉由設定其至所讀取最後記錄的ID，則將會回傳下一個記錄。若具有特定ID的記錄不再存在於佇列中，藉由將ID參數設定為0，則該特性將相同於引用基數的特性。最後，需要至少兩個基元：
1. mq_create(spec)基元將蜂巢規格作為參數並當其不存在時新增這樣的蜂巢。
2. mq_delete(spec)基元將蜂巢規格作為參數並且當其存在時刪除這樣的蜂巢。
5.設計
將MaxiQ實現為MaxiFS服務可用的設備。其邏輯模式為礎分散式檔案系統的功能性將可作為實現MaxiQ的基礎結構使用，然而MaxiQ將可以為處理複製以及冗餘性重建等等更高階的分散式檔案系統服務所使用。因此，MaxiQ的功能性可輕易的疊加至MaxiFS所支援的檔案系統名稱空間。因此蜂巢可映射至檔案。這將明確的提供MaxiFS所支援的冗餘性與縮放性給MaxiQ。MaxiFS名稱空間係透過散列技術來實現，其將目錄分配至多個伺服器，使得將名稱空間充分的同質分配至所有節點允許將工作量分散至節點(縮放性)並且允許維持資料的冗餘儲存庫(可用性)。因此，MaxiQ可輕易的繼承MaxiFS之可用性與縮放性的特性。
MaxiQ的設計已支援對檔案進行只能附加寫入模式的概念(不需要明確的同步作用)。這是需要實現mq_put()基元的基礎設備。將支援的額外功能性為從檔案中擷取記錄的能力(於必要時透過該租賃與壽命機制有條件的刪除之)。
MaxiQ的設計因此建立於MaxiFS的強度並支援MaxiFS所需要的複製與例外管理。當MaxiFS使用MaxiQ的時後MaxiQ使用MaxiFS在意義上似乎有點衝突。然而，事實為MaxiQ使用MaxiFS資料路徑成分，而MaxiFS管理使用MaxiQ。因此，實際的問題將僅於當MaxiFS管理系統使用同級組上的某些蜂巢時發生。解決方法為與蜂巢以及與蜂巢相關的同級組一起進行辨識。此同級組ID成為蜂巢規格的一部份，如上所述。在此方法中系統將會保證蜂巢將儲存於與蜂巢內容無關的同級組內。個別的MaxiQ蜂巢係實現為全域MaxiFS名稱空間之特定分支中的檔案。透過檔案系統名稱空間無法看見此分支，且該分支僅可透過MaxiQ基元間接的進行存取。這樣的檔案為三向冗餘(其所在之每個同級組成員上皆有一副本)，且對其的存取係為讀取或寫入操作。然而，後者僅發生於附加模式中。換句話說，這樣的蜂巢僅因為新記錄依附至末端處而改變。不然的話其內容並未改變。
每次只有同級組的一個成員來管理蜂巢。用戶端透過MaxiQ基元使用的特殊協定將其請求傳送至蜂巢管理者。執行管理者同級組成員為同級組的主要成員。其提供用來實現使用者請求地執行序池。這些已適當的同步，以便保證蜂巢的一致性。若管理蜂巢的同級組成員進入離線狀態，該同級組成員扮演新主要成員的角色亦接管蜂巢的管理來保證蜂巢的持續可用性。蜂巢本身的結構為平衡樹，其保留對所有記錄的參考並允許對其進行即時存取。索引記錄包含對所屬索引頁面之記憶體中的指標以及磁碟上的檔案偏移。其亦包含對檔案偏移形式之資料記錄的參考。每個資料記錄係於接收時儲存於磁碟中，且其偏移係記錄於平衡樹中。平衡樹允許從蜂巢中的任何地方刪除記錄並允許將新記錄新增至蜂巢末端。
個別資料記錄的屬性，例如其ID、其租賃時間以及其尺寸係與參考資料記錄本身的索引頁面一起儲存。這允許藉由僅更新所參考的頁面索引執行對記錄的租賃時間的改變(由引用例如mq_take()以及mq_reser()基元所造成)。此機制依賴刪除純邏輯的方式來刪除現存的資料記錄。換句話說，藉由移除指向記錄的參考可將記錄從指向記錄之樹的頁面刪除，而不是透過實體刪除記錄來完成。當修改索引頁面時，其係附加至對蜂巢進行備份儲存的檔案末端。這造成對在父索引頁面中被更新之已修改索引頁面之最後化身的檔案偏移，其接著附加至檔案等等以至樹的根頁面。當附加新的根時，蜂巢檔案包含全更新的樹。當蜂巢管理者開啟蜂巢檔案時，其讀取記憶體中的全索引階層，從檔案末端根頁面之最後化身處開始讀取並以其方法讀取剩餘部分。若樹的更新不完整(遺失根頁面或中間頁面)，則蜂巢管理者自動回復樹的先前版本。由於修改蜂巢檔案之MaxiQ基元在將控制權還給呼叫者之前同步的更新，因此這不是關鍵的。因此，唯一可遺失的項目為基元執行不正常完成的項目。呼叫者將知道此，並將無法假設更新達到穩定儲存器。蜂巢檔案為冗餘的事實使得讀取無法回復之壞區段的機率很小。隨著時間的過去，蜂巢檔案可處於包含相當數量的舊記錄、舊索引頁面以及目前的記錄與索引。當有效記錄與舊記錄的比值超過既定臨界值時，蜂巢管理者藉由建立作為清除舊資料之新檔案來重建蜂巢。
6.結論
MaxiQ實現穩健的設備，其可將資訊儲存用來執行離線處理。其支援下列功能性：
1.將記錄附加於複製蜂巢內的能力，實現蜂巢之同級組中高達兩成員故障所殘存之複製蜂巢。
2.同級組管理者之間的透明故障轉移，以適當的處理服務的故障轉移。
3.遍歷全記錄列表的能力。
4.從蜂巢頂部基於租賃的擷取記錄一段時間。這於租賃者故障時支援存活的記錄。
如此一來，期望MaxiQ作為MaxiFS中許多系統管理服務的基礎。在附件中會詳細說明MaxiQ設備之用戶端可用之基元的範例C語言語法。
附件--MAXIQ基元的規格
文件的這個章節提供本發明實施例以C語言函式庫的形式對MaxiQ設備所支援API的詳細說明。
包含用於MaxiQ之常數、類型定義以及函式原型(function prototype)的C語言標頭檔案為mq.h，並且必須藉由使用該設備的C程式包含在內。在連結時，這些應用程式必須連結在MaxiQ函式庫中。
內容
MQ_TMINFINITE此常數係用來指定對mq_rest()的無限長度租賃(相當於透過mq_take()從佇列中將租賃記錄永久移除)，並且透過mq_put設定記錄的無限壽命。
MQ_MAXTMO此常數指定以秒表示之過期時間的最大長度。
MQ_MAXBUF此常數指定附加至蜂巢之個別資料記錄的最大位元組數量。
MQ_NULLID這是對rid_t類型之變數的空值(如下述)。
類型
此處定義一些資料結構。其與MaxiQ函式庫中的基元一起使用。
unit8_t無號位元組。
unit64_t無號64位元長。
rid_t此類型係用來定義變數，其用來包含佇列項目的唯一辨識器。值得注意的是，ID僅對橫跨既定規格有關的記錄來說是唯一的。
rdmode_t此列舉類型係用於mq_read()來選擇操作模式是否為擷取ID符合輸入至基元之ID的記錄，或該基元是否應在指定一ID之後擷取第一記錄。類型之值為：RDM_EXACT(當尋找精確ID匹配時使用)以及RDM_NEXT(當已提供ID之記錄之後的記錄為預期時使用)。
mqr_t此類型係用來定義可變長度結構，其包含指向記錄規格之成分的指標，並且當透過mq_read()或mq_take()擷取其實際值時包含指向其實際值的指標。資料結構包含下列欄位：
rid_t mqr_id；
int mqr_lease；
int mqr_bufsize；
int mqr_size；
unit8_t mqr_buffer[]；
欄位mqr_id總是設定為MQ_NULLID，藉由任何基元的呼叫者將指標指向輸入中的mqr_t結構。這是由被呼叫的基元來設定。
欄位mqr_lease為記錄的租賃期間，其可以被設定為MQ_TMINGINITE或是其可以為正的秒數。
欄位mqr_bufsize以位元組來指定mqr_buffer[]陣列的尺寸並且總是由呼叫者來設定。
欄位mqr_size指定使用中之mqr_buffer[]陣列的位元組數量。對mqr_put()呼叫來說，呼叫者將mqr_bufsize與mqr_size皆設定為緩衝器中使用中的位元組。對mq_read()或mq_take()呼叫來說，呼叫者將mqr_bufsize設定為緩衝器尺寸並且將mqr_size設定為0。基元將mqr_size設定為緩衝器中實際使用中的位元組數量。
欄位mqr_buffer[]為儲存實際記錄的可變長度緩衝器。其長度不可以超過MQ_MAXBUF位元組。
公用程式
MaxiQ基礎結構使可用來組構可儲存’b’位元組之可變長度mqr_t結構之公用程式巨集(utility macro)為可用的：MQR_ALLOC(p,b)。
巨集採用類型為mqr_t *的第一參數(p)以及以位元組為長度的第二參數(b)。第一參數為可變至新記錄之指標的名稱。第二參數為即將組構之記錄之緩衝器的位元組尺寸。若成功，巨集指定新組構結構的指標指向p。否則，已指定之值為空指標。可透過標準函式庫常式free()釋放以此方法組構的結構。
回傳碼
此處係定義由基元回傳代表成功或失敗的程式碼。如下：
MQ_OK成功地執行基元。
MQ_INIT MaxiQ未初始化。
MQ_BADID不具有這樣的記錄。
MQ_SIZE緩衝器的尺寸不夠擷取記錄。
MQ_BADSIZE記錄長度之無效緩衝器尺寸。
MQ_TMO查無資料。這可能當被引用的基元指定過期時間且於過期時間到期時沒有記錄符合存在規格時發生。
MQ_BADREC無效的或空記錄指標。
MQ_BADSPEC無效的記錄規格。
MQ_BADREQ無效的或未實現的請求。
MQ_NOSPEC不存在這樣的規格。
MQ_BADLEASE無效的租賃值。
MQ_BADTMO無效的過期時間值。
MQ_OPEN蜂巢已開啟。
MQ_NOTFOUND項目未找到。
MQ_NOMORE沒有更多項目可看。
MQ_SYSERROR內部系統錯誤。
MQ_BADARG無效的參數。
MQ_EXISTS蜂巢已存在。
MQ_ALLOC無法組構記憶體。
MQ_BADIO I/O操作失敗。
MQ_NOHIVE不存在的蜂巢。
MQ_NOFLUSH無法沖洗蜂巢。
MQ_NODEL無法刪除蜂巢。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
mq_creat()
名稱
mq_create-新增新的蜂巢
概要
#include<mq.h>
int mq_creat(const unit8_t *spec)；
參數
spec 此參數為指向包含感興趣蜂巢規格之字串的指標。不允許字串開始於斜線字元(‘/’)。
說明
此基元的目的為將現存的蜂巢從MaxiQ中刪除。
此呼叫(spec)的唯一參數是用來辨識要被刪除之蜂巢的規格(如上所述)。刪除蜂巢代表永久性的刪除其包含的資料記錄。
回傳值
MQ_OK成功地執行基元。
MQ_INIT MaxiQ未初始化。
MQ_NOSPEC空的蜂巢規格。
MQ_BADSPEC無效的蜂巢規格。
MQ_ALLOC無法組構記憶體。
MQ_SYSERROR無法刪除蜂巢。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
mq_read()
名稱
mq_read-讀取符合規格之佇列中的下一個可用記錄
概要
#include<mq.h>
int mq_read(const unit8_t *spec,rid_tid,rdmode_t rdm, mqr_t *period,int tmo)；
參數
spec 此參數為指向包含感興趣蜂巢規格之字串的指標。不允許字串開始於斜線字元(‘/’)。
id 此參數指定先前讀取記錄的ID。其也可以被設定為MQ_NULLID。
rdm 此參數指定具有提供於id中的ID之記錄ID的精確匹配是否為尋找要讀取的記錄(在此例子中，此參數應被設定為RDM_EXACT)，或是是否應讀取ID被指定為id之後的記錄(在此後者例子中，此參數應被設定為RDM_NEXT)。
precord 這是指向包含記錄規格之資料結構的指標，並且在回傳時將會被記錄內容填滿。
tmo 此參數指定在回傳錯誤訊息之前當沒有可用記錄時基元應等待的最大秒數。當不具有符合存在規格的記錄時要求立即回傳，則可將參數設定為0，或是當呼叫必須暫停直到一項這樣的記錄變為可用時，可以將參數設定為不超過MQ_MAXTMO的秒數。
說明 此基數的目的為從佇列中讀取記錄而不需移除之。
此呼叫(spec)的第一參數係用來辨識應擷取記錄處的蜂巢(如上所述)。
此呼叫(id)的第二參數係用來辨識已處理之記錄，因此引用根據第三參數(rdm)之值回傳具有特定ID的記錄或是該記錄之後的第一記錄。當id被設定為MQ_NULLID時，rdm參數應被設定為RDM_NEXT，並且回傳蜂巢中的第一可用記錄。當id被設定為非空值記錄ID時，當要擷取具有特定ID的記錄時應該將rdm參數設定為RDM_EXACT，或是當要擷取的記錄為指定ID之後的記錄時應該將rdm參數設定為RDM_NEXT。當rdm參數被設定為RDM_EXACT且具有特定ID的記錄不在存在於蜂巢中時，回傳錯誤訊息MQ_NOTFOUND。這將會在記錄被”取走”(參考mq_take())時發生，而呼叫者係掃瞄所有的記錄。
第四參數(precord)指向資料結構，其中具有將要被擷取的記錄。透過MQR_ALLOC()公用程式可組構這樣的資料結構。若作為部分mqr_t結構的緩衝器不大，則基元將部分填滿緩衝器直到其容量並且將會回傳錯誤指示至呼叫者。此結構的成員的用法如下：函式的呼叫者總是將欄位id設定為MQ_NULLID。被呼叫的基元將其欄位更新為所擷取記錄的ID。欄位mqr_lease為記錄的租賃期間，並且當讀取記錄時該欄位總是為0。呼叫者係設定欄位mqr_bufsize，以指定mqr_buffer[]陣列的位元組尺寸。呼叫者亦可將mqr_size設定為0。基元將mqr_size設定為該記錄實際使用中的位元組數量。若記錄緩衝器的尺寸不夠大到包含全記錄，則適當的設定precode指向的資料結構欄位，但是不會將資料回傳於mqr_buffer[]內並且會回傳MQ_SIZE錯誤訊息。在此例子中，precode指向的結構欄位mqr_id係設定為記錄的ID，且欄位mqr_size係設定為記錄的實際長度。藉由檢查回傳碼，呼叫者可辨識狀況，組構夠大的緩衝器並重新發佈具有無法被讀取之記錄ID的請求，並且指定讀取模式為RDM_EXACT。
當無法取得符合規格的記錄時，第四參數(tmo)指定呼叫者是否應該暫停tmo秒。若要求立即回傳，則此參數可以被設定為0，或是當呼叫必須暫停直到可取得符合規格的記錄或是指定過期時間到期時，將此參數設定為不超過MQ_MAXTMO的正值。
用來擷取與處理與蜂巢相關之所有記錄之此基數的一般呼叫係與下列程式碼片段大致相同：
rid_t id；
mqr_t *pr；
/* 1024只是隨機選取之緩衝器的尺寸*/
MQR_ALLOC(pr,1024)；
if(！pr)
exit(1)；
id=MQ_NULLID；
while((ret=mq_read(“a/b/c”,id,RDM_NEXT,pr,0)) ==MQ_OK){
id=pr->mqr_id；
processrecord(pr)；}
像是該的呼叫讀取儲存在蜂巢”a/b/c”中所有的現存記錄，但是將其留在蜂巢中執行其他處理。在類似此的例子中係為了通過清單中的所有項目因而指定空的過期時間。當使用無限的過期時間時，呼叫者將在最後項目進入佇列之後被封鎖，等待要被附加的其他項目。所節錄的程式碼並未強調由於引用可能基於其他原因而不成功而必須更仔細察看回傳碼的事實。例如，若一個引用回傳錯誤訊息MQ_NOTFOUND，其代表之前所擷取的項目目前在也不可用，且應該要重新執行該迴圈。這可能需要必須忽略已執行過之該項目的應用程式。
回傳值
MQ_OK成功地執行基元並且擷取一項記錄。
MQ_NOHIVE空的蜂巢規格。
MQ_BADARG空的記錄緩衝器指標。
MQ_BADIO無法讀取記錄。
MQ_BADREC無效的記錄。
MQ_SIZE對記錄來說緩衝器太小。在此例子中，記錄緩衝器之”mq_size”欄位包含無法擷取之記錄的實際長度。
然而，回傳空的且不應該存取之資料緩衝器(“mq_size”)。
MQ_BADSIZE無效的緩衝器尺寸。
MQ_TMO過期時間在擷取適當記錄之前到期。
MQ_BADTMO無效的過期時間值。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
mq_take()
名稱
mq_take-從佇列中讀取並移除符合規格的下一項可用記錄。
概要
#include<mq.h>
int mq_take(const unit8_t *spec,mqr_t *precord,int lease, int tmo)；
參數
spec 此參數為指向包含感興趣蜂巢規格之字串的指標。不允許字串開始於斜線字元(‘/’)。
precord 這是指向包含記錄規格之資料結構的指標，並且在回傳時將會被記錄內容填滿。
lease 此參數指定所尋找之記錄的租賃期間。租賃期間係以秒來表示。所請求的租賃時間必須為正值並且不可以設定為MQ_TMINFINITE。
tmo 此參數指定在回傳錯誤訊息之前當沒有可用記錄時呼叫者應等待的最大秒數。當不具有符合存在規格的記錄時要求立即回傳，則可將參數設定為0，或是當呼叫必須暫停直到一項這樣的記錄變為可用時，可以將參數設定為不超過MQ_MAXTMO的秒數。
說明
此基數的目的為從佇列的特定蜂巢中擷取記錄。
此呼叫的第一參數(spec)係用來辨識應擷取記錄處的蜂巢(如上所述)。
第二參數(precord)指向將儲存被擷取記錄的資料結構。透過MQR_ALLOC()公用程式可組構這樣的資料結構。若作為部分mqr_t結構的緩衝器不大，則基元將部分填滿緩衝器直到其容量並且將會回傳錯誤指示至呼叫者。在此例子中，不會將像是mq_read()操作的呼叫操作的記錄從佇列中移除。mqr_t結構的成員的用法如下：呼叫者總是在引用此函式之前將欄位id設定為MQ_NULLID。被呼叫的基元將其欄位更新為所擷取記錄的ID。欄位mqr_lease為以秒為單位之記錄的租賃期間，其不可以被設定為非正值或是MQ_TMINFINITE。呼叫者係設定欄位mqr_bufsize，以指定以位元組為單位之mqr_buffer[]陣列的尺寸。呼叫者亦可將mqr_size設定為0。基元將mqr_size設定為實際用來將資料記錄複製至緩衝器的位元組數量。若記錄緩衝器的尺寸不夠大到包含全記錄，則適當的設定precord指向的資料結構欄位，但是不會將資料回傳於mqr_buffer[]內並且會回傳MQ_SIZE錯誤訊息。在此例子中，將mqr_id欄位設定為該記錄的ID，並且將mqr_size欄位設定為記錄的實際長度。藉由檢查回傳碼，呼叫者可辨識狀況，組構夠大的緩衝器並重新發佈請求(若此時候者被其他用戶端擷取則不會相同的記錄)。欄位mqr_buffer[]為可變長度緩衝器，其中的實際記錄係被擷取。第三參數(租賃)係指定呼叫者期望用來處理該記錄的秒數。對指定的時間期間佇列中的記錄將不可使用。接下來，呼叫者具有下列選項：
1.若其讓租賃過期(這可能因為執行呼叫的執行序死亡)，則記錄會重新出現在佇列中。
2.其可引用mq_reset(ID,MQ_TMINFINITE)將該記錄從佇列中永久的抹除。
3.其可在當引用mq_take()時所取得的租賃到期之前引用mq_reset(ID,0)使佇列中的記錄為可用的。
第四參數(tmo)指定若無法取得符合規格的記錄時呼叫者是否應暫停tmo秒。若要求立即回傳，則此參數可以被設定為0，或是當呼叫必須暫停直到可取得符合規格的記錄或是指定過期時間到期時，將此參數設定為MQ_TMINFINITE。
回傳值
MQ_OK成功地執行基元並且擷取一項記錄。
MQ_NOHIVE空的蜂巢規格。
MQ_BADARG空的記錄緩衝器指標。
MQ_BADLEASE壞的租賃值。
MQ_NOMORE沒有更多的可用項目。
MQ_BADIO無法讀取記錄。
MQ_BADREC無效的記錄。
MQ_SIZE對記錄來說緩衝器太小。
MQ_BADSIZE無效的緩衝器尺寸。
MQ_TMO過期時間在擷取適當記錄之前到期。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
mq_put()
名稱
mq_put-將記錄附加至佇列末端
概要
#include<mq.h>
int mq_put(const unit8_t *spec,mqr_t *precord,int wait)；
參數
spec 此參數為指向包含感興趣蜂巢規格之字串的指標。不允許字串開始於斜線字元(‘/’)。
precord 這是指向包含記錄規格之資料結構的指標，並且在回傳時將會被記錄內容填滿。
wait 若在接收來自呼叫的控制權之前呼叫者不想等到新記錄穩定儲存，則可以將此參數設定為0。
說明 此基數的目的為將記錄附加至特定蜂巢內之佇列的末端。
此呼叫的第一參數(spec)係用來辨識記錄應附加至的蜂巢(如上所述)。
第二參數(precord)係指向包含將要附加之記錄的資料結構。透過MQR_ALLOC()公用程式可組構這樣的資料結構。Precord指向之mqr_t結構的數量係使用如下：在引用此函式之前呼叫者總是將欄位id設定為MQ_NULLID。在成功地執行呼叫之後，基元將其設定為系統指定的ID。欄位mqr_lease為以秒表示之記錄的租賃期間，其應被設定為0並且被此基元忽略。呼叫者係設定欄位mqr_bufsize，以指定mqr_buffer[]陣列的位元組尺寸。呼叫者亦將mqr_size設定為等於mqr_bufsize。
欄位mqr_buffer[]為呼叫者儲存將要附加之記錄的緩衝器。若最後參數(sync)被設定為0，也就是其為空參數，對呼叫者而言此呼叫為不可中止，且呼叫者在快取記錄時取回控制權。否則，只有在記錄為穩定儲存時呼叫者才可取回控制權。
回傳值
MQ_OK成功地執行基元並且將一項記錄附加至佇列。
MQ_NOHIVE空的蜂巢規格。
MQ_BADARG空的記錄指標器或是無效的記錄尺寸。
MQ_BADSIZE無效的記錄長度。
MQ_BADIO無法寫入記錄。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
mq_reset()
名稱
mq_reset-重設佇列中特定記錄的租賃
概要
#include<mq.h>
int mq_reset(const unit8_t *spec,rid_t id,int lease)；
參數
spec 此參數為指向包含感興趣蜂巢規格之字串的指標。不允許字串開始於斜線字元(‘/’)。
id 此參數指定先前”取走”之現存記錄的ID。
lease 此參數指定在記錄租賃到期之後關於執行呼叫的時間的秒數。可接受的值為0(可立即看到該記錄)，正值(租賃將於執行此呼叫的數秒之後過期)或是MQ_TMINFINITE(記錄係永久的從佇列中移除)。
說明 此基元的目的為重設現存記錄的租賃時間或壽命。
此呼叫的第一參數(spec)是用來辨識記錄應附加至的蜂巢(如上所述)。此呼叫的第二參數(id)是用來辨識將被執行基元影響的記錄。第三參數(lease)為記錄租賃在最後引用此基元時間之後持續新的秒數。可接受的值為0、正值或是MQ_TMINFINITE。會造成以下例子：
1.若租賃的新值為0，則佇列中受影響的記錄將立即可見。
2.若租賃的新值為正值，則租賃在引用此基元時間之後的特定額外時間區間將維持不可見。
3.若租賃的新值為MQ_TMINFINITE，則該記錄係永久的從佇列中抹除。
回傳值
MQ_OK成功地執行基元。
MQ_NOHIVE空的蜂巢規格。
MQ_BADID無效的記錄ID。
MQ_BADLEASE無效的租賃值。
MQ_NOTFOUND記錄未找到。
MQ_BADIO無法寫入已修改的記錄。
MQ_ENET網路錯誤。
MQ_SHUTDOWN系統正在關機。
MQ_ECONN連結錯誤。
MQ_NETDOWN網路存取錯誤。
MQ_EMSG接收無效的訊息。
參考
[1]Carriero,N.,Gelertner,在1989年四月於ACM通訊技術第82卷第4期之第444-458頁中所發表的”Linda的背景”。
IV.典型的成員資格協定 1.前言
MaxiFS基礎結構是由儲存節點的聚集所組成。這裡有基礎結構中儲存節點的兩個邏輯成員資格。一者為管理伺服器聯盟(Management Server Federation,MSF)。MSF是用來促進MaxiFS基礎結構中的系統管理活動。另一個邏輯成員資格為同級組。同級組係促進檔案系統的相關操作。
此文件說明用來建構MFS與同級組的成員資格協定。其中展示了用於該協定之作為發展與驗證架構的模擬架構。
2.維持狀態
儲存節點將成員資格協定用於加入MSF與同級組。在處理期間，節點維持故障回復或正常重新啟動的里程碑狀態。除了該狀態之外，也維持下列資訊：
●MSF分組視圖。可以為0或1視圖。
●0或多個同級組視圖。
2.1 MSF群組視圖
MSF群組視圖包含如下：
●MaxiFS基礎結構的ID。
●節點最後知道的MSF群組視圖之版本。
●視圖的時間標記(用來執行啟發式決策，如下述)。
●包含視圖中節點ID的MSF群組向量。
●MSF之根目錄的IP位址。
2.2同級組視圖
●同級組的ID。
●同級組視圖的版本。
●視圖的時間標記。
●屬於該同級組之節點的ID。
●同級組之主要節點的IP位址。
3.節點成員資格的狀態轉變
當節點加入MaxiFS基礎結構，總是在企圖加入同級組之前加入MSF。因此，如第25圖所示，節點的成員資格狀態轉變如下：
●INIT：初始化狀態，不具有任何成員資格。
●MSF-JOINED：節點加入MSF。
●PEER_SET-JOINED：節點加入至少一同級組。
因此，成員資格協定包含用於形成MSF的協定以及用於形成同級組的協定。範例協定說明如下。
4. MSF成員資格協定
MSF成員資格協定包含下列子協定：
●發現/加入：節點用來發現與加入MSF的協定。
●合併：該協定允許MSF根目錄將群組視圖與其餘成員同步，並允許在網路分區之後將數個MSF樹合併。
●故障偵測(Failure Detection,FD)：該協定確保MSF群組的完整性。
第26圖顯示在MSF加入期間節點的狀態轉變。以下章節將會討論子協定的詳細內容。
4.1.1.1發現/加入協定
第27圖顯示發現/加入協定的狀態轉變。
當初始化節點時，在時間範圍tmin 至tmax 期間其係維持在”融解”狀態中。初始設定在休眠狀態(dormant state)中的節點可避免當全儲存基本結構重新啟動時(也許是在電源中斷之後)產生”封包風暴(packet storm)”狀態。從該狀態逾時所花費的時間為該節點ID的功能。ID是節點的永久識別(例如，ID可以為基於該節點之第一網路介面MAC位址的數字)。實際上，時間是節點ID在此狀態期間用來解析MSF根目錄內容的決定性函數，並且有助於快速收斂。
若有儲存任何永久MSF視圖，則當節點從”融解”狀態中喚醒之後係進入”請求加入”狀態。其傳送請求至MSF的根目錄。若同意該請求，則其被視為MSF的號碼並開始執行FD子協定。若沒有之前的永久MSF視圖或是節點從”請求加入”狀態逾時，則其進入發現狀態並開始IP多播發現封包(例如，使用TTL，本地連結多播位址224.0.0.0/25，有限範圍的位址239.0.0.0-239.255.255.255將多播封包限制於MaxiFS系統內)。
在發現狀態中，節點監聽輸入並決定候選根目錄來加入。候選根目錄的資訊可以為兩種形式：1)由其他節點傳送至該節點的建議封包，2)由根目錄於群組多播位址傳送的群組同步封包。
若節點在發現狀態中逾時，則該節點承擔根目錄的職責並開始合併協定。
4.1.1.2合併協定
當節點承擔根目錄的職責時，其進入合併狀態並開始合併協定。其週期性地執行全組同步封包之有限範圍的IP多播，其包含如下：
●MaxiFS ID(在建立時指定給全基礎結構的ID)。
●視圖版本。
●接收者應等待下一個同步封包之以毫秒為單位的經過時間。
●MSF中的節點ID列表。
●散列表代表促進名稱空間解析的同級組組構。該視圖的版本應安裝於包含內部節點通訊的所有呼叫，特別是透過EJB執行的呼叫。可偵測任何的版本不一致並且有助於視圖同步。為了避免修改EJB介面，可使用EJB 3.0提供的攔截器(interceptor)來實現。包含於同步封包中的資訊作為下列用途：
●其提供對所有節點的同步視圖。節點應考慮從MSF迴避的本體並且當其版本失去同步時需要重新加入。
●其作為根目錄對階層的租賃。
●其提供在系統啟動期間加速階層收斂的機制。
●其提供在網路分區之後合併MSF樹(與同級組)的機制。
第28圖顯示合併協定的狀態轉變。
節點可從合併狀態轉變為”請求加入”狀態，其中運用加入協定將其聯盟與其他聯盟合併。此事件可於當MSF的根目錄從其他節點接收包含代表具有較小ID之現存根目錄資訊的建議或群組視圖時發生。
合併協定的另一個重要層面為合併同級組。同級組可因為網路分區而被分為兩個被降級的同級組。我們將在以下章節定義其處理程序。
4.1.1.3基於租賃的FD協定
一旦節點加入MSF，則節點進入FD狀態並開始FD協定。除了在節點加入至少一同級組之後在同級組內執行可能的FD協定之外，也包含在MSF階層處執行的FD協定(因為節點可以不是任何同級組的成員)。
如第29圖所示，為了執行MSF階層的故障偵測，MSF通常係組織為由節點ID來排序的循環鏈接串列(circular linked list)。較小的ID節點建立係具有其相鄰節點的租賃。透過更新每個租賃，請求者提供期限延長的租賃，且在到期時間內更新租賃是請求者的責任。若節點未能更新租賃，則該節點為嫌疑節點。
值得注意的是，若任何節點為嫌疑節點，則必須產生事件來通知MSF根目錄與同級組散列表與MSF群組視圖保持同步。
然而，MSF的根目錄不可能經歷故障。這應該以下列方式來處理：
●具有最小ID的節點總視為MSF的根目錄。
●根目錄係週期性的將群組視圖傳遞遍及基礎結構。該資料包含節點應等待下一視圖傳遞的經過時間。若節點沒有在特定時間內接收n次訊息，則根目錄應是有嫌疑的。
●若根目錄為有嫌疑的，則節點應嘗試藉由以地增ID順序審查MSF中的所有節點來推選下一個根目錄。當遇到接受推選的第一個節點時停止。
●新的根目錄響應推選請求，並包含對MSF的請求節點。值得注意的是，當節點傳送推選請求時，其包含其同級組資訊，因此，新的根目錄在推選處理程序期間瞭解同級組成分。
5.同級組加入協定
在節點加入MSF之後，應該繼續進行同級組的加入。基本上有兩種可能性：
●節點不是任何同級組的成員。
●節點為至少一同級組的成員。
在第一個例子中，該節點為加入任何同級組的候選者或是其可變為資料儲存庫節點。MSF應根據基礎結構的狀態決定適當的動作。若系統中具有被降級的同級組，則命令該節點在之後加入降級的同級組。
在第二個例子中，節點應一次一個的與其所屬之所有同級組的主要節點共同繼續其之前的同級組成員資格。同級組之主要節點係選擇同意或拒絕請求。該協定的結果將傳送至MSF的根目錄，因此告知根目錄目前同級組的視圖。同級組之主要節點執行如下：
●若拒絕請求：
■將決定通知加入成員。
●若同意請求：
■將新視圖通知同級組次要成員。
■蒐集來自成員的確認訊息。
■維持結果並更新關於新同級組視圖的MSF根目錄。
如第30圖所示，根據加入節點的觀點，協定繼續進行如下：
●傳送單播請求至主要IP位址(若節點為主要節點則不需要)。當節點加入MSF時，MSF根目錄指定主要節點的IP位址。若位址定IP位址，則該位址將會是加入節點先前維持的位址。
●若發生逾時，則傳送請求至同級組擁有的多播位址。
●若在此狀態中發生逾時，則有兩種可能的動作：
■若該節點為同級組的主要節點，其傳送成為主要節點的請求至MSF的根目錄(儘管不保證特別在系統啟動期間可取得管理者同級組，此任務可由管理者同級組來協調。因此，具有MSF的根目錄是更可靠的)。具有幾種結果：
◆同意請求，且節點變為主要節點。回復包含在”等待加入”狀態中任何存在的次要節點之資訊。
◆拒絕請求，且節點維持在”等待加入”狀態中。
◆根目錄將同級組主要資訊作為回復。接下來，節點繼續加入處理程序。
■若節點不是同級組的主要節點，其將會進入”等待加入”狀態。
當節點在同級組之”等待加入”狀態中時，將等待事件來繼續加入處理程序。同級組的主要節點可能是故障的。該同級組是故障的，其中所有的次要節點係等待主要節點的出現。
MSF根目錄可執行的一種啟發式決策為若同級組在此狀態中直到其可前進的限制，則命令次要節點形成該同級組。同級組將至少回到被降級的狀態。協定繼續進行如下：
●MSF根目錄藉由提供次要節點之資訊命令節點之一者(兩者中具有較小ID者)成為主要節點。
●主要節點增加視圖版本並邀請其他節點加入該同級組。
●主要節點接收來自次要節點的確認訊息。
●主要節點儲存協定結果。
●主要節點更新MSF根目錄關於新同級組的資訊。
目前同級組仍在被降級的狀態中，其中僅具有兩個成員。當系統進化且容量變的可用時，MSF將同級組回復至一般狀態。
6.同級組協定 6.1同級組協定1
管理系統(management system,MS)維持在每個本地資料庫中作為部分聯盟的節點組以及描述已組構同級組的所有必要資訊。系統維持的一項關鍵結構為節點表，系統與聯盟協定引擎(federation protocol engine,FPE)共用該節點表。當特定節點(又稱為元組(tuple))上的FPE啟動時，其從系統中擷取節點表的副本，並且當協定邏輯進行時對此副本執行操作，並於每個合併週期將節點表的改變與系統同步。此章節主要係集中於對同級組協定與聯盟協定的說明，並說明同級組協定引擎(peer set protocol engine,PPE)如何與FPE連接。
同級組協定(也就是特定同級組成員之間的對話)係用來確認同級組的個別成員可彼此通訊。由MS來選取加入同級組的成員，且FPE與PPE接不具有對處理程序的直接控制權。(MS的成員選取演算法係考量各種條件，例如容量尺寸與同級組狀況以及其他商業規則，且在協定引擎階層無法取得此資訊。)
每當MS執行其選取演算法並組構新的可能同級組，FPE於下個合併週期使用由MS產生的成員改變，並將這些改變反應於本身的節點表副本。接下來，將新增節點表分配至聯盟的其他成員作為由跟節點傳送出的部分合併訊息。若節點表指出從傳送最後合併訊息以來同級組成員已改變，接下來所抵達反應節點表中發生改變的新合併訊息係傳送至PPE來初始其同級組對話並確認特定同級組的成員是否可彼此通訊。接下來，在PPE完成同級組成員之間的對話之後(不論是否成功)，PPE將具有代表成功或失敗的對話結果傳送至MS。若對話結果傳遞成員通訊失敗的訊息，則MS使用傳遞資訊並透過其選取演算法再次執行，並於必要時組構取代無法通訊的成員。
當新節點加入聯盟或是現存節點離開聯盟(例如由於節點故障)時FPE也會通知MS。這樣的資訊亦觸發MS執行其成員選取邏輯。同級組協定之內部運作的詳細說明如下。
第31圖顯示下列處理流程。當節點第一次啟動時，引發多個執行序來處理以節點之節點/容量對表示之每個同級組元組。每個元組執行序進入”等待”狀態來等待合併訊息的到達。當這樣的合併訊息到達時，元組首先審查包含於合併訊息中的同級組成員資格資料來判斷此特定元組是否被指派給同級組(3100)。基於合併訊息的內容，若特定元組不屬於同級組，這樣的元組會回到”等待”狀態，其中其繼續審查每個到達的合併訊息來判斷其是否被指定給同級組。
然而，當合併訊息指出特定元組屬於一同級組時，元組係判斷相同同級組有哪些其他元組並開始與其對話，傳送邀請訊息至每個成員並等待將回傳的InviteAck確認訊息(3105)。根據同級組協定，元組將在放棄之前嘗試初始與和相同同級組有關之其他元組的對話數次。InviteAck訊息包含成員的目前顏色、角色、檢查點編號以及同級組世代編號(若該成員屬於現存的同級組)或是”未指定”指示器(若同級組是新的)。每個元組係擷取來自MS的此資訊，MS將其保存於其本地資料庫。元組之間這樣通訊的整體結果為當Invite/InviteAck交換完成時，每個成員應知到其他成員的顏色、角色、檢查點編號與同級組世代。
一般來說，在藉由元組執行交換之中的任何不一致代表某種程度的系統故障，可以在步驟3110中解決。當關於相同同級組之兩個或多個元組的每一者代表其為主要成員時會發生這樣的狀況。一般來說，不一致應由元組來解決，例如藉由選取關於最高同級組世代的資訊。若出現不一致且世代編號相同，則藉由使用具有最高檢查點編號的同級組成員可解決這個限制。在當世代標號與最高檢查點編號皆相同的不一致例子中可藉由選擇具有最低節點id的同級組成員提供決定性(tie-breaking)機制。
假設同級組之三個成員的每一者接收來自其他成員的回覆，同級組協定引擎繼續進行至確認狀態。在此狀態中，指定的元組(也就是具有最低id的元組)傳送確認同級組訊息至根節點(3115)，表示所有三個成員皆成功的交換Invite/InviteAck訊息，並且接下來每個元組皆進入等待下一個合併訊息的”等待”狀態。(在接生來自同級組元組的確認同級組訊息時，根目錄依序傳送PEER_SET_CREATED事件至包含在此事件中成功交換邀請訊息之元組清單的主要MS。MS因而更新其節點表，表示已確認過其同級組成員。接下來，根節點係在下一個合併週期將這些改變與其本身的節點表同步，更新處理程序中的聯盟視圖id，並且將這些改變分配至其他節點。)當新的合併訊息到達時，等待元組執行序係檢查是否已更新其同級組項目。
一個實際的故障情況可包含在傳送訊息期間無益的遺失合併訊息(例如，由於UDP傳輸錯誤)。當特定同級組之所有三個元組遺失合併封包時，每個這些元組係繼續等待並且不會發生損害。然而，若至少一成員未接收封包且其他元組接收封包，則元組將會被迫彼此失去同步。為了避免發生此狀況，當在確認等待狀態中的元組接收合併訊息時，這樣的元組對其同級組中的其他節點執行遠端方法呼叫(remote method incovation,RMI)(3120)，重複的傳遞至已接收合併訊息的這些節點。RMI呼叫的處理者接收合併訊息並將其置入目標元組之訊息佇列，因此保證每個元組將接收合併訊息。(若特定元組已透過正常處理程序接收合併訊息，則其拒絕任何複製封包。)因此，整體結果為使用RMI呼叫保證所有元組將接收合併訊息，即使只有一個元組接收合併訊息。因此，所有的元組繼續進行至一致的下個狀態。
若發生這樣的更新，元組係傳送PEER_SET_CONFIRMED事件至本地MS來宣佈已確認的同級組。然而，在傳送這樣的事件之前，元組可執行額外的活動(3125)。特別是在特定例子中，當新增新的同級組時，在傳送該事件之前，元組協議例如根據其相對節點id順序指定節點顏色。值得注意的是，可以將紅色指定給具有最低id的成員，綠色指定給具有第二低id的成員，而藍色指定給第三低以及剩餘成員。再者，將例如根據相對節點id順序以及對同級組id執行模數3來選取成員的角色。例如，若對同級組id執行模數的結果為0，則選取具有最低節點id的成員為主要成員，依此類推。此外，每個非主要成員將會被指派次要成員的角色。最後，新同級組的世代編號將會被設定為0。接下來，將所有訊息傳遞至本地MS作為部分的PEER_SET_CONFIRMED事件(3127)。值得注意的是，也可以使用其他方法來指定顏色以及主要/次要角色。
然而，有時不需要更新根據FPE分配至基於MS之節點表之合併訊息中之元組的同級組資訊。不具有更新節點表的可能原因包含：(i)在往根節點的路上遺失初始確認同級組訊息(ConfirmPeerSet)，或是(ii)時間問題，且元組在繼續進行其操作之前將必須等待下一個合併訊息。若當合併訊息到達時合併訊息中的同級組資訊未被更新，則具有最低節點id的元組將再次傳送新增同級組訊息(CreatePeerSet)至根目錄(3130)，並進入另一”等待”狀態。如目前的預想，同級組元組將的等待具有其項目更新為”已確認”的合併訊息。然而，可以按需要來調整這樣的時間間隔(time interval)，且基於此目的所精確定義的不同時間間隔亦在本發明的範圍內。
另一個可能的故障情況可能在Invite/InviteAck交換期間發生，其中在嘗試多次Invite之後，特定元組未接收來自其同級組之至少一者的InviteAck回覆(3135)(也就是”邀請”元組未接收來自”丟失”成員的回覆，在這樣的例子中，”邀請”元組係進入回復狀態)。成員可能無法回復的原因分成兩種主要類型；可能具有節點或容量的實體故障或是具有網路分區。即使”邀請”元組無法區分這兩種類型的故障，但是係體對這些故障的回應有相當的不同。在下列說明中，首先指出包含實體成員故障的例子，並接著說明協定引擎如何處理網路分區的問題。
單獨成員的故障例子顯示各種可能性。首先，同級組可能丟失其一或兩個成員。再者，同級組的”丟失”成員可能是目前指派的主要成員。這兩種情況接無法立即解決。在任一例子中必須採取的第一動作為如同步具有丟失成員之同級組的例子一樣繼續傳送一般的ConfirmPeerSet訊息至根節點(3140)。該訊息係由回應Invite訊息之元組間所指定的元組來傳送，例如具有最小節點id的元組。傳送訊息指出那個同級組成員回應Invite訊息。在傳送訊息之後，傳送元組進入”等待”狀態，等待下一個合併訊息。在接收ConfirmPeerSet訊息時，跟節點將執行與執行關於完全充滿同級組之ConfirmPeerSet訊息相同的動作。如上所述，這些動作包含：傳送PEER_SET_CREATED事件至MS，並且回應由MS對節點表所造成的改變，並因而調整本身的節點表。在”丟失”成員的特定例子中，MS將根據PEER_SET_CREATED事件辨識未回應同級組邀請的一些成員。MS將會對回應成員旗標為”已確認”來對接收這樣的PEER_SET_CREATED事件作回應。關於其他”丟失”成員，MS將立即離開這些”丟失”成員(因而允許遲抵達的例子)，或是當其決定該成員因為確實故障而為丟失成員時將選取替代成員。在其他例子中，根節點會在下個合併週期將由MS對MS節點表的任何改變與其本身的節點表進行同步。
等待來自根節點之合併訊息的元組執行序將審查訊息以確認其本身的項目已經過確認，並且也將藉由MS檢查是否已選擇任何替代成員。由於丟失至少一成員，因此將執行一些額外的操作(3145)：訊息中同級組的世代編號將會增加1，且若丟失成員之一者先前為主要成員，則將使用該基於模組的選擇機制來選取新的元組來承擔主要成員的角色。然而，新成員的顏色指定將不會改變並且維持相同。不論在此合併週期是否選取新的成員，若藉由根節點傳遞至元組的節點表表示現存成員被旗標為”已確認”，每個元組將傳送PEER_SET_CONFIRMED事件至本地MS(3150)。當本地MS接收訊息時，其將同級組旗標為”降級”或”故障”同級組，並且採取適當的動作(3155)。在故障同級組的例子中，例如MS通常將於”唯讀”模式(也就是MS將對同級組成員啟動檔案系統服務，在此方法中將不允許更新本地磁碟上之分散式檔案系統的分割直到MS將模式切換為讀取-寫入模式)中啟動快速路徑服務(也就是藉由在每個同級組成員上執行的個別檔案伺服器處理程序實現的檔案系統服務)。
若已選取新的替代成員，再將PEER_SET_CONFIRMED事件傳送至本地MS時(且增加世代編號)，元組執行序將啟動與其原始開機交換相同之新的Invite/InviteAck交換(3160)。若所有成員皆如期望的回應，則現在完全填充的同級組準備待確認且每個元組接傳送其他ComfirmPeerSet訊息至根節點，其中根節點如該執行精確的相同動作，也就是其通知目前完全填充的同級組之MS，從MS擷取更新表，並且傳送在其下一合併週期中的更新節點表。當等待元組接收新的合併訊息時，其將視需要重新協商顏色/角色指派(例如，每個現存成員維持其目前的顏色且每個新成員被指派為使用的顏色，且新成員通常被指派為次要成員)並且將同級組世代增加1。接下來，新的同級組成員將再次傳送PEER_SET_CONFIRMED事件至本地MS，而原始同級組成員將傳送PEER_SET_UPDATED事件至MS。PEER_SET_CONFIRMED事件將包含額外的旗標來告訴本地MS在快速路徑服務之前啟動容量同步工作流程，且PEER_SET_UPDATED事件將包含旗標來命令MS不要公開成員資訊給快速路徑服務直到完成容量同步之後。
在元組傳送PEER_SET_CONFIRMED或PEER_SET_UPDATED事件至本地MS之後，其返回等待狀態。每當新的合併訊息到達時，其檢查是否最後已知的成員資格是否有所改變。若發生任何改變，則其重複與新辨識的成員進行Invite/InviteAck交換，並且通過該相同的處理步驟。當元組接收合併訊息時，其可能將會發現本身不再是同級組成員。若此發生，則將通知本地MS，且接下來元組將進入”等待”狀態。
由於網路分區，兩個不同的根節點皆可能具有全組節點的一些子集合。每個區將看見現存同級組的互補版本。例如，分區可能將兩個同級組成員置放於一邊，而將單一同級組成員置放於另一邊。同級組協定僅看到較小的圖像，且每一邊將對應的免費圖像通報至個別分區的根節點，其將依次傳遞至該分區的根MS。在這樣的分割中，無法藉由兩個根MS負擔同時取代相同同級組之”丟失”成員，因為當解決分割時，這樣的同步替代將產生具有潛在不同資料之相同同級組的兩個版本。MS將決定如何處理此狀態。FPE將叢集拓樸中的改變回報至MS，且MS決定如何解決。此處要記住的關鍵為具有兩個(或更多)分區，每個皆具有自己的根目錄以及主要MS例子。
當察覺發生網路分區時，每個部分之根MS中的規則引擎將採取適當動作，規定如下：1)當系統不斷變動時不要執行不可逆的動作(例如移動或取代)，以及2)當大比例的現存節點丟失時不要採取任何動作，除非管理上命令其執行動作。在n向分區的例子中，每個分區中的協定引擎繼續操作如上。每個分區中的根MS繼續接收事件(其中很多為故障事件)，繼續評估拓樸，並且繼續更新其內部狀態。然而，必須瞭解的是，在網路分區狀態下的操作中，根MS會受到限制，因此僅在與主要成員相關的分區中組構新的同級組。換句話說，根MS不應該在具有較少節點數量的分區中新增新的同級組。若不滿意此狀態(也就是若允許每個分區新增新的同級組)，則當重建分區時會發生同級組id衝突。下列雙向分區的例子係說明此原則。同級組id必須是唯一的。然而，若具有最小模式數量之分區A中的最高同級組id數量為N，具有最大模式數量之分區B中的最高同級組id數量為N+M，則新的同級組應組構於分區A中，這樣新的最高數量將會是N+1。因此，當兩個分區最終重合併時，兩個根節點MS例子將各具有同級組數量為N+1，其違反同級組id的唯一性，因此不被允許。必須強調該對根MS操作的限制為對新同級組之組構的限制。現存的同級組仍可有限制的徵求新成員。
在任何分區中具有任何兩成員(已降級)的同級組(也就是具有兩運作成員的同級組)可取代其丟失成員，不論是有關於同級組的那個分區並且繼續操作於該分區內的全功能狀態。然而，丟失成員僅應在經過適當逾時時間之後被取代，其可解決網路分區的問題。特定已降級同級組的丟失成員最終會根據該之同級組協定而被取代(其包含被增加1的同級組世代，由現存成員傳送的PEER_SET_UPDATED事件，以及由新成員所傳送的PEER_SET_CONFIRMED事件)。
操作於已分區環境中的單一成員(故障)同級組(也就是僅具有一個運作成員的同級組)的丟失成員無法被取代。反之，同級組協定將發送同級組已丟失兩成員的信號至本地MS，且該分區的根MS會將這樣的同級組置於”唯讀”狀態。丟失成員可存在為第二分區之兩成員同級組，且若該分區持續夠久，則將可能取代丟失成員。當最終解決網路問題且分區重建時，則MS驅逐舊的”唯讀”成員並且取回被這樣的成員所佔用的容量。該同級組的世代係根據以下而定義：若在發生雙向分區之前特定同級組具有世代編號N，則在分區之後，則在兩分區中之對應同級組的世代編號分別為M與L，因此世代編號指定至”已復原”同級組之重建分區為max(M,L)+1。若網路故障的時間很短，且尚未選擇任何替代成員，則單一成員將重新加入其舊的同級組，將其資料與其他兩成員同步(若發生任何改變)。藉由MS執行的有效操作為驅逐該成員，丟棄其失去同步的資料，並接著選擇相同的成員作為替代。
對合併n向分區叢集來說，這將如聯盟協定之部分正常操作的發生。當解決產生分區網路問題時，每個個別分區的根目錄將接收由其他根節點所傳送的下個合併訊息。新增為網路分區結果之叢集的根目錄將看見來自具有較低id之節點的合併訊息(原始根節點)，並將請求加入該節點。原始根節點將接著繼續其作為唯一根節點的狀態，構成其他分區的節點自動地重新加入作為其他根節點之一部份的根節點而將根節點狀態轉變為原始根節點。
6.2同級組協定2
此章節說明可用於本發明某些實施例之同級組協定的另一版本。
同級組協定的此版本具有四個主要狀態，某些子狀態可能會影響協定從一狀態轉變至另一狀態的方法。主要狀態為INIT_WAIT、PEER_SYNC、CONFIRM_PEERSET以及FD_WAIT。在正常情況下，同級組成員將於叢集啟動時透過每個這些狀態進行轉換，最終進入終端FD_WAIT狀態。一旦在此狀態中，同級組成員將等待一些外部事件來觸發轉變為其他狀態。以下將詳細說明這些狀態。
INIT_WAIT狀態
當節點初次啟動時，藉由協定引擎產生執行序來管理每個磁碟容量。每個這些執行序代表同級組中的潛在成員。這些成員執行序進入INIT_WAIT狀態，等待來自叢集之根目錄之合併訊息的到達。
合併訊息包含聯盟物件，且此物件包含該叢集中所有同級組的完整成員資格資訊。當合併訊息到達時，每個成員執行序審查合併訊息看看其是否被指派至一同級組，若是則看看是被指派至哪一個同級組。若成員未被指定至同級組，則其維持在INIT_WAIT狀態中等待下一個合併訊息。這將會被無限期的執行。
另一方面，若成員發現其被指定至一同級組，則檢查其同級組所在的節點是否加入該聯盟。節點的加入狀態係包含於相同的聯盟物件中，其係透過合併訊息傳遞至成員執行序。若至少一其同級仍未加入該聯盟(例如因為節點太晚啟動)，則該成員停留在INIT_WAIT狀態等待下一個合併訊息。其將留在此狀態直到其同級組所屬的節點全部加入該聯盟。
一旦所有成員最終加入為一團體，則其繼續進行至PEER_SYNC狀態。這適用於任何基數N的同級組，其中N大於或等於2。亦涵蓋了單件同級組(N=1)的例子，差異在於該成員不需要等待其同級組加入該聯盟，並且可以在被指派至同級組時直接繼續進行至PEER_SYNC狀態。
PEER_SYNC狀態
PEER_SYNC狀態的目的為讓同級組之成員交換有關其本身世界觀的資訊。在進入此狀態時，每個同級組成員詢問本地管理系統關於其所屬同級組的詳細資訊，例如同級組世代以及每個成員之角色、顏色與狀態。由於每個同級組位於個別的節點且每個節點具有描述其所屬同級組特性的本地資料，因此同級組可能有失去同步關於此資料的機會(可能由於某些類型的系統故障)。PEER_SYNC狀態提供讓同級組成員資料中任何差異一致的機制。
在本發明實施例中，同級組成員之間的資訊交換係使用UDP封包來完成，然而在其他實施例中可使用其他協定。UDP為橫跨個別系統之間交換資訊的便利機制，但其具有主要的缺點-不保證傳送封包將實際到達其期望的目標。因此，圍繞UDP設計的任何協定或是同樣不可靠的協定應具有足夠的內建冗餘性來最小化封包遺失的風險。
”同級組同步”交換包含多個回合。在第一回合中，每個成員建立同級組物件列表，包含於說明本身同級組資料之單一物件的第一回合中。接下來，每個成員透過同級組同步封包傳送此列表至其每個同級組，其基本上為同級組物建立表的容器，並且接下來在簡短的等待之後檢查來自其同級組的輸入同級組同步封包。若沒有任何封包到達，則其傳送其他回合的同級組同步封包，並在檢查額外輸入封包之前再次等待。
若成員接收來自同級組的封包，其增加包含於此封包中的同級組物件至其同級組列表，並將其他回合的同級組同步封包傳送至具有此更新列表的同級組。當成員接收來自其所有同級組的封包時(特別是當其同級組列表長度等於其所屬同級組的基數時)，其在傳送至同級組之下個同級組同步物件中設定”已同步”旗標，表示其以蒐集其同級組的所有同級組物件。當成員接收具有設定已同步旗標的同級組同步封包時記錄那個成員傳送該封包。
同級組成員之間的資訊交換繼續進行直到所有成員接收具有設定為已同步旗標之同級組同步封包為止。這保證每個同級組彼此知道。若在某預定回合次數之後成員仍未接收來自其同級組之至少一者的已同步封包，則該成員返回INIT_WAIT狀態。若發生此狀況，則該成員的所有同級組應處於相同的情況並且也將返回INIT_WAIT狀態。
若同級組同步成功，則該同級組轉變為CONFIRM_PEERSET狀態。如同在INIT_WAIT狀態的例子中，此處說明的同級組同步交換係與任何基數N的同級組合作，其中N>=2。也可以處理N=1之退化例子，但是不需要交換任何資訊，且該成員可直接繼續進行至CONFIRM_PEERSET狀態。
CONFIRM_PEERSET狀態
當到達CONFORM_PEERSET狀態中時，同級組成員可開始處理已交換的資料。在此處，每個成員應具有從其同級組蒐集之相同的同級組物件列表，在此列表中的每個個別同級組物件係說明同級組之特定同級組視圖。此狀態的目的是用來讓此資料一致，處理這些個別同級組物件的結果成為新的同級組物件，其中所有的成員認同包含指定每個成員的角色與顏色，同級組之世代以及關於該同級組的其他狀態資訊。需要考慮許多例子。
例如，成員可以為部分新形成的同級組，在這例子中同級組將交換不具有特性定義(無角色、顏色或狀態)的同級組物件，且同級組的世代將會被設定為預設值(例如-1)來表示新的同級組。在此情況中，同級組成員必須對同級組的每個成員指定角色與顏色。一個同級組將會被指定為主要成員的角色，而其他同級組將是次要成員，且每個成員將被指定唯一的顏色(例如在具有三個成員之同級組的例子中為紅色、綠色與藍色)。此處理程序中的關鍵步驟為在新的同級組中選擇主要成員，這將在以下主要選擇協定中說明。
其他可能性為該成員為在叢集重新啟動之後被重新開啟之先前新增同級組的部分。在此例子中，同級組同步化將使每個成員具有相同同級組物件列表，假設每個節點關於其成員所屬之同級組的特性是一致的。若同級組物件基於某些原因不匹配，則定義規則來判斷選擇那個同級組物件作為贏家。此選擇通常是基於同級組世代，其中具有最高世代的同級組獲勝。若世代皆相同但具有其他差異(例如角色或顏色不匹配)，則使用額外的規則來選擇獲勝的同級組。
第三種可能性為增加新成員至同級組。例如，具有兩成員的同級組可加入第三成員，因此當完成同級組同步化時，每個成員將具有三個同級組物件的列表，具有用於具有未定義其屬性值之新增加成員的物件。此新增加的成員將總是成為次要成員(因為現存成員之一者將已經為主要成員)，且其將被指定一唯一的顏色屬性。關於同級組的世代，每當同級組之拓樸中發生改變時會將其世代增加1。
第四種可能性為同級組丟失一成員，例如三個成員的同級組可減少為兩個成員的同級組。在此情況中，剩餘成員保持其已被指定的角色與顏色。在此情況中的特殊例子為已丟失成員的位置為舊的同級組主要成員。在此例子中係選擇剩餘兩個成員之一者為新的主要成員。在本發明實施例中，首先基於那個節點具有最少目前指定的主要成員數量來選擇新的主要成員，並且若具有相同主要成員數量的節點皆具有兩個成員時，則選擇具有較低ID的成員。例如，叢集中的每個節點具有N個磁碟容量，且特定同級組係由來自M個不同節點的容量所構成。在任何特定時間，屬於一節點的一些容量將作為主要成員，而一些容量將作為次要成員，且一些容量將可能是未指定的。當兩個成員的同級組必須決定哪一個成員作為主要成員時，則選擇已被指派至其主節點之具有最少主要成員數量的成員。由於在同級組同步化期間其為已交換資訊的一個額外位元，因此同級組成員已可用此資訊來執行此決定。
主要成員選擇協定
如該，在同級組必須選擇其成員之一者作為主要成員的情況是新同級組的例子。因為成員交換已指定至其主節點之主要成員作為部分的同級組同步處理程序，在新同級組中挑選主要成員的一種可能解決方法為選擇具有最低指派至其主節點之主要成員的成員。若單一新的同級組新增於以建立並執行之叢集上的一些點，則此方法將運作良好。問題為當初次建立叢集時並未指定任何的主要成員或其他東西。所有的同級組係於同時間或多或少的出現，並且當發生同級組同步交換時，計算所有節點的主要成員為零。這將表示該成員將回復到使用具有最低ID的成員作為主要成員，但這可能會導致較差的成員分佈，有些節點被指派四個主要成員而有些節點不具有主要成員。期望橫跨叢集的主要成員是達到平衡的，以有助於改善叢集的效能。
主要成員選擇協定是一種子狀態，同級組成員進入該子狀態來選擇同級組的那個成員將作為主要成員。該協定被設計用來嘗試挑選一成員，其可維持橫跨合理平衡之叢集的主要成員總數。期望取得最佳平衡但這並不是必要的。
該協定操作如下。每個節點維持指定至該節點的主要成員數量計數。當叢集初次形成時，所有節點的此計數為零。當選取主要成員時，此計數會增加。該協定採取先到先服務的方法。例如，在三個成員的同級組的例子中，不像在同級同步協定中所有成員同時啟動該協定，在主要成員選擇協定中，成員對誰將啟動該協定以及誰將進入等待狀態達成共識。在本發明實施例中，選擇係基於對同級組ID藉由同級組尺寸進行模數操作。因此，若同級組ID為15且同級組尺寸為3，則對15以3進行模數操作的結果為0，因此成員0將啟動該協定，假設成員係藉由其節點ID來排序。成員1與2將進入等待狀態，等待訊息到達來通知下一操作。
啟動該協定的成員尋找非常特別的狀態來決定如何繼續進行。在本發明實施例中係檢查其主節點來看看是否不具有任何主要成員被指派至此節點。若是這種情況，則其將此節點的主要計數增加1並推選其本身作為同級組的主要成員。其接下來離開主要成員選擇協定並啟動主要成員同步協定(如下述)。檢查節點的主要計數以及隨後增加其計數係實施為基元操作(例如透過”測試與設定”或鎖定機制)，由於在具有N個可具有同級組之磁碟容量的節點A中，其他同級組的N-1個其他成員亦於同時間檢查節點A的主要計數。藉由使其成為基元操作，唯一的一個成員將具有成功的零檢查。其他成員將皆看見此節點上的主要計數已經為1，且代替選擇此節點來具有其他主要成員，同級組成員將”傳遞火炬”至其直接的同級來繼續執行該協定，且傳遞火炬的成員進入等待狀態。
此傳遞係藉由主要檢查封包來完成。此封包包含主要計數，假定接收成員是用來測試此第一傳遞中何者的主要計數為零。在接收這些封包之一者時，成員離開其等待狀態並接管作為該協定中的引導。此時，對這些新的成員來說該協定同樣地繼續進行。每個成員將檢查其主節點是否具有主要檢查封包中表示的主要計數，且因為測試與增量為單一基數操作，因此依舊只有執行檢查之成員的一者將取得正面的結果。贏得檢查的一成員推選自己作為其同級組的主要成員，並且繼續進行至主要同步步驟。
測試失敗的成員透過其他主要檢查封包執行相同的傳遞至其直接同級，且對這些新的成員重複該處理程序。當同級組的最後成員接收主要檢查且主要計數測試再次失敗時，其傳送下一個主要檢查封包至啟動該主要選擇協定且目前位於等待狀態中的原始成員。在接收主要檢查封包時其學習被要求再次測試已測試過之零的主要計數。這表示該成員將被測試之值增加1，其在此第二傳遞期間將從0增加為1。該協定從此處繼續以這種方式對每個連續成員測試所請求的主要計數並且推選自己為主要成員或將檢查傳遞至此列表中的下一成員。最終，所有節點上的所有同級組將挑選具有合理良好或可能甚至最佳平衡分佈的主要成員。
主要選擇協定必須處理UDP封包丟失，且在此實施例中執行此具有內建逾時。例如，當節點傳送主要檢查至其同級時，知道在該協定環繞與還回時將接收已選取主要成員的信號(藉由下述主要同步封包)或是將接收其他主要檢查封包。若在期望逾時時間內未接收到新的封包，其重新傳送所送出的最後主要確認封包。其無法知道最後封包是否被接收，或是其未接到收新封包的理由是否是因為丟失了所傳送的封包。因此再次傳送相同的封包。當目標同級接收此封包時，其將知道此是否為最後主要檢查封包的副本或是新的封包。若封包是新的，其繼續處理該協定(如該)。若封包為副本，其依次重送傳送給同級的最後主要檢查封包，並且此確保該協定將繼續進行。若在嘗試多次之後該協定仍無法推選主要節點，則所有的成員最終回到INIT_WAIT狀態。
主要同步協定
當成員推選其本身作為同級組主要成員來作為主要選取協定的結果時，該成員繼續進行至主要同步協定。設計此協定是要確保同級組的所有成員知道成員以推選其本身作為主要成員。起初，只有一成員繼續進行至此新的子狀態，而其他成員仍維持在等待狀態中等待同級告知如何繼續進行。
當被推選的主要成員啟動主要同步協定時，其傳送主要同步封包至其每個同級組，表示其以取得主要成員的角色。當這些等待成員接收此封包時，其離開等待狀態並轉變為主要同步子狀態。在此狀態中，其依序繼續傳送主要同步封包至其每個同級組，包含在此封包中推選其本身作為主要成員的成員ID。主要同步協定從此處繼續本質相同於同級同步協定的處理，其中每個成員繼續傳送主要同步封包至其同級組並且依序接收來自其同級組的封包。此處的差異為成員僅交換其相信已被推選為主要成員的成員ID取代交換同級組物件。此封包交換繼續進行直到所有成員接收具有設定代表所有成員已接收來自其他每一者的封包之”已同步”旗標的封包。
當到達此點時，每個成員應具有透過其同級所傳送表示所相信的哪個成員被選取為主要成員的ID列表。這些ID應皆為相同的，但是若沒有機相同，則代表主要選擇與同步協定失效且所有成員將回復到INIT_WAIT狀態，當下一個合併封包到達時將會再次嘗試整體處理程序。
成員資格確認
所有的成員最終會轉變為會員資格確認狀態。這作為完成主要同步交換之後的下一步驟或是作為完成必須在同級同步步驟期間蒐集之同級組物件上所執行的任何處理之後的下一步驟。在進入此子狀態時，所有的同級組成員將與關於必須被確認之特定同級組物件一致，包含每個成員的角色、顏色與狀態以及同級組世代。
在繼續進行至FD_WAIT狀態之前，協定引擎必須取得來自根管理系統(Management System,MS)的確認，其確認與同意同級組成員贊成的同級組物件。為了取得同意，選擇具有最小ID的同級組成員傳送成員資格確認訊息至根MS。接下來的確認係藉由根MS定期傳送的一般合併訊息廣播的方法。同級組成員將無限期的等待此確認的到來。當終於接收確認時，可贊成或反對該同級組。若贊成該同級組，則成員將繼續進行至FD_WAIT狀態，若反對該同級組，則成員回復至INIT_WAIT狀態。該同級組被反對的可能原因有很多，但是從協定引擎的觀點來說，由於其僅操作於所接收的資料，因此同級組被反對的原因不重要。
合併同步協定
如該，藉由其合併訊息廣播的方式從根MS傳送成員資格確認訊息的確認。若總是如此，同級組成員必須處理可能的封包遺失。若所有三個成員皆遺失相同的合併封包，則其將僅繼續等待並且不會造成任何損害。若所有的成員接收合併封包，則可以繼續進行至同步中的下一狀態。然而，同級組的至少一成員可能失去合併封包並可能使其失去與其同級的同步。基於此理由，當接收合併封包時係使用同級同步交換的其他變化，而該成員係位元成員資格確認等待狀態。此合併同步交換再次執行與同級同步與主要同步交換類似的操作。在此例子中，成員交換所接收最新合併封包的序號。
例如，一成員可能會因為封包遺失而失去合併封包。在接收使封包時，其他成員立即啟動合併同步協定，傳送合併同步封包至其每個同級。合併同步封包包含所接收最近合併同步封包的序號。當失去此最後合併封包的成員接收此封包時，其將離開其等待狀態並且亦啟動合併同步協定。然而，由於其失去最後合併封包，其將無法傳送包含於其合併同步封包中其他成員的相同序號。因此，當完成合併同步時，成員將看到同級之一者失去及他所接收的合併封包，並且無法繼續進行至下一個狀態。因此，所有成員僅同意維持在成員資格確認等待狀態中，並將在下個合併週期再次嘗試同步操作。最終，所有的成員應接收相同的合併封包並且其將皆可作為群組繼續進行至INIT_WAIT或FD_WAIT狀態。
FD_WAIT狀態
在成功地完成CONFIRM_PEERSET狀態時，同級組成員轉變為FD_WAIT狀態。這被視為”終點”狀態。同級組的成員將無限期的維持在此狀態中並且將僅在代表需要改變狀態的一些事件發生時轉換至其他狀態。
用來觸發狀態改變的主要機制有兩種。當在FD_WAIT狀態忠實，成員週期性的監視佇列的輸入封包。若接收合併訊息，則檢查其同級組是否有任何重要的改變。例如，三成員同級組可能發現成員已從同級組中移除，這被稱為是拓樸改變。若此發生，則剩餘成員立即轉變至PEER_SYNC狀態來交換其最新同級組物件並透過MS來確認新的同級組。同時，被移除的成員將接收合併訊息並且將發現其已經從其同級組中被移除。在此例子中，成員傳送成員驅逐訊息至本地MS並且接著轉變至並且無限期的停留在INIT_WAIT狀態直到其再次加入同級組。
可觸發成員離開FD_WAIT狀態的第二機制為透過MS所傳送的重新啟動請求。這在當MS知道沒有對將造成成員轉變至新狀態的同級組拓樸產生改變時完成，但其強迫同級組成員回復至INIT_WAIT狀態以從某種類型的故障情況中恢復。在此例子中，同級組成員僅經由同級組協定的每個階段繼續進行並且最終將返回至FD_WAIT狀態。
V.範例小檔案儲存庫 1.前言
可於特定時間間隔在磁碟驅動裝置所執行的最大量I/O操作通常比可傳送的資料量或是驅動裝置的傳送率具有更多的限制。現代磁碟驅動裝置的特徵為當磁碟驅動裝置尚未被填滿時，在通常會造成I/O操作數量達到期最大值的相關市場、傳統檔案系統中即使不需要額外的儲存容量也可能會導致磁碟驅動裝置的激增。此依序可造成成本超過預期的上升。相關應用環境通常需要透過最小化檔案伺服器需要執行的I/O操作數量以有效存取小檔案。對於例如縮略圖或小圖片來說這是典型的例子。為了開啟一個這樣的檔案，即使對傳統網路檔案系統(像是NFS)查找路徑名稱之中間成分的時間打折扣，其通常將必須從參考期的目錄中查找檔案i節點，讀取該檔案的i節點，且最後讀取該檔案的資料區塊。此通常需要至少3個I/O操作。在許多相關環境中，期望最大存取將會是對具有平均尺寸約為64千位元組的檔案。除此之外，這樣的檔案係以非常隨機的方式來存取，因此透過使用前端快取記憶體(front-end cache)很可能不具有任何優點。因此，期望具有特殊設備來最小化存取這樣小檔案的I/O操作數量。
另一方面，透過審慎的取代檔案中的區塊，對等模式(ad hoc)檔案系統設計可限制實際I/O操作的數量並保證較高的磁碟頻寬。為了達到這目的，本發明實施例實現小檔案儲存庫(稱為MaxiSFR)。MaxiSFR係設計用來將讀取這種檔案的I/O操作平均數量降低為1。
2.基礎架構
調派可處理先前章節中所概述需求之子系統的方法為將小檔案儲存於作為相同尺寸(小檔案的最大尺寸)之延伸陣列的檔案系統伺服器容量內。接下來，藉由對陣列簡單的索引可對個別檔案進行存取。
為了瞭解這實際上如何實現，假設MaxiFS之名稱空間中的特定上層目錄係用於此功能性。假設此目錄不是真的存在任何地方，但是透過用戶端軟體以這樣的方法說明對在目錄下編碼索引之名稱的所有存取係管理為透過其索引對短檔案的特殊存取。例如，假設”/sfr”是這樣的目錄並且假設”/MaxiFS_1”為其用戶端上的安裝點。接下來，開啟”/MaxiFS_1/sfr/CD3A”將實際上請求對具有十六進位索引為0*CD3A之最佳化儲存庫上之小檔案的存取。這可以實現於將必須組構為供應每個伺服器磁碟驅動裝置的專用容量內。顯然的，在像是由幾千個伺服器所構成之MaxiFS基礎結構中，儘管額外資訊通常將用來辨識感興趣的儲存庫，僅索引將足以完全辨識儲存庫中檔案的位置。
3.對此範例實施例需求
此章節取得MaxiSFR設背壁需滿足此範例實施例的需求，也就是：R0.小檔案儲存庫對每個MaxiFS基礎結構來說必須是全域的，且儲存於其中的檔案必須是唯一可橫跨MaxiScale系統之全名稱空間來識別的。
R1.小檔案必須以這樣的方法來存取，使得所有open()、read()、close()序列皆不需要超過伺服器上的單一I/O操作。列舉、新增或寫入這樣的檔案不需要是有效率的。
R2.小檔案儲存庫必須強行限制其儲存檔案的最大尺寸並且可根據需求R1來進行存取。然而，MaxiSFR應允許這樣尺寸限制內的任何檔案儲存於MaxiSFR內。
R3.呼叫者必須可指定新增小檔案的檔案後置(suffix)(例如，辨識檔案類型：JPEG、GIF、MPEG等等)。後置可以為空值。非空值後置為檔案名稱的組成部分並且應該在列舉容量內容時擷取之。
R4.用戶端必須可藉由讓MaxiFS選擇名稱或是藉由讓請求用戶端指定名稱來新增小檔案(後者對備份還原特別有用)。
R5.必須列舉小檔案儲存庫的內容並且擷取關於小檔案的屬性。小檔案的名稱空間應以每個目錄的列舉不超過約1000個檔案的方法來分區。
R6.區塊複製設備必須允許遠端複製小檔案儲存庫來簡化儲存庫本身的備份與還原。
R7. MaxiFS基本結構的小檔案儲存庫的縮放必須正比於基礎結構成員的節點數量。
R8.小檔案必須支援其他檔案的所有屬性，例如擁有者的身份、存取保護權限、新增與修改日期等等。對任何其他檔案應強制執行檔案層級的存取保護。
R9. C語言必須與大部分用於網頁應用程式(Java、Python、Perl、PHP等等)一樣具有新增小檔案、寫入小檔案以及擷取小檔案名稱的函式庫功能。
接下來說明設備的詳細設計以及符合該需求的方法。
4.操作理論
此章節提供期望如何使用MaxiFS的詳細視圖。
此方法說明先前轉達的一般概念，即使基於下列理由透過其索引直接存取小檔案的特定用戶端是不實際的：索引本身總是提供某種程度上的存取，不論其是否仍被組構或已被釋放。
辨識那個伺服器管理保存感興趣小檔案之特定小檔案儲存庫是困難的。
基於此理由，每個這樣的檔案不應該僅透過索引來處理，而應該具有MaxiFS內的全域唯一ID。這樣的唯一小檔案ID(“USFID”)應建構為四個成分的串聯，如同在USFID中USFID=<psid><sid><bn>，尖刮號中的每個項目是唯一ID的成分，如下：<psid>這個欄位為小檔案所在的同級組ID(MaxiFS中的同級組為元資料冗餘的最小單位，這是個由三個伺服器所構成的小叢集，每個伺服器管理指定給該同級組的一個驅動裝置)。藉由將同級組ID嵌入USFID中，該檔案係永久的屬於該同級組並且當USFID未改變時無法自由的從一同級組重置至其他同級組。
<sid>這是同級組的插槽ID，或是換句話說為該檔案所儲存之邏輯容量區塊的索引。藉由使此部分資訊為USFID的一部份，該檔案僅可存在於容量內的特定邏輯偏移。
<bn>這是檔案使用的邏輯區塊數量。藉由將此部分資訊嵌入USFID，該檔案無法改變其跨距之邏輯磁碟區塊的數量。值得注意的是，檔案的實際長度位元組係儲存於磁碟中實際使用者資料之前的檔案元資料區域。
因此，假設<psid>為0*ABCD(“ABCD”，2位元組)，<sid>為(“0000000005”，5位元組)，且<bn>為16(“10”，1位元組，其代表檔案係儲存於17個邏輯區塊中)，該檔案的USFID係以十六進位法表示如下：ABCD0000 00000510。
唯一ID中個別欄位的長度為係完全的標示。這些欄位可以被減少、增加或分裂來滿足用戶端OS目標的限制以及期望用於個別欄位的最大值。在任何例子中，一旦決定就不應該改變欄位之間的邊界。
期望此資訊可透過MaxiFS特定fcntl()呼叫(參考下文)經由標準POSIX介面使用於應用程式，也可使用替代機制。關於USFID內每個欄位的長度的選擇係調整如下：將兩個位元組用於該同級組ID已足夠。具有64K可能同級組的MaxiFS基礎結構的節點包含4個驅動裝置，每個驅動裝置可涵蓋約50000個節點。這應該適用於很長一段時間。
將1位元組用於區塊中檔案的長度已經足夠。邏輯區塊相當於一千位元組。若出現於USFID中的區塊數量等於檔案中邏輯區塊的總量減一，這將涵蓋長度多達256千位元組的檔案，這是作為小檔案資格的最大長度。
將5位元組用來處理一千位元組區塊可涵蓋之代表240 (1012 )小檔案的起始邏輯區塊編號。這對應至每驅動裝置多達1PB的分區，這超過目前可取得驅動裝置容量的三個數量級。
儲存於檔案元資料內的資訊包含實際檔案長度位元組(用於該檔案的儲存空間量可小於整個範圍)，擁有者資料、存取權限、新增時間等等。這樣的元資料將儲存於該範圍實際資料之後的第一部份。
POSIX檔案介面不具有新增匿名檔案並於之後指定名稱給該檔案的方法。然而，MaxiFS允許透過一連串的POSIX呼叫來完成同樣的操作。因此應用程式碼應與下列相似：
1. fd=creat(“/MaxiFS_1/sfr/*”,0777)；
2. n=write(fd,buff,bytes)；
3....
4. sfn.buffer=name,sfn.length=sizeof(name)；
5. fcntl(fd,MAXIFS_GETNAME,&sfn)；
6. close(fd)；
在敘述1中所提供的名稱是很常見的。這是由請求新增檔案之用戶端上MaxiFS的安裝點(在此實施例中為”/MaxiFS_1”)以及相對於安裝點的路徑名稱(“sfr/*jpg”)所構成。後者指出全MaxiFS的虛擬小檔案目錄(“sfr”)以及常見檔案名稱。使用特定目錄名稱(虛擬目錄”sfr”被認為是MaxiFS用戶元件上的實際目錄，這目錄下的所有小檔案皆為可存取的，不具有子目錄，也不允許建立任何子目錄)通知MaxiFS的用戶端元件我們正在處理小檔案以及接下來應該以特定方式處理什麼。檔案名稱(“*”)不是個萬用字元(wild character)或是一般表示法(Unix系統呼叫不會解譯萬用字元或是一般表示法：任何字元會被逐字的解譯，因為萬用字元或一般表示法的擴充係於系統被飲用之前在函式庫或應用程式內執行)。這只是告訴MaxiFS系統必須新增小檔案並且對該檔案挑選適當檔案名稱的傳統方法。
從敘述2開始，呼叫可將資料寫入至新的小檔案。
接下來，在敘述5中，用戶端引用對MaxiFS的特定操作(“MADIFS_GETNAME”)。執行此fcntl()呼叫需要如下：用戶端通知MaxiFS目前已完全複製該小檔案。
用戶端請求系統產生給該檔案的USFID。該檔案的名稱將回傳為儲存於fcntl()視為參數(“sfn”)之資料結構中的字串。基於此理由，在敘述4中，呼叫者初始結構的欄位，指定將儲存名稱的緩衝器以及緩衝器的長度。
用戶端通知MaxiFS在引用fcntl()之後將不會對檔案執行任何寫入操作且MaxiFS將強制執行此。值得注意的是，因為USFID將嵌入檔案長度以及其容量偏移，因此這很重要。因此，若允許檔案從此處擴大，則可能會改變其長度以及檔案儲存的位置。
最後(敘述6)，用戶端關閉檔案。從此以後，可藉由其名稱對檔案進行讀取存取。假設檔案的USFID為”ABCD000000000510”,fcntl()引用將回傳路徑名稱”/MaxiFS_1/sfr/ABCD/000000000510”。為了在應用程式層級處完全支援此功能性，期望封包、函式庫等等將發展用於Web 2.0應用程式的普遍程式語言(Java、Perl、Python等等)。
值得注意的是，在”sfr”之下，檔案的全路徑名稱包含父目錄名稱(”ABCD”)。此名稱符合儲存該檔案之同級組的ID。”sfr”與剩餘檔案名稱之間中間目錄的理由為簡化這種檔案的聚合。這避免將所有小檔案列舉於基礎結構中如同所有小檔案皆具有相同父目錄(“sfr”)的需求。
這種形式的路徑名稱係顯示為傳統路徑名稱。然而，”sfr”與”ABCD”不存在於MaxiFS名稱空間中的實際目錄。每當MaxiFS的用戶端成分看見MaxiFS安裝點下此形式的路徑名稱時，其轉換USFID中”sfr”下的部分並且將具有此USFID的請求轉換為期望儲存該檔案的同級組(在此例子中為0*ABCD)。
一般來說係開啟這樣的檔案來執行讀取操作。然而，將這樣的檔案開啟來執行寫入操作是個重要的例子。若將從備份中還原該檔案，備份應用程式將透過其USFID來新增檔案並且寫入之。遠端複製需要相同的操作。然而，這只會＊發生於小檔案容量中的位置以及USFID所指之同級組可用時。若在使用中，則企圖新增這樣的檔案將會被拒絕。同樣的，注意需要儲存該檔案的邏輯區塊數量係嵌入於USFID中，因此在新增檔案時MaxiFS可確認可取得所需要的擴充。
在任何例子中，在新增小檔案之後，MaxiFS透過單一I/O操作支援對檔案的讀取存取。因此，基於USFID的路徑名稱可成為URL的一部份，因此對這樣檔案的網路存取(即使非常隨機的存取)不會使伺服器執行大量I/O操作。
列舉包含於特定名稱空間目錄中的小檔案僅需要辨識已組構範圍並且重建其唯一ID。為了列舉橫跨全MaxiFS之所有這樣的檔案，一項這樣的列舉應執行於系統中每個同級組的小檔案內。
透過基於USFID的名稱來刪除小檔案是可行的。
小檔案將必須具有冗餘性。為了簡化，將確認任何這樣的檔案存在於三個副本中：該檔案所屬同級組之每個成員中的每個小檔案容量皆具有一者。
值得注意的是，儘管MaxiFS實現檔案的邏輯複製，其中橫跨副本之檔案的實際組構是完全無關緊要的，對小檔案來說，不僅必須複製檔案，也必須將每個檔案精確的儲存於小檔案容量之每個副本的相同位置。若非如此，相同的ID無法應用至相同檔案的不同副本。
小檔案容量係組構為作為同級組成員之每個節點上每個驅動裝置的子分區。當組構伺服器時將建立這些分區。困難之處在於分區限制驅動裝置上可使用之儲存器的彈性。一旦組構分區，不論其為未使用、空的、輕微使用或是完全填滿的皆不會影響關於相同驅動裝置上的剩餘儲存器。因此即使一區域基本上是空的且其他區域為溢位也沒有辦法改變事時。這取決於事實來保證單一操作存取，必須對實體容量而不是邏輯容量進行存取，對邏輯容量進行存取可能需要額外的I/O操作來查找該分區之特定邏輯區塊的實際位置。
在敘述1中所提供的名稱是非常常見的。這是由請求新增檔案之用戶端上之MaxiFS的安裝點(在此例子中為”MaxiFS_1”)以及相對於安裝點的路徑名稱(“sfr/*.jpg”)所構成。後者指出全MaxiFS的小檔案目錄(“sfr”)以及由兩個子成分所構成的常見名稱。檔案名稱(“*”)不是萬用字元或是一般表示法(Unix系統呼叫不會解譯萬用字元或是一般表示法：任何字元會被逐字的解譯，因為萬用字元或一般表示法的擴充係於系統被飲用之前在函式庫或應用程式內執行)。這是告訴MaxiFS這不是實際檔案名稱且系統必須新增小檔案並且挑選適當的檔案名稱的傳統方法。名稱(“.jpg”)的後置是一項可能的後置，也可以選擇任何其他者(包含空後置)。然而，後置係與檔案共同儲存，且敘述5所產生並擷取的檔案名稱將由具有選擇後置(在此例子中為”.jpg”)之USFID的字串表示法構成。使用目錄(虛擬目錄”sfr”被視為MaxiFS之用戶端成分上的實際目錄，這目錄下的所有小檔案皆為可存取的，不具有子目錄，也不允許建立任何子目錄)係通知MaxiFS的用戶端成分我們正在處理小檔案以及接下來應該以特定方法處理什麼。一般名稱通知MaxiFS的用戶端成分這是個新增新的小檔案的請求，此時的USFID是未知的。該說明的關鍵點如下：
1.儲存於小檔案儲存庫中的每個檔案皆具有在MaxiScale儲存基礎結構之安裝點下之虛擬目錄”sfr”下的路徑名稱。此名稱代表透過MaxiFS用戶端軟體實現抽象化之MaxiFS用戶端可存取的虛擬項目。
2.該目錄具有虛擬子目錄：基礎結構中的每個同級阻街具有一者。每個這樣的子目錄具有由四個字元長度的十六進位字串所表示的名稱，其係對應至同級組的數值ID(在一般例子中，這樣的子目錄將包含其名稱的前導零)。一項這種虛擬子目錄的列舉係產生儲存於對應同級組之小檔案儲存庫中的檔案列表。進一步的虛擬目錄存在，以限制每個項目中的數量(如該)。
3.關於一般檔案，此設計的小檔案具有一些簡單提及的限制，也就是：
a.其長度無法超過全系統預定限制。
b.只有在名稱遵守基於USFID常規時才可以對MaxiSFR內的檔案進行重新命名，並且意味著將檔案重置至新名稱所指的區域。
c.若未填滿，其僅可擴充來填充檔案的最後邏輯區塊(也就是因此檔案所使用之邏輯區塊的數量不會改變，儘管檔案的長度位元組可能會改變)。否則，將必須改變包含已使用區塊計數的名稱。
d.只要所跨距之邏輯區塊的數量不要增加，則現存的小檔案可以被覆寫。
e.若可取得藉由小檔案儲存庫內之名稱所暗指之實際儲存器，則通常僅可藉由名稱來新增小檔案(主要是用來還原轉存(restore dump))。此名稱將包含虛擬目錄的名稱來辨識將要儲存檔案的同級組。
5.設計
文件中此章節的目的為詳細說明MaxiFS之範例小檔案設備的設計。
MaxiFS小檔案儲存庫係由所有小檔案儲存庫的集合所構成，系統中的每個同級組皆可使用。如R0的需求，個別儲存庫的聚合稱為小檔案儲存庫(或是簡稱SFR)且對MaxiScale系統的名稱空間來說是全域的。儲存於同級組上的每個個別儲存庫稱為同級組儲存庫(或是簡稱PSR)。每個PSR係橫跨同級組的所有成員進行複製，同級組之每個成員上之每個副本的尺寸與內容皆相同於同級組之其他成員，且其皆於鎖步中發展。個別PSR為完全獨立的項目，每個皆關於全域SFR的”虛擬子目錄”，其名稱為代表具有PSR之同級組之同級組ID的十六進位字串。當新的同級組成員加入同級組時，新的成員必須從其同級組複製其小檔案儲存庫的內容。儲存於每個同級組內之PSR的副本必須相同於該同級組之其他成員的副本。用於此目的之檔案系統容量不需要相同，但是意味著可用的實際空間將會是同級組成員之間的最小可用空間(所有皆必須堅持最嚴格的限制)，並且無法以具有檔案儲存庫小於已組構於PSR內之檔案所使用的最高區塊編號的新成員來取代現存成員。
5.1 PSR的組構
在每個個別同級組成員中，部分的磁碟驅動裝置被預留為作為一些本地PSR的分區。由於同級組之每個成員中的三個儲存庫皆相同並且在鎖步中發展，下列所有關於PSR討論的目的為應用至三個成員的每一者。
若PSR必須包含具有相同長度的檔案，則對每個PSR的管理將是非常簡單的，其中全PSR可再分割為皆具有相同長度的插槽，並且將必須持續追蹤那個插槽是空的那個插槽是滿的。MaxiFS的小檔案設備強制執行小檔案的最大長度(需求R2)。無法儲存超過此長度的檔案利用該設備且應該依靠通用檔案系統。
當可變長度檔案開始作用，過份簡化的實施可當作所有檔案皆具有最大許可長度而組構空間給每個檔案，不論每個檔案的實際長度為何。然而，已知小檔案從一個至預定最大數量的區塊，這將導致非常差的空間組構，主要的儲存器浪費係由於內部分割所產生。
因此，在本發明實施例中，空間係組構為”邏輯區塊尺寸”的倍數。此值被設定為1千位元組，因此小檔案可有效使用可用空間，限制內部分割。因此，PSR中的最小檔案將使用儲存庫上的1千位元組。如同在任何其他FreeBSD檔案中，每個檔案之儲存區域的初始部分包含所有相關檔案系統的元資料。這包含建立時間、修改時間、擁有者之使用者與群組ID、存取權限位元、檔案長度位元組等等(需求R8)。除此之外，檔案的元資料部分亦包含PSR相關的其他資訊，例如代表檔案後置的字串以及檔案的檢查總和(checksum)。
由於儲存在SFR中的每個檔案係佔據變數量的邏輯區塊，必須簿記來執行此。也就是，管理每個PSR的軟體必須可以：
1.找到用來儲存特定長度檔案的一些連續區塊。
2.不用讀取檔案的元資料即可辨識檔案跨距的區塊數量。
具有各種方法來管理可變長度檔案的空白空間。然而，最有效率的是位元映象，其中每個位元係關於一邏輯區塊。當位元被設定為1時，邏輯區塊為使用中，否則邏輯區塊是空的。位元硬像是很方便的，其允許輕易的尋找連續夠大的自由空間區域。
除此之外，每個PSR亦需要持續追蹤儲存於PSR中檔案的後置。這會加速儲存庫中的檔案列舉。因此，表格必須關於儲存這種後置的儲存庫。
最後，每個PSR必須包含標頭來儲存對PSR來說為全域的資訊並且定義其結構。下列資訊係儲存於此區域：PSR的版本。隨著時間的推移，可能需要較新的組構且此欄位可用來做區別。
PSR中邏輯區塊的尺寸。不同PSR的尺寸可能有所不同。
區塊中PSR的尺寸。
儲存PSR之自由空間位元映象的區塊索引以及區塊中位元映象的長度。
儲存在PSR中的檔案數量。
將PSR分為三個區域：
1. PSR標頭，說明PSR的特性(如該)。
2.自由空間位元映象。
3.實際檔案儲存庫。
由於同級組的每個成員皆具有PSR的鏡像副本，同級組成員之間儲存於三個區域中的資訊必須相同。
5.2小檔案操作
此章節及其子章節係說明可在小檔案儲存庫實現的操作以及實現的方法。
5.2.1概論
在SFR中，不可以新增目錄、刪除目錄、對目錄重新命名或是改變目錄屬性(包含存取權限位元)。實際上，這些”虛擬目錄”可見僅為了輕易的列舉包含的檔案。然而，期望支援用戶端能力來改變對任何這些虛擬目錄之處理程序的目前目錄。
每個PSR係對應至全域SFR的虛擬子目錄，其名稱為對應至具有PSR之同級組ID的十六進位字串。我們將在以下子章節中看到，這些PSR目錄也具有子虛擬目錄。記住系統提供SFR的視圖來代替虛擬目錄，然而，在磁碟上不具有對應的資料結構。這是視覺抽象化，僅需要提供更具結構性的SFR與PSR視圖。
在任何虛擬目錄中唯一的路徑操作為列舉目錄本身的內容以及新增與刪除檔案。值得注意的是，檔案是平衡的並且僅可以在PRS目錄階層的最低階層處新增與刪除檔案。
至於檔案，支援對檔案的新增(匿名或具有名稱)與刪除。只有在新名稱對應至構成檔案之區塊數量且新名稱跨距的區塊範圍是自由的時允許SFR內的重新命名。否則將會拒絕重新命名操作。很顯然的必須可以藉由名稱開啟小檔案來進行讀取、寫入操作或該兩者。
出現在SFR名稱空間中之虛擬目錄的擁有權係屬於系統。所有這樣的目錄皆具有標準存取權來允許所有使用者讀取、寫入以及執行權限。
需要對資料與元資料進行更新的檔案操作係以相同於管理一般檔案的方式來管理。
5.2.2用戶端與SFR的交互作用
MaxiFS用戶端驅動器在與SFR進行交互作用時必須表現特別。然而對一般檔案來說，用戶端驅動器係使用全系統散列表根據路徑名稱判斷那個同級組必須負責管理特定檔案或目錄，在SFR的例子中，用戶端需要確認目標為來自路徑名稱的小檔案之事實。偵測感興趣物件的路徑名稱必須具有SFR名稱作為其第一成份是很容易的。接下來，用戶端驅動器必須察看表示為十六進位字串之SFR名稱下方之第一階層目錄的名稱並且必須將其轉換為必須傳送其請求之同級組的ID。接下來，必須將全路徑名稱與將要處理的請求一起傳送至適當同級組的PSR。
除此之外，用戶端需要在兩種模式之一者中與SFR互動。一些交互作用本質上係與用於其他類型之檔案相同。這些包含在唯寫模式中開啟，藉由名稱來新增檔案，檔案刪除，目錄列舉、正常讀取與寫入等等。這些類型的交互作用隱藏所有SFR伺服器端上小檔案的特質。特別的交互作用組係針對SFR並且實施保證以1個I/O操作來讀取小檔案之特殊語意。此集合中具有兩個交互作用：
1.藉由讓伺服器選擇名稱來執行新增檔案的操作(根據檔案的位置與尺寸)。此交互作用特別的原因為本質上由先前的例子擷取並且包含辨識PSR包含新檔案的同級組，執行請求來新增未指定名稱的檔案，沿著所有檔案資料傳遞並接著擷取SFR伺服器產生給該檔案的名稱。
2.開啟檔案進行讀取操作的集合係藉由降低其為伺服器上的單一I/O操作來讀取其內容並關閉之。這包含向前遞送包含讀取模式的開啟請求，其回應(若成功)包含所有的小檔案資料。後者係緩存於用戶端直到隨後來自用戶端的讀取操作將資料本身擷取至發出請求的應用程式。
以下子章節係詳細說明伺服器端的個別操作。
5.2.3 PSR列舉
列舉對應至SFR之特定虛擬子目錄之PSR中以及關於同級組ID的所有檔案係降低SFR階層處關於全域列舉之被列舉項目的數量。然而，給定在USFID中的40位元係用來辨識PSR內的檔案，仍具有必須列舉高達240 (1012 )檔案的可能性，這將對使用者階層的公用程式產生問題並且將與需求R5形成對比。因此，這40位元名稱空間(這對應至使用檔案之USFID中的5位元組)係進一步以這樣的方法分區，因此每個虛擬子目錄具有不超過210(1024)個項目。這需要PSR中具有由四階層目錄構成的虛擬階層且該檔案僅出現於這樣階層的最底層。結果為在先前實施例所顯示的例子中，對應至USFID之檔案”ABCD000000000510”(注意，關於PSR之虛擬目錄下每個路徑名稱成分係限制為跨距於十六進位範圍0*000-0*3FF，這不是檔案本身的真實名稱，其包含對檔案長度進行編碼的兩個額外字元)的實際路徑名稱為”/MaxiFS_1/sfr/ABCD/000/000/000/00510”而不是”/MaxiFS_1/sfr/ABCD/000000000510”。
根據此組構，儘管檔案可能包含關於隨後虛擬目錄的區塊，起始區塊在對應至虛擬子目錄之全PSR之特定區塊範圍內的所有檔案僅出現在該虛擬目錄中。例如，檔案開始於區塊0*3EF，3區塊長的USFID為”ABCD00000003FE03”，並且將列為目錄”ABCD/000/000/000”下的”ABCD/000/000/000/3EF03”，儘管其最後區塊在目錄”ABCD/000/000/001”下的區塊範為中。
列舉中間虛擬目錄(SFR中的所有目錄，包含關於PSR的目錄並且不包含可能包含實際檔案的葉目錄)是不重要且完全虛擬的。這包含列舉可用的全十六進位範圍(0*000-0*3FF)，不包含將對應至超過包含PSR之容量尺寸之區塊的項目。因此，這是純計算並且不需要磁碟存取。
列舉葉目錄需要對磁碟進行存取。列舉PSR之特定虛擬子目錄內檔案的方法為開始於對應至被列舉之虛擬子目錄之PSR位元映象的位置，察看使用中的下一位元，存取對應區塊中的元資料資訊，並且藉由檔案長度重建來自起始區塊偏移的檔案名稱。然而，由於應該回報檔案後置(需求R3)且這並沒有隱含在檔案位置中，因此必須執行兩件事：
若檔案具有非空值後置，則應從新增檔案時儲存非空值後置的檔案元資料來擷取此。
接下來，後置將會被新增至尤其位置與長度等等構成的檔案名稱。
由於遍歷位元映象以及讀取每個檔案之元資料的需求是為了重建其名稱，因此列舉目錄將不會是非常快速的操作。為了根據位元映象列舉檔案，PSR管理軟體必須知道檔案開始於容量的哪個偏移。事實上使用中的邏輯區塊不足夠。檔案的起始區塊需要特定的標記。
同樣的，用來辨識檔案之起始區塊的資料結構會最佳化不具有後置之檔案的列舉。這可以藉由將PSR位元映象轉換為使用每個區塊的位元對(而不是單一位元)來完成。然而，仍將包含尺寸。在1TB PSR的例子中，擴充的位元映象將僅佔用256千位元組。
接下來，擴充的位元映象將根據下列特徵標記每區塊具有兩個位元的各種區塊：
00自由區塊
01忙碌的中間區塊。這是檔案主體內的一個區塊。
10起始不具有後置之檔案的忙碌區塊。
11起始具有後置之檔案的忙碌區塊。
接下來，列舉演算法將從對應至屬於將被列舉之虛擬目錄之區塊範圍的偏移察看已擴充的位元映象，並且操作如下：
1.審視位元映象直到遇到和PSR標頭中計數值一樣多的檔案。
2.略過自由區塊(特徵’00’)以及檔案中間的忙碌區塊(特徵’01’)。
3.對起始不具有後置之檔案的忙碌區塊來說(特徵’10’)，從起始區塊的位置以及檔案長度(從目前標頭區塊之後的第一自由區塊或下一個標頭區塊算起)重建檔案USFID，並將其轉換為檔案名稱字串。
4.對起始具有後置之檔案的忙碌區塊來說(特徵’11’)，從起始區塊的位置以及檔案長度(從目前標頭區塊之後的第一自由區塊或下一個標頭區塊算起)重建檔案USFID，讀取檔案標頭來擷取檔案後置，並將USFID與後置轉換為檔案名稱字串。
檔案操作係以些許不同的方法來處理，取決於其是否需要更新元資料或資料。若不需要，請求係藉由同級組之可用成員以循環的方式來實現。然而，若其需要更新元資料或資料(如新增、刪除或重新命名寫入與fsync的例子中)，同級組的主要成員只有在所有同級組成員彼此同步時藉由協調影響每個同級組成員上PSR之所有副本的更新以及承認請求用戶端來實現請求。
5.2.4新增檔案
檔案新增請求係藉由同級組的主要成員來實現。
為了在SFR中新增檔案，具有兩種可能性：藉由指定其名稱來新增檔案(大部分係藉由還原操作來完成)，或是藉由系統選擇名稱(這是普遍的操作模式且最多允許呼叫者指定檔案後置)。
在第一例子中，用戶端已選擇名稱：名稱將邏輯區塊數量以及其起始邏輯區塊偏移一起編碼於檔案中。因此，系統可從檔案名稱來解碼此資訊，並用來檢查將新增檔案之起始偏移與最後邏輯區塊之間的邏輯區塊目前並非使用中。
在此，若邏輯區塊是自由的，將其組構給檔案且允許用戶端寫入多達編碼於檔案名稱中的檔案長度。若一或多個區塊在使用中，則結果取決於用戶端的身份以及受影響檔案的權限位元。若用戶端的有效身份符合覆寫新檔案所使用區塊範圍中所有檔案，則使用中的區塊會被釋放(藉由自動刪除所屬檔案)。否則，請求會被拒絕。當新檔案與現存檔案完全重疊時也可使用相同的方法。
當新增新的檔案時，若在寫入檔案之前關閉檔案，則所有區塊皆被置零(zero out)。若遺失與用戶端的通訊或是在合理時間內未關閉檔案，則檔案會被刪除且已組構區塊會被釋放。
先前的實施例強調藉由讓系統選擇其名稱用戶端需要執行新增新的小檔案的呼叫順序。在此例子中，無法立即新增檔案，因為名稱係束縛於其尺寸且伺服器需要在組構必要空間之前接收所有資料為可用之指示，將資料提交至磁碟並且回傳檔案名稱。在來自fcntl()引用的回傳中(範例中的敘述5)係將檔案名稱回傳至關閉檔案的用戶端並且使其內容為可用的。
值得注意的是，在將空間組構給SFR中的檔案時係設想各種策略。其中一種可能性為從重新啟動的第一時間，用戶端以完全隨機的方式引用可用同級組之間的目標同級組。若同級組因為其PSR中的可用空間不夠而無法同意請求，則用戶端轉往對具有ID大1(對同級組數量進行模數操作)的同級組重複其請求，直到可取得適當的PSR為止。每個用戶端持續追蹤處理最後新增請求的最後同級組(不包含明確指定檔案名稱的同級組)，因此接下來的請求係根據與用來重申失敗新增請求相同的機制來選擇目標。這允許以隨機的方式來分配檔案。
另一種可能性為用戶端持續追蹤具有較大未使用容量的PSR以及將下一請求指向列表中的第一者，若請求被拒絕則只向下一者，依此類推。
5.2.5刪除檔案
檔案刪除請求係藉由同級組的主要成員來實現。
刪除小檔案是相當簡單的處理程序。假設發出請求之用戶端的有效身份符合關於刪除操作之即將刪除檔案的存取權限(由於所有的虛擬目錄對所有的使用者提供寫入存取，唯一的區別項目為檔案本身是否可以被呼叫者寫入)，則執行操作並且將相關檔案區塊回傳至自由儲存區。
5.2.6重新命名檔案
不支援包含SFR之檔案重新命名操作。若需要將檔案搬出SFR，則可以將複製檔案並且刪除原始檔案。反之亦然，只要使用用於實施例的方法或是呼叫者選擇對應至相關PSR之自由區域的檔案名稱，則該檔案夠大足以包含將要複製的資料量。然而，這些操作不是由SFR基礎結構來執行且應用程式必須明確地執行這些步驟。
5.2.7開啟檔案
檔案總是藉由名稱來開啟。為了讓SFR實現預期的效能，開啟與讀取操作係執行為單一動作。其他開啟模式係有關於讀取-寫入、寫入、新增、截斷與附加模式。
新增模式被視為新增請求(如該)。小檔案不支援截斷與附加模式(藉由維持組構給檔案的區塊以及降低其在檔案元資料中的長度可支援截斷模式)。
對唯讀、讀取-寫入以及寫入模式來說，PSR服務表現如下。若檔案名稱存在則開啟是成功的，且存取權限係符合讀取請求。然而，為了將I/O操作數量降低至1，則目標PSR服務(緩存其管理之PSR的位元映象)繼續進行如下：
1.從位元映象可驗證對應至該名稱的檔案存在，開始於指定區塊偏移，並且具有指定長度(起初忽略後置)。
2.接下來，從磁碟執行必要的單一I/O操作將連續檔案區塊讀入適當長度的緩衝器。
3.接下來，檢查請求者本身的檔案存取位元。若請求是不相容的，則丟棄讀入的資料且請求者接收否定確認信號。
4.接下來，檢查對應至請求中一項指定的後置(若有的話)。若不符合，則丟棄讀入的資料且請求者接收否定確認信號。
此處情況係根據開啟狀態而有所不同。
1.若在讀取-寫入或寫入模式中開啟檔案，則同級組的主要成員需要協調請求。
2.若在唯讀或讀取-寫入模式中開啟檔案，若所有該皆成功，則PSR服務將資料回傳至具有該請求之肯定確認信號的用戶端。用戶端緩存資料使得從緩存資料可滿足隨後對檔案的讀取請求。
3.若在唯寫模式中開啟檔案，則資料不會被回傳至用戶端，而PSR服務將其保存在記憶體中，使得隨後的讀取請求可以在寫入檔案之前與現存檔案資料合併。
4.若請求O_SYNC模式，則會影響寫入操作的行為(參考下文)。
5.2.8讀取檔案
檔案讀取操作是可能的並且期望在以讀取-寫入模式開啟檔案時使用。以讀取模式開啟檔案會導致小檔案資料被回傳至具有開啟確認訊息之請求用戶端。因此，理論上應很少使用單獨的讀取操作。然而，SFR服務以其為榮。
5.2.9寫入檔案
檔案寫入操作係藉由同級組的主要成員來協調，因為在確認訊息回傳至請求用戶端之前必須確認同級組的其他成員是同步的。
寫入操作係受限於檔案名稱中所指定檔案的長度。只要對檔案的寫入操作不超過檔案的最後區塊，則實際上在任何時後的寫入可以超過檔案長度。
若在開啟請求中設定O_SYNC旗標，則當接收資料時所有的寫入係提交至磁碟，並且只有當資料位於穩定儲存器時將確認訊息回傳至用戶端。若未設定該旗標，則當同級組成員接收將被寫入的資料時向用戶端確認請求，並且協調者知道此。
5.2.10同步檔案
必須藉由同級組的主要成員來協調此基數。確認緩存於特定檔案之伺服器中的所有資料被寫出，且只有當同級組的所有成員將資料緩存於穩定儲存器時會回送確認訊息。
5.2.11關閉檔案
檔案關閉不具有將檔案在讀取模式中開啟的實際效果。然而，在檔案以包含寫入模式的方法開啟的例子中，會導致任何資料緩存在屬於排程將被驅趕出之特定檔案的伺服器中。對用戶端的確認訊息係與有關刷新的資料不同步。然而，若在開啟請求中設定O_SYNC旗標，則確認訊息係與關閉檔案同步，即使是因為旗標，資料必須已到達穩定儲存器。
6. SFR的備份與還原
此章節提供如何備份儲存於SFR內的檔案並將其還原至MaxiFS平台或是其他系統的細節。
期望執行備份與還原SFR不需要特別的公用程式。目的為客戶應可以使用任可用的何公用程式而不需要適應對等模式程式。
基於以下理由這是有可能的。SFR被認為是基礎結構MaxiFS名稱空間的組成部分。因此，不論備份公用程式是否以名稱空間的SFR部分、其中一個子目錄或是全MaxiFS名稱空間為目標，遍歷全名稱空間以及讀取與寫入SFR中檔案的能力是設計的一部份。
儲存於SFR中的檔案名稱是人為且隱密的。然而，由於該名稱符合使用於標準Unix檔案系統中的名稱，因此可以將全SFR階層複製至大到足以包含其的其他檔案系統。
將其他類型的階層還原至SFR是不可能的，除非所使用的名稱、檔案與目錄與SFR中所使用的相容，且名稱映射至位置以及存在於目標SFR名稱空間中的同級組。
若目標SFR可用的同級組數量不小於備份SFR之同級組的數量且用於目標SFR之驅動裝置容量的尺寸不小於來源SFR的尺寸，則將備份還原至現存SFR是可行的。這是可能的，因為具有適當的權限，任何公用程式皆可覆寫SFR中的現存檔案。然而，最佳的作法為在以備份內容覆寫之前抹去SFR或是被還原之子集合的內容。
7. SFR的同級組回復與遠端複製
在一般的例子中，同級組具有三個主動成員。在一般系統操作期間，一些節點可能變為不可用且可能必須被其他節點取代。對了正常運作，假設如下：
必須將實現一般MaxiFS名稱空間階層的元資料複製至同級組的新成員，因此可完全與其他成員同步。只要新同級組成員中的可用空間允許複製此階層，則這是個不代表對檔案系統與實現這種元資料階層之容量的任何特定限制的邏輯操作。
由於同級組成員具有與其PSR相同的副本，因此必須確認進入該同級組的新成員更新官於其PSR的副本。如該，新成員無法具有不夠大到足以包含使用具有最高數量之區塊之檔案的PSR容量。
假設符合新同級組成員的尺寸需求，則同步同級組新成員最快的方法為提供與PSR服務結合之容量複製設備。以下是這所需要的。當需要更新PSR時，來源PSR初始對目標同級組成員的容量複製。一旦同級組的至少兩個成員完全運作，則PSR中的更新操作可正常進行。只有同步中的成員可支援唯讀操作。每當請求由同級組主要成員所協調之新的更新操作時，被更新的成員應副本達到的磁碟偏移。關於已經執行更新之部分容量的任何操作可根據所請求的新操作來進行更新。不需要更新超出複製範圍者，因為當複製容量的該區段時將會對其進行更新。
容量複製設備可藉由複製個別容量來更新基礎結構的遠端複製。
VI.結論
該的所有參考在此係與實體中的參考結合。
儘管在關於第4B圖的實施例中顯示單一用戶端，可以瞭解的是儲存系統可包含多個用戶端，每個用戶端皆具有透過網路與FS伺服器元件通訊之FS用戶端元件。每個FS用戶端係獨立操作來服務來自其個別用戶端裝置中檔案系統所接收的請求。
在該實施例中，FS用戶端與FS伺服器元件為分別安裝在用戶端與儲存提供者中的額外元件。值得注意的是，一些或所有的FS用戶端的功能性可與檔案系統414或是其他用戶端元件(例如用戶端作業系統)結合，且一些或所有的FS伺服器的功能性可整合於儲存處理器或其他儲存提供者元件內(例如儲存提供者作業系統)。因此，例如，本發明實施例可包含具有整合FS用戶端功能性的檔案系統，具有整合FS伺服器功能性的儲存處理器，以及具有整合FS用戶端以及/或DS伺服器功能性的作業系統。
值得注意的是，由於FS用戶端元件與FS伺服器元件彼此通訊，因此通訊不需要遵守標準網路檔案協定，例如NFS或CIFS。在標準實施例中，這樣的通訊係使用允許交換儲存管理資訊的專用協定，例如檔案在儲存系統內的位置，儲存系統內的檔案移動，儲存系統內的檔案複製(例如為了冗餘性或是負載平衡)，以及藉由各種儲存提供者所執行的任務等等。專用協定係提供FS用戶端與FS伺服器之間(例如，用來滿足應用程式的請求)以及FS伺服器之間(例如，用來管理儲存以及回報統計資料)的通訊。
值得注意的是，因為FS用戶端與FS伺服器根據散列機制解析路徑名稱，儲存系統不需要個別的元資料伺服器來解譯路徑名稱。
值得注意的是，當多個實例檔案儲存在不同的儲存提供者中時(例如為了負載平衡)，而不是目標儲存提供者將具有檔案副本之儲存提供者清單回傳至用戶端，並允許每個用戶端選取儲存提供者之一者(例如隨機或透過政策導向機制)，目標儲存提供者可將儲存提供者之不同者回傳至不同的用戶端，因此每個用戶端係透過不同的儲存提供者來存取檔案。
值得注意的是，此處所使用例如”用戶端”與”伺服器”的術語是用來說明可能用於通訊系統的各種通訊裝置，然其並非用以將本發明限定為任何特定的通訊裝置類型。因此，通訊裝置可包含橋接器、路由器、橋式路由器(cridge-router,brouter)、切換器、節點、用戶端、伺服器、電腦或其他通訊裝置，然其並非用來限定本發明的範圍。
值得注意的是，此處所使用的術語”封包”是用來說明可由通訊裝置所使用或是由通訊媒體來傳遞的通訊訊息(例如藉由通訊裝置所進行之新增、傳送、接收儲存)，然其並非將本發明限定為任何特定的通訊訊息類型、通訊訊息格式或是通訊協定。因此，通訊訊息可包含資料框、封包、資料包、使用者資料包、單元或其他類型的通訊訊息，然其並非用來限定本發明的範圍。
值得注意的是，此處所使用的邏輯流程圖示用來說明本發明的各層面，然其並非用來將本發明實施例限制為任何特定的邏輯流程或邏輯實現。該邏輯可以在不改變整體結果的情況下分為不同的邏輯區塊(例如程式、模組、功能或子程式)，否則會脫離本發明的真正範圍。很多時候，可以在不改變整體結果的情況下增加、修改、省略、以不同順序執行或使用不同的邏輯結構來實現(例如，邏輯閘、循環基數、條件邏輯以及其他邏輯結構)，否則會脫離本發明的真正範圍。
本發明可具體表現於許多不同的形式中，包含與處理器一同使用的電腦程式邏輯(例如微處理器、為控制器、數位信號處理器或通用電腦)、與可編程邏輯裝置共同使用的可編程邏輯(例如現場可編程閘陣列(Field Programmable Gate Array,FPGA)或其他PLD)，離散元件、整合電路(例如專用集成電路(Application Specific Integrated Circuit,ASIC))或包含任何組合之任何其他裝置。在本發明一般實施例中，FS用戶端與FS伺服器元件係實現於轉換為電腦可執行形式的軟體中，儲存為電腦可讀取媒體，並且由受到作業系統控制之微處理器來執行。
此處說明之實現所有或部分該功能性的電腦程式邏輯可具體表現於各種形式中，包含原始碼形式、電腦可執行形式以及各種中間形式(例如由所組合語言、編譯器、連結器或定位器所產生的形式)。原始碼可包含以各種程式語言之任一者(例如電腦語言、組合語言或高階語言，例如Fortran、C、C++、JAVA或HTML)所實現適用於與各種作業系統或操作環境的一連串腦程式指令。原始碼可定義並使用各種資料結構與通訊訊息。原始碼可以微電腦可執行形式(例如透過解譯器)，或是原始碼可以(藉由轉譯器(translateor)、組譯器(assembler)或邊譯器)轉換為電腦可執行形式。
電腦程式可固定為實際儲存媒體中(例如半導體記憶裝置(例如RAM、ROM、PROM、EEPROM或閃存可編程RAM)、磁性記憶裝置(例如磁盤(diskette)或固定式磁盤)、光學記憶裝置(例如CD-ROM)、PC卡(例如PCMCIA卡)或是其他記憶裝置)的任何形式(例如原始碼形式、電腦可執行形式或是中間形式)。可以將電腦程式分配為任何形式，如同伴隨印刷或電子文件的可移除式儲存媒體(例如現成套裝軟體)，預載電腦系統(例如在系統ROM或固定式磁盤上)，或是透過通訊系統來分配伺服器或電子佈告欄(例如網際網路或全球資訊網)。
此處之前說明用來實現所有或部分功能性的硬體邏輯(包含用於可編程邏輯裝置之可編程邏輯)可使用傳統手動方法來設計，或是可使用各種工具(例如電腦輔助設計(Computer Aided Design,CAD)、硬體描述語言(例如VHDL或AHDL)或PLD程式語言(例如PALASM、ABEL或CUPL))來設計、擷取、模擬或將文件電子化。
可編程邏輯可永久或暫時的固定於實際儲存媒體中，例如半導體記憶裝置(例如RAM、ROM、PROM、EEPROM或閃存可編程RAM)、磁性記憶裝置(例如磁盤或固定式磁盤)、光學記憶裝置(例如CD-ROM)或是其他記憶裝置。可編程邏輯可固定為可使用各種通訊技術(包含類比技術、數位技術、光學計數、無線技術(例如藍芽)、網路技術以及互聯網技術)之任一者傳送至電腦的信號，然其並非用來限定本發明。可以將可編程邏輯分配為具有印刷或墊子文件的可移除式儲存媒體(例如現成套裝軟體)、預載電腦系統(例如在系統ROM或固定式磁盤上)或是透過通訊來分配伺服器與電子佈告欄(例如網際網路或全球資訊網)。
本發明雖以較佳實施例揭露如上，然其並非用以限定本發明的範圍，任何熟習此項技藝者，在不脫離本發明之精神和範圍內，當可做些許的更動與潤飾，因此本發明之保護範圍當視後附之申請專利範圍所界定者為準。
110．．．根目錄
120．．．目錄
122．．．目錄
124．．．檔案
130．．．檔案
132．．．檔案
140．．．目錄
150．．．檔案
210．．．NTFS檔案系統
212．．．開啟功能
214．．．關閉功能
216．．．讀取功能
218．．．寫入功能
220．．．硬碟
230．．．CIFS檔案系統
232．．．開啟功能
234．．．關閉功能
236．．．讀取功能
238．．．寫入功能
240．．．網路
250．．．檔案伺服器
260．．．硬碟
310．．．根檔案系統
320．．．根目錄
330．．．目錄A
331．．．檔案
332．．．目錄B
334．．．目錄C
336．．．目錄D
338．．．檔案
340．．．已安裝檔案系統
350．．．根目錄
360．．．目錄
362．．．目錄
370．．．檔案
372．．．檔案
382．．．硬碟
392．．．區域網路
394．．．電腦
396．．．硬碟
410．．．用戶端
412．．．應用程式
414．．．檔案系統
415．．．FS用戶端
420．．．網路
430．．．儲存提供者
431．．．FS伺服器
432．．．儲存處理器
434．．．儲存器
440．．．儲存提供者
441．．．FS伺服器
442．．．儲存處理器
444．．．儲存器
450．．．儲存提供者
451．．．FS伺服器
452．．．儲存處理器
454．．．儲存器
510．．．儲存伺服器
520．．．微處理器
530．．．隨機存取記憶體
540．．．硬碟1
542．．．硬碟2
544．．．硬碟3
546．．．硬碟4
550．．．網路介面卡1
552．．．網路介面卡2
610．．．用戶端伺服器
620．．．交換器1
622．．．交換器2
630．．．儲存伺服器1
640．．．儲存伺服器2
650．．．儲存伺服器3
810．．．檔案路徑
812．．．根目錄
814．．．第一層目錄
816．．．第二層目錄
818．．．檔案葉
820．．．散列函式
830．．．十六進位值
832．．．十六進位值
840．．．位元遮罩
850、852．．．遮罩結果
910、920、930．．．表格
940、942、952、953、954、955．．．表格項目
1010．．．儲存元資料檔案
1012．．．檔案名稱
1014、1016、1018、1020．．．項目
1110．．．伺服器1
1112．．．伺服器8
1114．．．伺服器6
1120、1122、1124、1126、1132、1134．．．儲存媒體
1130、1130A、1130B．．．同級組
1210．．．同級組
1220、1230、1240．．．伺服器
1222、1232．．．次要節點
1242．．．主要節點
1310．．．節點
1320、1330．．．目錄樹
1322．．．根目錄
1324．．．目錄
1326．．．檔案
1334、1336、1338、1340．．．目錄
1350．．．檔案
1410．．．佇列
1412、1414．．．箭頭
1420．．．第一記錄
1422．．．租賃
1424．．．伺服器
1430．．．第二記錄
1440．．．第三記錄
1444、1610、1710．．．伺服器
1510、1512．．．初始化
1514、1526．．．加入同級組
1516．．．開始檔案系統服務
1520．．．系統故障
1522．．．取得增加新節點的權限
1524．．．傳送”加入”訊息
1528．．．傳送任務
1529．．．加入佇列
1530、1540．．．通知
1532．．．查詢
1534．．．租賃任務
1536．．．複製資料
1538．．．完成
1539．．．離開佇列
1542．．．傳送”啟動”訊息
1544．．．繼續服務
1546．．．開始服務
第1圖顯示傳統技術中的檔案系統目錄樹。
第2圖顯示可能對設置於檔案系統目錄樹內之檔案所執行之各種操作的方塊圖。
第3圖顯示包含於檔案安裝操作中兩個檔案系統目錄之間的關係。
第4A圖顯示傳統技術中範例用戶端/伺服器系統之相關元件的方塊圖，具有用戶端與多個儲存提供者，儲存提供者係透過例如LAN或WAN的網路(例如網際網路)與用戶端進行通訊。
第4B圖顯示本發明實施例之用戶端/伺服器系統之相關元件的方塊圖。
第5圖顯示本發明實施例之儲存伺服器之相關元件的方塊圖。
第6圖顯示第4B圖之儲存裝置可能的實體佈局。
第7圖顯示本發明實施例之處理用戶端檔案之邏輯元件之間相關互動的方塊圖。
第8圖顯示本發明實施例將檔案路徑轉換為表索引來判斷儲存提供者的處理程序之概念表示法。
第9圖顯示擴充控制檔案元資料之儲存提供者表格的處理程序，藉由在第8圖之處理程序中新增的表索引來邊索引。
第10圖顯示儲存元資料檔案內容的表示法。
第11圖顯示本發明實施例之同級組之邏輯元件的示意圖。
第12圖顯示本發明實施例之用戶端與同級組之間藉由使用第4圖之電腦網路進行通訊。
第13圖顯示根據本發明實施例之儲存伺服器內節點中的資料儲存區域與元資料儲存區域。
第14圖顯示本發明實施例之包含佇列以及與佇列通訊之元件的方塊圖。
第15圖顯示本發明實施例在修復遺失第二節點期間，在同級組與非同步佇列之間所傳遞訊息之相關動作的時序圖。
第16A圖顯示在第二儲存節點故障期間第11圖之同級組的示意圖。
第16B圖顯示在藉由第15圖的處理程序將同級組復原之後第11圖之同級組的示意圖。
第17A圖顯示在主要儲存節點故障期間第11圖之同級組的示意圖。
第17B圖顯示在同級組復原之後第11圖之同級組的示意圖。
第18圖顯示本發明實施例之兩個用戶端與兩個伺服器之範例名稱空間的示意圖。
第19圖顯示本發明實施例之用戶端將輸出目錄安裝至其個別名稱空間的示意圖。
第20圖顯示本發明實施例之範例階層式名稱空間的示意圖。
第21圖顯示本發明實施例使用散列方法實現第20圖知名稱空間的示意圖。
第22圖顯示本發明實施例在重新命名目錄之後第21圖之名稱空間的示意圖。
第23圖顯示本發明實施例動態擴充散列表的示意圖。
第24圖顯示本發明實施例之小檔案儲存庫的示意圖。
第25圖顯示本發明實施例之節點初始化的狀態轉變圖。
第26圖顯示本發明實施例之成員在管理伺服器聯盟的狀態轉變圖。
第27圖顯示本發明實施例之發現與加入管理伺服器聯盟的狀態轉變圖。
第28圖顯示本發明實施例之藉由根節點合併管理伺服器聯盟的狀態轉變圖。
第29圖顯示本發明實施例在管理伺服器聯盟中基於租賃故障偵測的示意圖。
第30圖顯示本發明實施例加入同級組的狀態轉變圖。
第31圖顯示本發明實施例之同級組協定之相關元件的邏輯流程圖。
410．．．用戶端
412．．．應用程式
414．．．檔案系統
415．．．FS用戶端
420．．．網路
430、440、450．．．儲存提供者
431、441、451．．．FS伺服器
432、442、452．．．儲存處理器
434、444、454．．．儲存器

Claims (44)

  1. 一種檔案儲存系統，用來處理包含一路徑名稱之一標準檔案系統請求，該系統包含：複數個儲存提供者；一用戶端，與該儲存提供者進行通訊，其接受該檔案系統請求並產生一對應的再格式化請求至該等儲存提供者其中已選取之一者，該用戶端係根據應用至該路徑名稱之至少一部分的一散列演算法來初始地選取該等儲存提供者其中已選取之一者，使得該用戶端係作為該標準檔案系統請求與該等儲存提供者之間的一介面，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組同級節點之複數個同級間電腦處理程序。
  2. 如申請專利範圍第1項之檔案儲存系統，其中指向一特定虛擬伺服器的一特定請求係遞送至該虛擬伺服器的所有同級組節點，然而該同級組係經組構以使得只有該等同級節點之其中一者回應該特定請求。
  3. 如申請專利範圍第1項之檔案儲存系統，其中該等同級節點的每一者係實現為耦接至一不同微處理器之一不同實體儲存媒體。
  4. 如申請專利範圍第3項之檔案儲存系統，更包含複數個實體儲存伺服器，每個實體儲存伺服器包含複數個實體儲存媒體以及一微處理器，其中每個虛擬伺服器係與一不同儲存伺服器被組構，而與該同級組之每個節點相關。
  5. 一種將一特定檔案設置於具有至少一儲存提供者之一檔 案儲存系統中之方法，關聯於一檔案路徑名稱的該特定檔案包含一系列的目錄名稱以及一檔案名稱，該方法包含：在一電腦處理程序中，應用一散列演算法至該等目錄名稱中所選擇之一者以取得一索引編號，其中該散列演算法的特性為不同的目錄名稱具有不同的索引編號；辨識關聯於該已取得索引編號之一已選取儲存提供者；以及接觸該已選取儲存提供者編號來取得該已選取儲存提供者所維持關於該檔案儲存系統內該特定檔案的位置之資訊，由於不論該特定檔案是藉由該已選取儲存提供者及/或藉由至少一其他儲存提供者所儲存，皆可以設置該特定檔案，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組同級節點之複數個同級間電腦處理程序。
  6. 如申請專利範圍第5項之方法，其中該已選取目錄名稱為該檔案名稱的一父目錄。
  7. 如申請專利範圍第5項之方法，其中該散列演算法係取得從零至一已選取基底整數之整數乘冪的一數目，但不包含該數目，使得該數目係大於或等於該檔案儲存系統中檔案伺服器的數量，且該數量除以該基底整數係小於該檔案儲存系統中檔案伺服器的數量。
  8. 如申請專利範圍第7項之方法，其中該已選取基底整數為二。
  9. 如申請專利範圍第5項之方法，更包含：改變該檔案儲存系統內該特定檔案的位置；以及更新藉由該已選取儲存提供者所維持的資訊來反應已改變的位置。
  10. 如申請專利範圍第5項之方法，其中該特定檔案的多個實例係儲存於該檔案儲存系統中，且其中藉由該已選取儲存提供者所維持的該資訊係辨識該等實例的位置。
  11. 如申請專利範圍第5項之方法，其中辨識關聯於該已取得索引編號之該已選取儲存提供者包含：使用該已取得索引編號對儲存提供者之表格編索引。
  12. 一種由一用戶端提供對一儲存系統中的一檔案進行存取之方法，該檔案係關聯於一檔案路徑名稱，該方法包含：將該檔案之一實例儲存在每個複數個儲存提供者中，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組同級節點之複數個同級間電腦處理程序；將該檔案的元資料儲存在一目標儲存提供者，該目標儲存提供者係使用一預定映射機制且至少部份根據該路徑名稱來選擇，該元資料至少包含一儲存提供者列表；藉由該用戶端將一請求傳送至該目標儲存提供者；藉由該目標儲存提供者將該儲存提供者列表提供至該用戶端來回應該請求；藉由該用戶端使用一預定選擇機制選擇所列出的該儲存提供者之一者；以及藉由該用戶端與該已選取儲存提供者進行通訊來存取儲 存在該已選取儲存提供者中的該檔案實例。
  13. 如申請專利範圍第12項之方法，其中該預定映射機制包含應用至部分該路徑名稱的一散列演算法。
  14. 如申請專利範圍第12項之方法，其中該預定選擇機制包含從所列出的該等儲存提供者之間隨機選取。
  15. 如申請專利範圍第12項之方法，其中該預定選擇機制包含一使用者可組構的策略。
  16. 如申請專利範圍第12項之方法，其中該目標儲存提供者是儲存該檔案之一實例的該複數個儲存提供者之其中一者。
  17. 如申請專利範圍第12項之方法，其中該目標儲存提供者不是儲存該檔案之一實例的該複數個儲存提供者之其中一者。
  18. 如申請專利範圍第12項之方法，其中該元資料更包含該路徑名稱、部分該路徑名稱、以及一檔案版本編號之至少一者。
  19. 如申請專利範圍第12項之方法，其中該檔案之一實例係儲存在每個複數個儲存提供者中，來提供冗餘性。
  20. 如申請專利範圍第12項之方法，其中該檔案之一實例係儲存在每個複數個儲存提供者中，以將處理負載分配至該等複數個儲存提供者。
  21. 一種儲存系統，包含：一用戶端；以及一儲存提供者，透過一通訊網路與該用戶端進行通 訊，該儲存提供者包含複數個節點，每個儲存節點係由一不同的儲存伺服器管理，其中該等複數個儲存節點係關聯於一多播位址，且複數個請求係使用該多播位址被傳送至該儲存提供者，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組儲存節點之複數個同級間電腦處理程序。
  22. 一種儲存系統，包含：一用戶端；一儲存提供者，透過一通訊網路與該用戶端進行通訊，該儲存提供者包含複數個儲存節點以及一分配佇列機制，其允許該等儲存節點之一或多者對待被佇列的複數個任務進行處理，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組儲存節點之複數個同級間電腦處理程序。
  23. 如申請專利範圍第22項之儲存系統，其中每個儲存節點係由一不同的儲存伺服器管理。
  24. 如申請專利範圍第23項之儲存系統，其中該等儲存節點係關聯於一多播位址，且使用該多播位址來佇列任務。
  25. 如申請專利範圍第22項之儲存系統，其中該等儲存節點之其中一者被指派於任何特定時間處理已佇列任務。
  26. 如申請專利範圍第22項之儲存系統，其中該等儲存節點被指派不同的角色來管理已佇列任務的處理，該角色預設至少包含一主要節點來管理已佇列任務的處理，以及一次要節點在該主要節點無法運作時管理已佇列任務的 處理。
  27. 如申請專利範圍第26項之儲存系統，其中該等角色被指派使用指定顏色。
  28. 一種儲存系統，包含：一用戶端；以及一儲存提供者，透過一通訊網路與該用戶端進行通訊，該儲存提供者包含複數個儲存節點，其中該等儲存節點之其中一者被指派作為該複數個節點之一代理主機，用來管理該複數個節點之間的資料儲存，並且代表該其他儲存節點與該用戶端互動，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組儲存節點之複數個同級間電腦處理程序。
  29. 如申請專利範圍第28項之儲存系統，其中每個儲存節點係由一不同的儲存伺服器來管理。
  30. 如申請專利範圍第29項之儲存系統，其中該等儲存節點係關聯於一多播位址，且其中該用戶端係使用該多播位址與該儲存系統進行通訊。
  31. 如申請專利範圍第28項之儲存系統，其中該等儲存節點被指配不同的角色，該等角色至少包含一主要節點作為該代理主機，以及一次要節點在該主要節點於法運作時作為該代理主機。
  32. 如申請專利範圍第31項之儲存系統，其中該等角色被指派使用指定顏色。
  33. 一種儲存系統，包含複數個儲存提供者，用來分配關聯 於一檔案系統的檔案之儲存，其中每個儲存提供者係維持關於其儲存之檔案的統計資料，且其中，一指定儲存提供者係蒐集該統計資料來進行處理，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組儲存節點之複數個同級間電腦處理程序。
  34. 如申請專利範圍第33項之儲存系統，其中該統計資料包含檔案存取頻率。
  35. 一種將處理負載分配至複數個儲存提供者之方法，該方法包含：判斷期望存取由一特定儲存提供者所儲存之一檔案的多個用戶端，其中每個儲存提供者係為一虛擬伺服器，該虛擬伺服器包含形成一組儲存節點之複數個同級間電腦處理程序；複製至少一額外儲存提供者中的該檔案，使得每個儲存提供者，包含該特定儲存提供者，儲存該檔案之一實例；以及允許用戶端存取該檔案的任何實例，以將處理負載分配至該儲存提供者。
  36. 如申請專利範圍第35項之方法，其中允許用戶端存取該檔案之任何實例包含：將該等儲存提供者之一列表提供至每個該等用戶端；以及允許每個用戶端選擇該等儲存提供者之其中一者，以經由該儲存提供者存取該檔案。
  37. 如申請專利範圍第35項之方法，其中允許用戶端存取該檔案之任何實例包含：對每個該等用戶端指定不同的儲存提供者。
  38. 一種用來維持一電腦檔案儲存系統之同級組節點的方法，該方法包含：根據一節點選擇演算法辨識關聯於一目前同級組的等待節點，該節點選擇演算法在一第一電腦處理程序中的一根節點處產生該等目前同級組節點之一更新列表，其中該目前同級組為複數個儲存提供者中一儲存提供者之一部分，該等儲存提供者係為虛擬伺服器，每個虛擬伺服器包含形成一同級組之複數個同級間電腦處理程序；以及在一第二電腦處理程序中，在該等已辨識節點之間進行對話，該對話在該等節點之間建立一階層以及角色分配。
  39. 如申請專利範圍第38項之方法，其中辨識關聯於該等目前同級組節點之該等待節點包含：藉由一等待節點從該根節點接收包含關聯於該目前同級組之等待節點之描述符的一訊息。
  40. 如申請專利範圍第38項之方法，其中進行對話包含：每個節點邀請者將邀請函傳送至節點受邀者，每個邀請函觸發一節點受邀者藉由傳送確認訊息至一對應節點邀請者來做回應；至少一節點邀請者接收至少一確認訊息，其中一節 點邀請者與一節點受邀者皆為辨識為關聯於該目前同級組的等待節點。
  41. 如申請專利範圍第40項之方法，其中若每個節點邀請者接收來自每個節點受邀者的確認訊息，則該對話指標為正，否則該對話指標為負。
  42. 如申請專利範圍第41項之方法，更包含：在一第三電腦處理程序中，若該對話成功指標為負，則分派用於該目前同級組之替代節點。
  43. 如申請專利範圍第40項之方法，其中進行對話更包含：將每個節點邀請者所接收來自該根節點的訊息傳遞至每個節點受邀者。
  44. 如申請專利範圍第40項之方法，其中進行對話更包含：藉由至少一節點邀請者傳遞等待被該節點受邀者接收之訊息，該訊息包含關聯於該目前同級組及由來自該根節點之至少一節點邀請者所接收之等待節點的描述符。
TW098113958A 2008-04-29 2009-04-28 同級間冗餘檔案伺服器系統及方法 TWI476610B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US4878108P 2008-04-29 2008-04-29
US11195808P 2008-11-06 2008-11-06

Publications (2)

Publication Number Publication Date
TW201007489A TW201007489A (en) 2010-02-16
TWI476610B true TWI476610B (zh) 2015-03-11

Family

ID=41216019

Family Applications (1)

Application Number Title Priority Date Filing Date
TW098113958A TWI476610B (zh) 2008-04-29 2009-04-28 同級間冗餘檔案伺服器系統及方法

Country Status (3)

Country Link
US (11) US8296398B2 (zh)
TW (1) TWI476610B (zh)
WO (1) WO2009134772A2 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI688869B (zh) * 2015-05-27 2020-03-21 香港商阿里巴巴集團服務有限公司 資料即時傳輸的方法和裝置
TWI747349B (zh) * 2020-06-30 2021-11-21 大陸商合肥沛睿微電子股份有限公司 儲存裝置之低級格式化方法
TWI755417B (zh) * 2016-10-18 2022-02-21 香港商阿里巴巴集團服務有限公司 計算任務分配方法、流計算任務的執行方法、控制伺服器、流計算中心伺服器集群、流計算系統及異地多活系統
TWI820814B (zh) * 2022-07-22 2023-11-01 威聯通科技股份有限公司 儲存系統與其硬碟恢復方法
TWI860122B (zh) * 2023-10-12 2024-10-21 技嘉科技股份有限公司 編號式檔案的資料結構、交握方法及交握系統

Families Citing this family (520)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711847B2 (en) 2002-04-26 2010-05-04 Sony Computer Entertainment America Inc. Managing users in a multi-user network game environment
US20030217135A1 (en) 2002-05-17 2003-11-20 Masayuki Chatani Dynamic player management
US8131802B2 (en) 2007-10-05 2012-03-06 Sony Computer Entertainment America Llc Systems and methods for seamless host migration
US8560707B2 (en) * 2007-10-05 2013-10-15 Sony Computer Entertainment America Llc Seamless host migration based on NAT type
US7827214B1 (en) 2003-02-14 2010-11-02 Google Inc. Maintaining data in a file system
US20070164842A1 (en) * 2006-01-19 2007-07-19 Lumera Corporation Electro-Optic Radiometer to Detect Radiation
US8175248B2 (en) * 2007-01-29 2012-05-08 Nuance Communications, Inc. Method and an apparatus to disambiguate requests
TWI476610B (zh) * 2008-04-29 2015-03-11 Maxiscale Inc 同級間冗餘檔案伺服器系統及方法
US8943271B2 (en) * 2008-06-12 2015-01-27 Microsoft Corporation Distributed cache arrangement
CN101610210A (zh) * 2008-06-18 2009-12-23 鸿富锦精密工业（深圳）有限公司 具有冗余结构的组播传输系统及方法
US8015343B2 (en) * 2008-08-08 2011-09-06 Amazon Technologies, Inc. Providing executing programs with reliable access to non-local block data storage
US8285719B1 (en) 2008-08-08 2012-10-09 The Research Foundation Of State University Of New York System and method for probabilistic relational clustering
US8019732B2 (en) 2008-08-08 2011-09-13 Amazon Technologies, Inc. Managing access of multiple executing programs to non-local block data storage
CN102177508B (zh) * 2008-08-08 2015-08-05 亚马逊技术有限公司 向执行中的程序提供对非本地块数据存储装置的可靠访问
US9098519B2 (en) * 2008-09-16 2015-08-04 File System Labs Llc Methods and apparatus for distributed data storage
US8386443B2 (en) * 2008-10-06 2013-02-26 Dell Products L.P. Representing and storing an optimized file system using a system of symlinks, hardlinks and file archives
SE533007C2 (sv) 2008-10-24 2010-06-08 Ilt Productions Ab Distribuerad datalagring
US8151062B2 (en) * 2008-10-26 2012-04-03 Microsoft Corporation Consistency models in a distributed store
US8880473B1 (en) 2008-12-15 2014-11-04 Open Invention Network, Llc Method and system for providing storage checkpointing to a group of independent computer applications
US8185566B2 (en) 2009-01-15 2012-05-22 Microsoft Corporation Client-based caching of remote files
US9268779B2 (en) * 2009-01-28 2016-02-23 Mckesson Financial Holdings Methods, computer program products, and apparatuses for dispersing content items
US8301654B2 (en) * 2009-02-24 2012-10-30 Hitachi, Ltd. Geographical distributed storage system based on hierarchical peer to peer architecture
US8489633B2 (en) * 2009-03-06 2013-07-16 Hewlett-Packard Development Company, L.P. Correlated query process (CQP) and peer-to-peer (P2P) execution
US20100241731A1 (en) * 2009-03-17 2010-09-23 Gladinet, Inc. Method for virtualizing internet resources as a virtual computer
US20100262797A1 (en) * 2009-04-10 2010-10-14 PHD Virtual Technologies Virtual machine data backup
US20100299362A1 (en) * 2009-05-24 2010-11-25 Roger Frederick Osmond Method for controlling access to data containers in a computer system
US8793257B2 (en) * 2009-05-24 2014-07-29 Roger Frederick Osmond Method for improving the effectiveness of hash-based data structures
US9015198B2 (en) * 2009-05-26 2015-04-21 Pi-Coral, Inc. Method and apparatus for large scale data storage
US20100306236A1 (en) * 2009-05-29 2010-12-02 Sun Microsystems, Inc. Data Policy Management System and Method for Managing Data
KR101078288B1 (ko) * 2009-08-21 2011-10-31 한국전자통신연구원 증거 수집 방법 및 장치
US8489654B2 (en) * 2009-08-28 2013-07-16 Beijing Innovation Works Technology Company Limited Method and system for forming a virtual file system at a computing device
US8370307B2 (en) * 2009-09-01 2013-02-05 Empire Technology Development Llc Cloud data backup storage manager
US8495044B2 (en) * 2009-09-02 2013-07-23 Microsoft Corporation File system node updates
US9306803B2 (en) * 2009-10-30 2016-04-05 Hewlett Packard Enterprise Development Lp Methods and devices for implementing configuration synchronization
US8380678B2 (en) * 2009-11-24 2013-02-19 Symantec Corporation Tracking files which have been processed by a backup or a restore operation
WO2011065570A1 (ja) * 2009-11-30 2011-06-03 Ｊｖｃ・ケンウッド・ホールディングス株式会社 情報表示装置、情報表示方法およびコンピュータプログラム
US9575985B2 (en) * 2009-12-07 2017-02-21 Novell, Inc. Distributed lock administration
US9037620B2 (en) * 2009-12-16 2015-05-19 Microsoft Technology Licensing, Llc File system active symbolic link
DE102010005172B4 (de) * 2010-01-20 2016-01-14 Siemens Aktiengesellschaft Verfahren zum Betreib eines Archivierungssystems für medizinische Bilddatensätze und Archivierungssystem
US8639876B2 (en) * 2010-01-27 2014-01-28 International Business Machines Corporation Extent allocation in thinly provisioned storage environment
US8862617B2 (en) * 2010-02-09 2014-10-14 Google Inc. System and method for replicating objects in a distributed storage system
US9305069B2 (en) * 2010-02-09 2016-04-05 Google Inc. Method and system for uploading data into a distributed storage system
US8874523B2 (en) * 2010-02-09 2014-10-28 Google Inc. Method and system for providing efficient access to a tape storage system
US20110196900A1 (en) * 2010-02-09 2011-08-11 Alexandre Drobychev Storage of Data In A Distributed Storage System
US8341118B2 (en) * 2010-02-09 2012-12-25 Google Inc. Method and system for dynamically replicating data within a distributed storage system
US8615485B2 (en) * 2010-02-09 2013-12-24 Google, Inc. Method and system for managing weakly mutable data in a distributed storage system
US8744997B2 (en) 2010-02-09 2014-06-03 Google Inc. Pruning of blob replicas
US8423517B2 (en) * 2010-02-09 2013-04-16 Google Inc. System and method for determining the age of objects in the presence of unreliable clocks
US8380659B2 (en) 2010-02-09 2013-02-19 Google Inc. Method and system for efficiently replicating data in non-relational databases
US20110208761A1 (en) * 2010-02-24 2011-08-25 Microsoft Corporation Coordinating content from multiple data sources
US8819208B2 (en) * 2010-03-05 2014-08-26 Solidfire, Inc. Data deletion in a distributed data storage system
US8843459B1 (en) * 2010-03-09 2014-09-23 Hitachi Data Systems Engineering UK Limited Multi-tiered filesystem
ES2703767T3 (es) * 2010-03-11 2019-03-12 Rakuten Inc Método de procesamiento de información, dispositivo de procesamiento de información, programa y medio de grabación
US8266176B2 (en) * 2010-03-12 2012-09-11 Hitachi, Ltd. Storage system and file access determination method of the same
US8903906B2 (en) * 2010-03-16 2014-12-02 Brother Kogyo Kabushiki Kaisha Information communications system, node device, method of communicating contents, computer readable recording medium storing a program
US8312237B2 (en) 2010-04-02 2012-11-13 Autonomy, Inc. Automated relocation of in-use multi-site protected data storage
US20110246550A1 (en) * 2010-04-02 2011-10-06 Levari Doron System and method for aggregation of data from a plurality of data sources
US9251214B2 (en) * 2010-04-08 2016-02-02 Microsoft Technology Licensing, Llc In-memory database system
JP5592493B2 (ja) * 2010-04-13 2014-09-17 株式会社日立製作所 ストレージネットワークシステム及びその制御方法
US9813529B2 (en) 2011-04-28 2017-11-07 Microsoft Technology Licensing, Llc Effective circuits in packet-switched networks
US9454441B2 (en) 2010-04-19 2016-09-27 Microsoft Technology Licensing, Llc Data layout for recovery and durability
US8533299B2 (en) 2010-04-19 2013-09-10 Microsoft Corporation Locator table and client library for datacenters
US9170892B2 (en) * 2010-04-19 2015-10-27 Microsoft Technology Licensing, Llc Server failure recovery
US8996611B2 (en) 2011-01-31 2015-03-31 Microsoft Technology Licensing, Llc Parallel serialization of request processing
US8370305B2 (en) * 2010-04-19 2013-02-05 Greenbytes, Inc., A Rhode Island Corporation Method of minimizing the amount of network bandwidth needed to copy data between data deduplication storage systems
EP2712149B1 (en) 2010-04-23 2019-10-30 Compuverde AB Distributed data storage
US8788628B1 (en) * 2011-11-14 2014-07-22 Panzura, Inc. Pre-fetching data for a distributed filesystem
US9852149B1 (en) 2010-05-03 2017-12-26 Panzura, Inc. Transferring and caching a cloud file in a distributed filesystem
US8799414B2 (en) * 2010-05-03 2014-08-05 Panzura, Inc. Archiving data for a distributed filesystem
US9792298B1 (en) 2010-05-03 2017-10-17 Panzura, Inc. Managing metadata and data storage for a cloud controller in a distributed filesystem
US8805967B2 (en) * 2010-05-03 2014-08-12 Panzura, Inc. Providing disaster recovery for a distributed filesystem
US8799413B2 (en) * 2010-05-03 2014-08-05 Panzura, Inc. Distributing data for a distributed filesystem across multiple cloud storage systems
US8805968B2 (en) * 2010-05-03 2014-08-12 Panzura, Inc. Accessing cached data from a peer cloud controller in a distributed filesystem
US9852150B2 (en) 2010-05-03 2017-12-26 Panzura, Inc. Avoiding client timeouts in a distributed filesystem
US9811532B2 (en) 2010-05-03 2017-11-07 Panzura, Inc. Executing a cloud command for a distributed filesystem
US20110283368A1 (en) * 2010-05-11 2011-11-17 Massimiliano Gasparri Identification and end-use differentiation in digital media
US9417969B2 (en) * 2010-05-13 2016-08-16 Sony Corporation Distributed network backup of multimedia files
US8255738B2 (en) 2010-05-18 2012-08-28 International Business Machines Corporation Recovery from medium error on tape on which data and metadata are to be stored by using medium to medium data copy
US9015126B2 (en) * 2010-05-22 2015-04-21 Nokia Corporation Method and apparatus for eventually consistent delete in a distributed data store
US8909781B2 (en) 2010-05-24 2014-12-09 Pi-Coral, Inc. Virtual access to network services
US8572029B2 (en) * 2010-05-31 2013-10-29 Salesforce.Com, Inc. Methods and systems for synchronizing data in a multi-tenant database environment
US9336263B2 (en) 2010-06-04 2016-05-10 Yale University Data loading systems and methods
US8886631B2 (en) 2010-06-04 2014-11-11 Yale University Query execution systems and methods
US8935232B2 (en) * 2010-06-04 2015-01-13 Yale University Query execution systems and methods
US9495427B2 (en) 2010-06-04 2016-11-15 Yale University Processing of data using a database system in communication with a data processing framework
US9292533B2 (en) * 2010-06-08 2016-03-22 Dell Products L.P. Systems and methods for improving storage efficiency in an information handling system
US8224780B2 (en) * 2010-06-15 2012-07-17 Microsoft Corporation Checkpoints for a file system
US9323775B2 (en) 2010-06-19 2016-04-26 Mapr Technologies, Inc. Map-reduce ready distributed file system
US11726955B2 (en) 2010-06-19 2023-08-15 Hewlett Packard Enterprise Development Lp Methods and apparatus for efficient container location database snapshot operation
US9477738B2 (en) 2010-07-21 2016-10-25 International Business Machines Corporation Initialization protocol for a peer-to-peer replication environment
US8635420B2 (en) * 2010-07-22 2014-01-21 Susan Elkington Resilient mirroring utilizing peer-to-peer storage
US8380961B2 (en) 2010-08-18 2013-02-19 International Business Machines Corporation Methods and systems for formatting storage volumes
US8392653B2 (en) 2010-08-18 2013-03-05 International Business Machines Corporation Methods and systems for releasing and re-allocating storage segments in a storage volume
US8306950B2 (en) * 2010-08-26 2012-11-06 International Business Machines Corporation Managing data access requests after persistent snapshots
US8290919B1 (en) * 2010-08-27 2012-10-16 Disney Enterprises, Inc. System and method for distributing and accessing files in a distributed storage system
US8392368B1 (en) 2010-08-27 2013-03-05 Disney Enterprises, Inc. System and method for distributing and accessing files in a distributed storage system
US8768981B1 (en) 2010-08-27 2014-07-01 Disney Enterprises, Inc. System and method for distributing and accessing files in a distributed storage system
US9411517B2 (en) 2010-08-30 2016-08-09 Vmware, Inc. System software interfaces for space-optimized block devices
US20130166654A1 (en) * 2010-08-31 2013-06-27 Telefonaktiebolaget L M Ericsson (Publ) Method and Arrangement in a Peer-to-Peer Network
US8996575B2 (en) * 2010-09-29 2015-03-31 M-Files Oy Method, an apparatus, a computer system, a security component and a computer readable medium for defining access rights in metadata-based file arrangement
US8972366B2 (en) * 2010-09-29 2015-03-03 Red Hat, Inc. Cloud-based directory system based on hashed values of parent and child storage locations
US9400799B2 (en) * 2010-10-04 2016-07-26 Dell Products L.P. Data block migration
CA2815569C (en) * 2010-10-25 2016-03-01 Research In Motion Limited System and method for enabling applications to communicate using a peer-to-peer (p2p) system
US8782238B2 (en) * 2010-11-05 2014-07-15 Verizon Patent And Licensing Inc. Server clustering in a computing-on-demand system
WO2012068184A1 (en) * 2010-11-15 2012-05-24 File System Labs Llc Methods and apparatus for distributed data storage
EP2643948A1 (en) * 2010-11-23 2013-10-02 Nokia Siemens Networks Oy Network element configuration management
US9824091B2 (en) 2010-12-03 2017-11-21 Microsoft Technology Licensing, Llc File system backup using change journal
US8620894B2 (en) 2010-12-21 2013-12-31 Microsoft Corporation Searching files
US10346430B2 (en) 2010-12-23 2019-07-09 Mongodb, Inc. System and method for determining consensus within a distributed database
US10366100B2 (en) 2012-07-26 2019-07-30 Mongodb, Inc. Aggregation framework system architecture and method
US10997211B2 (en) 2010-12-23 2021-05-04 Mongodb, Inc. Systems and methods for database zone sharding and API integration
US9805108B2 (en) 2010-12-23 2017-10-31 Mongodb, Inc. Large distributed database clustering systems and methods
US11615115B2 (en) 2010-12-23 2023-03-28 Mongodb, Inc. Systems and methods for managing distributed database deployments
US10713280B2 (en) 2010-12-23 2020-07-14 Mongodb, Inc. Systems and methods for managing distributed database deployments
US10977277B2 (en) 2010-12-23 2021-04-13 Mongodb, Inc. Systems and methods for database zone sharding and API integration
US11544288B2 (en) 2010-12-23 2023-01-03 Mongodb, Inc. Systems and methods for managing distributed database deployments
US10614098B2 (en) 2010-12-23 2020-04-07 Mongodb, Inc. System and method for determining consensus within a distributed database
US10262050B2 (en) 2015-09-25 2019-04-16 Mongodb, Inc. Distributed database systems and methods with pluggable storage engines
US8996463B2 (en) 2012-07-26 2015-03-31 Mongodb, Inc. Aggregation framework system architecture and method
US8572031B2 (en) 2010-12-23 2013-10-29 Mongodb, Inc. Method and apparatus for maintaining replica sets
US10740353B2 (en) 2010-12-23 2020-08-11 Mongodb, Inc. Systems and methods for managing distributed database deployments
US9740762B2 (en) 2011-04-01 2017-08-22 Mongodb, Inc. System and method for optimizing data migration in a partitioned database
US9881034B2 (en) 2015-12-15 2018-01-30 Mongodb, Inc. Systems and methods for automating management of distributed databases
US10698775B2 (en) 2016-05-31 2020-06-30 Mongodb, Inc. Method and apparatus for reading and writing committed data
US10198492B1 (en) * 2010-12-28 2019-02-05 Amazon Technologies, Inc. Data replication framework
US8468132B1 (en) 2010-12-28 2013-06-18 Amazon Technologies, Inc. Data replication framework
US8554762B1 (en) 2010-12-28 2013-10-08 Amazon Technologies, Inc. Data replication framework
US9449065B1 (en) 2010-12-28 2016-09-20 Amazon Technologies, Inc. Data replication framework
US8738725B2 (en) 2011-01-03 2014-05-27 Planetary Data LLC Community internet drive
CN102646024B (zh) * 2011-02-17 2015-02-18 纬创资通股份有限公司 多硬盘的读写管理方法与系统、电子装置
US8909747B2 (en) * 2011-02-24 2014-12-09 Alcatel Lucent Method and apparatus for localization in peer-to-peer systems
JP5776267B2 (ja) * 2011-03-29 2015-09-09 日本電気株式会社 分散ファイルシステム
US8548961B2 (en) 2011-03-30 2013-10-01 Splunk Inc. System and method for fast file tracking and change monitoring
US8566336B2 (en) 2011-03-30 2013-10-22 Splunk Inc. File identification management and tracking
US9396242B2 (en) * 2011-04-11 2016-07-19 Salesforce.Com, Inc. Multi-master data replication in a distributed multi-tenant system
US8996789B2 (en) 2011-05-23 2015-03-31 International Business Machines Corporation Handling high priority requests in a sequential access storage device having a non-volatile storage cache
US8799578B2 (en) 2011-05-23 2014-08-05 International Business Machines Corporation Managing unmodified tracks maintained in both a first cache and a second cache
US8825944B2 (en) 2011-05-23 2014-09-02 International Business Machines Corporation Populating strides of tracks to demote from a first cache to a second cache
US8788742B2 (en) 2011-05-23 2014-07-22 International Business Machines Corporation Using an attribute of a write request to determine where to cache data in a storage system having multiple caches including non-volatile storage cache in a sequential access storage device
US8806122B2 (en) 2011-05-23 2014-08-12 International Business Machines Corporation Caching data in a storage system having multiple caches including non-volatile storage cache in a sequential access storage device
US8793436B2 (en) 2011-05-23 2014-07-29 International Business Machines Corporation Cache management of tracks in a first cache and a second cache for a storage
US8432632B2 (en) 2011-05-23 2013-04-30 International Business Machines Corporation Magnetic disk drive using a non-volatile storage device as cache for modified tracks
US8825952B2 (en) 2011-05-23 2014-09-02 International Business Machines Corporation Handling high priority requests in a sequential access storage device having a non-volatile storage cache
US9110739B2 (en) 2011-06-07 2015-08-18 Microsoft Technology Licensing, Llc Subscribing to multiple resources through a common connection
US9172708B2 (en) * 2011-06-23 2015-10-27 Microsoft Technology Licensing, Llc Computing system for managing data
US8843502B2 (en) 2011-06-24 2014-09-23 Microsoft Corporation Sorting a dataset of incrementally received data
US9229818B2 (en) 2011-07-20 2016-01-05 Microsoft Technology Licensing, Llc Adaptive retention for backup data
KR101888648B1 (ko) * 2011-09-01 2018-08-16 삼성전자주식회사 주소록에서 자동으로 그룹을 생성하고 관리하는 방법 및 그 장치
US9626378B2 (en) * 2011-09-02 2017-04-18 Compuverde Ab Method for handling requests in a storage system and a storage node for a storage system
US8997124B2 (en) 2011-09-02 2015-03-31 Compuverde Ab Method for updating data in a distributed data storage system
US8645978B2 (en) 2011-09-02 2014-02-04 Compuverde Ab Method for data maintenance
US9021053B2 (en) 2011-09-02 2015-04-28 Compuverde Ab Method and device for writing data to a data storage system comprising a plurality of data storage nodes
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system
US8650365B2 (en) 2011-09-02 2014-02-11 Compuverde Ab Method and device for maintaining data in a data storage system comprising a plurality of data storage nodes
US8881100B2 (en) * 2011-09-07 2014-11-04 International Business Machines Corporation Automated generation of bridging code to augment a legacy application using an object-oriented language
US20130124562A1 (en) * 2011-11-10 2013-05-16 Microsoft Corporation Export of content items from multiple, disparate content sources
US9804928B2 (en) 2011-11-14 2017-10-31 Panzura, Inc. Restoring an archived file in a distributed filesystem
US9817898B2 (en) 2011-11-14 2017-11-14 Microsoft Technology Licensing, Llc Locating relevant content items across multiple disparate content sources
US9805054B2 (en) 2011-11-14 2017-10-31 Panzura, Inc. Managing a global namespace for a distributed filesystem
CN103176861A (zh) * 2011-12-26 2013-06-26 富泰华工业（深圳）有限公司 用于数据备份的存储系统及备份方法
US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
US9054992B2 (en) 2011-12-27 2015-06-09 Solidfire, Inc. Quality of service policy sets
WO2013102506A2 (en) * 2012-01-02 2013-07-11 International Business Machines Corporation Method and system for backup and recovery
US8825953B2 (en) 2012-01-17 2014-09-02 International Business Machines Corporation Demoting tracks from a first cache to a second cache by using a stride number ordering of strides in the second cache to consolidate strides in the second cache
US9021201B2 (en) 2012-01-17 2015-04-28 International Business Machines Corporation Demoting partial tracks from a first cache to a second cache
US8966178B2 (en) 2012-01-17 2015-02-24 International Business Machines Corporation Populating a first stride of tracks from a first cache to write to a second stride in a second cache
US8825957B2 (en) 2012-01-17 2014-09-02 International Business Machines Corporation Demoting tracks from a first cache to a second cache by using an occupancy of valid tracks in strides in the second cache to consolidate strides in the second cache
US9166892B1 (en) 2012-01-20 2015-10-20 Google Inc. Systems and methods for event stream management
EP2791831B1 (en) * 2012-01-25 2020-03-11 Hitachi, Ltd. Single instantiation method using file clone and file storage system utilizing the same
US10860384B2 (en) * 2012-02-03 2020-12-08 Microsoft Technology Licensing, Llc Managing partitions in a scalable environment
CN103354923B (zh) * 2012-02-09 2016-03-09 华为技术有限公司 一种数据重建方法、装置和系统
CN102662947A (zh) * 2012-02-21 2012-09-12 惠州Tcl移动通信有限公司 手机及其文件配置方法
US9355120B1 (en) * 2012-03-02 2016-05-31 Netapp, Inc. Systems and methods for managing files in a content storage system
US8832050B2 (en) * 2012-03-09 2014-09-09 Hewlett-Packard Development Company, L.P. Validation of distributed balanced trees
EP2825976B1 (en) * 2012-03-16 2017-05-03 BlackBerry Limited System and method for managing data using tree structures
US8935203B1 (en) 2012-03-29 2015-01-13 Amazon Technologies, Inc. Environment-sensitive distributed data management
US8918392B1 (en) 2012-03-29 2014-12-23 Amazon Technologies, Inc. Data storage mapping and management
US8930364B1 (en) * 2012-03-29 2015-01-06 Amazon Technologies, Inc. Intelligent data integration
US8832234B1 (en) 2012-03-29 2014-09-09 Amazon Technologies, Inc. Distributed data storage controller
US11003687B2 (en) 2012-05-15 2021-05-11 Splunk, Inc. Executing data searches using generation identifiers
US8788459B2 (en) * 2012-05-15 2014-07-22 Splunk Inc. Clustering for high availability and disaster recovery
US10387448B2 (en) 2012-05-15 2019-08-20 Splunk Inc. Replication of summary data in a clustered computing environment
US9130971B2 (en) 2012-05-15 2015-09-08 Splunk, Inc. Site-based search affinity
US9305004B2 (en) * 2012-06-05 2016-04-05 International Business Machines Corporation Replica identification and collision avoidance in file system replication
KR101694288B1 (ko) * 2012-06-08 2017-01-09 한국전자통신연구원 비대칭형 클러스터 파일 시스템의 데이터 관리 방법
US9754005B2 (en) 2012-06-18 2017-09-05 Actifio, Inc. System and method for incrementally backing up out-of-band data
US10078474B1 (en) * 2012-06-29 2018-09-18 Emc Corporation Method of maintaining list of scratch volumes in shared filesystems across multiple nodes
US11544284B2 (en) 2012-07-26 2023-01-03 Mongodb, Inc. Aggregation framework system architecture and method
US11403317B2 (en) 2012-07-26 2022-08-02 Mongodb, Inc. Aggregation framework system architecture and method
US10872095B2 (en) 2012-07-26 2020-12-22 Mongodb, Inc. Aggregation framework system architecture and method
US9778856B2 (en) 2012-08-30 2017-10-03 Microsoft Technology Licensing, Llc Block-level access to parallel storage
US9317508B2 (en) * 2012-09-07 2016-04-19 Red Hat, Inc. Pro-active self-healing in a distributed file system
US8769105B2 (en) 2012-09-14 2014-07-01 Peaxy, Inc. Software-defined network attachable storage system and method
US9355036B2 (en) 2012-09-18 2016-05-31 Netapp, Inc. System and method for operating a system to cache a networked file system utilizing tiered storage and customizable eviction policies based on priority and tiers
US9158528B2 (en) * 2012-10-02 2015-10-13 Oracle International Corporation Forcibly completing upgrade of distributed software in presence of failures
US8875227B2 (en) * 2012-10-05 2014-10-28 International Business Machines Corporation Privacy aware authenticated map-reduce
US9253053B2 (en) 2012-10-11 2016-02-02 International Business Machines Corporation Transparently enforcing policies in hadoop-style processing infrastructures
CN103731451B (zh) * 2012-10-12 2018-10-19 腾讯科技（深圳）有限公司 一种文件上传的方法及系统
EP2907264B1 (en) * 2012-10-15 2021-08-11 Telefonaktiebolaget LM Ericsson (publ) A ue, a bm-sc, a status management server, a load balancing server and a file repair server and respective methods therein are provided for file repair procedure
US9678983B1 (en) * 2012-10-19 2017-06-13 Oracle International Corporation Systems and methods for automatically passing hints to a file system
TWI494872B (zh) * 2012-11-06 2015-08-01 Quanta Comp Inc 自動軟體稽核系統及自動軟體稽核方法
CN104838374A (zh) * 2012-12-06 2015-08-12 英派尔科技开发有限公司 分散hadoop集群
US8972334B2 (en) * 2012-12-21 2015-03-03 International Business Machines Corporation Transparent data service suitable for modifying data storage capabilities in applications
CN103902577B (zh) * 2012-12-27 2017-05-03 中国移动通信集团四川有限公司 一种资源查找定位的方法和系统
CN103078926B (zh) * 2012-12-28 2016-03-30 华为技术有限公司 分布式存储系统的文件访问方法和装置以及系统
US9063967B2 (en) * 2013-01-10 2015-06-23 Pure Storage, Inc. Performing copies in a storage system
US10908835B1 (en) 2013-01-10 2021-02-02 Pure Storage, Inc. Reversing deletion of a virtual machine
US11733908B2 (en) 2013-01-10 2023-08-22 Pure Storage, Inc. Delaying deletion of a dataset
US9081654B2 (en) * 2013-01-18 2015-07-14 Microsoft Technology Licensing, Llc Common lease agent for cluster communication
US20140214899A1 (en) * 2013-01-25 2014-07-31 Hewlett-Packard Development Company, L.P. Leaf names and relative level indications for file system objects
WO2014118791A1 (en) * 2013-01-29 2014-08-07 Hewlett-Packard Development Company, L. P Methods and systems for shared file storage
US9128944B2 (en) * 2013-02-13 2015-09-08 Edgecast Networks, Inc. File system enabling fast purges and file access
TWI502384B (zh) * 2013-02-19 2015-10-01 Acer Inc 檔案追蹤方法及其所適用之網路通訊裝置
CN105121760B (zh) * 2013-02-21 2018-09-25 Cfm环球有限责任公司 用于结构的具有隐藏的电子组件的建筑支撑体
CN104052767A (zh) * 2013-03-13 2014-09-17 宏碁股份有限公司 文件追踪方法及其所适用的网络通信装置
US10447524B1 (en) * 2013-03-14 2019-10-15 EMC IP Holding Company LLC Unified datapath processing with virtualized storage processors
US9805105B1 (en) * 2013-03-15 2017-10-31 EMC IP Holding Company LLC Automatically creating multiple replication sessions in response to a single replication command entered by a user
US9311326B2 (en) * 2013-04-12 2016-04-12 Alterante, Inc. Virtual file system for automated data replication and review
US20140330901A1 (en) * 2013-05-03 2014-11-06 Htc Corporation Method and device for sharing digital object over mesh network
US8984190B2 (en) 2013-05-23 2015-03-17 Western Digital Technologies, Inc. Methods and devices for booting a network attached storage with two logical units
US10963431B2 (en) * 2013-06-11 2021-03-30 Red Hat, Inc. Storing an object in a distributed storage system
TWI573015B (zh) 2013-06-19 2017-03-01 祥碩科技股份有限公司 防超時方法及資料處理系統
US10127236B1 (en) * 2013-06-27 2018-11-13 EMC IP Holding Company Filesystem storing file data in larger units than used for metadata
CN105308574A (zh) 2013-06-28 2016-02-03 惠普发展公司，有限责任合伙企业 永久主存储器的容错
US9213611B2 (en) 2013-07-24 2015-12-15 Western Digital Technologies, Inc. Automatic raid mirroring when adding a second boot drive
US9659050B2 (en) * 2013-08-06 2017-05-23 Sybase, Inc. Delta store giving row-level versioning semantics to a non-row-level versioning underlying store
US9436842B2 (en) * 2013-08-16 2016-09-06 Vinay Purohit Distributed fragments file system
US11422907B2 (en) 2013-08-19 2022-08-23 Microsoft Technology Licensing, Llc Disconnected operation for systems utilizing cloud storage
US10747475B2 (en) 2013-08-26 2020-08-18 Vmware, Inc. Virtual disk blueprints for a virtualized storage area network, wherein virtual disk objects are created from local physical storage of host computers that are running multiple virtual machines
US9672115B2 (en) 2013-08-26 2017-06-06 Vmware, Inc. Partition tolerance in cluster membership management
US9811531B2 (en) 2013-08-26 2017-11-07 Vmware, Inc. Scalable distributed storage architecture
US11016820B2 (en) 2013-08-26 2021-05-25 Vmware, Inc. Load balancing of resources
US9582198B2 (en) 2013-08-26 2017-02-28 Vmware, Inc. Compressed block map of densely-populated data structures
US9887924B2 (en) 2013-08-26 2018-02-06 Vmware, Inc. Distributed policy-based provisioning and enforcement for quality of service
US9304997B2 (en) * 2013-08-27 2016-04-05 Netapp, Inc. Asynchronously migrating a file system
US9311331B2 (en) * 2013-08-27 2016-04-12 Netapp, Inc. Detecting out-of-band (OOB) changes when replicating a source file system using an in-line system
US20160041996A1 (en) 2014-08-11 2016-02-11 Netapp, Inc. System and method for developing and implementing a migration plan for migrating a file system
US10860529B2 (en) 2014-08-11 2020-12-08 Netapp Inc. System and method for planning and configuring a file system migration
US9300692B2 (en) 2013-08-27 2016-03-29 Netapp, Inc. System and method for implementing data migration while preserving security policies of a source filer
US9311314B2 (en) * 2013-08-27 2016-04-12 Netapp, Inc. System and method for migrating data from a source file system to a destination file system with use of attribute manipulation
US9471610B1 (en) * 2013-09-16 2016-10-18 Amazon Technologies, Inc. Scale-out of data that supports roll back
JP6238659B2 (ja) * 2013-09-18 2017-11-29 キヤノン株式会社 管理システム、監視装置及びそれらの制御方法
US9477679B2 (en) * 2013-09-20 2016-10-25 Google Inc. Programmatically choosing preferred storage parameters for files in large-scale distributed storage systems
TWI514825B (zh) * 2013-09-23 2015-12-21 Promise Tecnnology Inc 具有內部儲存區域網路交換模組之資料儲存單元以及包含該資料儲存單元之備援式資料儲存系統
US9405783B2 (en) * 2013-10-02 2016-08-02 Netapp, Inc. Extent hashing technique for distributed storage architecture
US9819570B2 (en) * 2013-10-09 2017-11-14 International Business Machines Corporation Dynamic symbolic links for referencing in a file system
US9747166B2 (en) * 2013-10-10 2017-08-29 Adobe Systems Incorporated Self healing cluster of a content management system
HUE046816T2 (hu) 2013-10-11 2020-03-30 Asana Biosciences Llc Fehérje-polimer-gyógyszer konjugátumok
US20150120697A1 (en) 2013-10-28 2015-04-30 Scalebase Inc. System and method for analysis of a database proxy
US9525735B2 (en) * 2013-10-30 2016-12-20 Futurewei Technologies, Inc. Lock elevation in a distributed file storage system
US20150142855A1 (en) * 2013-11-15 2015-05-21 Paul Fast Mobile database initialization and update for offline consumption
TWI514811B (zh) * 2013-11-28 2015-12-21 Synology Inc 網路系統的操作方法
TWI548246B (zh) * 2013-12-02 2016-09-01 緯創資通股份有限公司 叢集伺服器部署方法以及使用該方法的裝置
US20150156264A1 (en) * 2013-12-04 2015-06-04 International Business Machines Corporation File access optimization using strategically partitioned and positioned data in conjunction with a collaborative peer transfer system
US20150160864A1 (en) * 2013-12-09 2015-06-11 Netapp, Inc. Systems and methods for high availability in multi-node storage networks
US10769296B2 (en) * 2013-12-10 2020-09-08 Early Warning Services, Llc System and method of permission-based data sharing
JP6221717B2 (ja) * 2013-12-12 2017-11-01 富士通株式会社 ストレージ装置、ストレージシステム及びデータ管理プログラム
US10693955B2 (en) * 2013-12-14 2020-06-23 Netapp, Inc. Techniques for SAN storage cluster synchronous disaster recovery
DE102013114214A1 (de) * 2013-12-17 2015-06-18 Fujitsu Technology Solutions Intellectual Property Gmbh POSIX-kompatibles Dateisystem, Verfahren zum Erzeugen einer Dateiliste und Speichervorrichtung
US9665533B2 (en) 2013-12-20 2017-05-30 Rambus Inc. Blob pools, selectors, and command set implemented within a memory appliance for accessing memory
US10592475B1 (en) * 2013-12-27 2020-03-17 Amazon Technologies, Inc. Consistent data storage in distributed computing systems
US9448924B2 (en) 2014-01-08 2016-09-20 Netapp, Inc. Flash optimized, log-structured layer of a file system
US9529546B2 (en) 2014-01-08 2016-12-27 Netapp, Inc. Global in-line extent-based deduplication
US9268653B2 (en) * 2014-01-17 2016-02-23 Netapp, Inc. Extent metadata update logging and checkpointing
US9256549B2 (en) 2014-01-17 2016-02-09 Netapp, Inc. Set-associative hash table organization for efficient storage and retrieval of data in a storage system
US9798631B2 (en) 2014-02-04 2017-10-24 Microsoft Technology Licensing, Llc Block storage by decoupling ordering from durability
US10303702B2 (en) 2014-02-07 2019-05-28 Ignite Scalarc Solutions, Inc. System and method for analysis and management of data distribution in a distributed database environment
US9542404B2 (en) * 2014-02-17 2017-01-10 Netapp, Inc. Subpartitioning of a namespace region
US9483482B2 (en) * 2014-02-17 2016-11-01 Netapp, Inc. Partitioning file system namespace
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
US10506075B1 (en) * 2014-03-26 2019-12-10 Amazon Technologies, Inc. Link correction system and methods
US10372685B2 (en) 2014-03-31 2019-08-06 Amazon Technologies, Inc. Scalable file storage service
US9519510B2 (en) * 2014-03-31 2016-12-13 Amazon Technologies, Inc. Atomic writes for multiple-extent operations
US10264071B2 (en) 2014-03-31 2019-04-16 Amazon Technologies, Inc. Session management in distributed storage systems
ES2881606T3 (es) * 2014-03-31 2021-11-30 Wandisco Inc Sistema de ficheros geográficamente distribuido que usa replicación de espacio de nombres coordinada
US9495478B2 (en) * 2014-03-31 2016-11-15 Amazon Technologies, Inc. Namespace management in distributed storage systems
US9268597B2 (en) 2014-04-01 2016-02-23 Google Inc. Incremental parallel processing of data
US9992292B2 (en) * 2014-04-01 2018-06-05 Noom, Inc. Wellness support groups for mobile devices
US9886216B2 (en) 2014-04-08 2018-02-06 Western Digital Technologies, Inc. Distributed remote data storage access
US20150293699A1 (en) 2014-04-11 2015-10-15 Graham Bromley Network-attached storage enhancement appliance
CN103916479B (zh) * 2014-04-15 2017-05-03 大连理工大学 一种基于工作组文件的云同步局域网加速系统
US10523753B2 (en) 2014-05-06 2019-12-31 Western Digital Technologies, Inc. Broadcast data operations in distributed file systems
US10542049B2 (en) 2014-05-09 2020-01-21 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US20210149981A1 (en) 2014-05-21 2021-05-20 New3S Method of building a three-dimensional network site, network site obtained by this method, and method of navigating within or from such a network site
CN104008152B (zh) * 2014-05-21 2017-12-01 华南理工大学 支持海量数据访问的分布式文件系统的架构方法
US9672165B1 (en) * 2014-05-21 2017-06-06 Veritas Technologies Llc Data management tier coupling primary storage and secondary storage
US9459975B2 (en) * 2014-06-20 2016-10-04 Red Hat Israel, Ltd. Managing storage connections
US10075329B2 (en) * 2014-06-25 2018-09-11 A 10 Networks, Incorporated Customizable high availability switchover control of application delivery controllers
US10425480B2 (en) * 2014-06-26 2019-09-24 Hitachi Vantara Corporation Service plan tiering, protection, and rehydration strategies
US9798728B2 (en) 2014-07-24 2017-10-24 Netapp, Inc. System performing data deduplication using a dense tree data structure
CN104135514B (zh) * 2014-07-25 2017-10-17 英业达科技有限公司 融合式虚拟化存储系统
WO2016018447A1 (en) * 2014-07-31 2016-02-04 Hewlett-Packard Development Company, L.P. File creation
JP6689821B2 (ja) * 2014-08-12 2020-04-28 シンジェンタ パーティシペーションズ アーゲー 硫黄含有置換基を有する殺有害生物的に活性な複素環式誘導体
US9886447B2 (en) 2014-08-22 2018-02-06 International Business Machines Corporation Performance of asynchronous replication in HSM integrated storage systems
US9823985B2 (en) * 2014-08-29 2017-11-21 Cynny Space Srl Systems and methods to organize a computing system having multiple computers
US9613048B2 (en) * 2014-09-10 2017-04-04 Panzura, Inc. Sending interim notifications to a client of a distributed filesystem
US10630772B2 (en) 2014-09-10 2020-04-21 Panzura, Inc. Maintaining global namespace consistency for a distributed filesystem
US10291705B2 (en) 2014-09-10 2019-05-14 Panzura, Inc. Sending interim notifications for namespace operations for a distributed filesystem
US9501359B2 (en) 2014-09-10 2016-11-22 Netapp, Inc. Reconstruction of dense tree volume metadata state across crash recovery
US9671960B2 (en) 2014-09-12 2017-06-06 Netapp, Inc. Rate matching technique for balancing segment cleaning and I/O workload
US10133511B2 (en) 2014-09-12 2018-11-20 Netapp, Inc Optimized segment cleaning technique
US9766990B1 (en) * 2014-09-23 2017-09-19 EMC IP Holding Company LLC Checkpoint block storage device
US11095715B2 (en) * 2014-09-24 2021-08-17 Ebay Inc. Assigning storage responsibility in a distributed data storage system with replication
US9990423B2 (en) * 2014-09-30 2018-06-05 Splunk Inc. Hybrid cluster-based data intake and query
US20160094649A1 (en) * 2014-09-30 2016-03-31 Code 42 Software, Inc. Node-to-node data distribution
US10235460B2 (en) 2014-09-30 2019-03-19 Splunk Inc. Sharing configuration information for searches in data intake and query systems
US9922099B2 (en) 2014-09-30 2018-03-20 Splunk Inc. Event limited field picker
US9697227B2 (en) * 2014-10-27 2017-07-04 Cohesity, Inc. Concurrent access and transactions in a distributed file system
EP3216177B1 (en) 2014-11-06 2021-04-14 Hewlett Packard Enterprise Development LP Network policy graphs
US10909086B2 (en) * 2014-11-17 2021-02-02 Red Hat, Inc. File lookup in a distributed file system
US9836229B2 (en) 2014-11-18 2017-12-05 Netapp, Inc. N-way merge technique for updating volume metadata in a storage I/O stack
CN104580359B (zh) * 2014-11-26 2018-09-28 上海斐讯数据通信技术有限公司 带存储功能的路由器中文件分片加密存储备份及下载方法
US9767118B2 (en) * 2014-12-01 2017-09-19 Dell Products, Lp Optimized UEFI file system with network file system compound statements
US9882906B2 (en) 2014-12-12 2018-01-30 International Business Machines Corporation Recommendation schema for storing data in a shared data storage network
CN105790985B (zh) * 2014-12-23 2020-06-16 中兴通讯股份有限公司 数据倒换的方法、第一设备、第二设备及系统
US10185730B2 (en) * 2014-12-31 2019-01-22 Nexenta Systems, Inc. Methods and systems for key-value-tuple-encoded storage
US10911537B1 (en) * 2014-12-31 2021-02-02 Acronis International Gmbh Increasing speed of synchronization and restore
US9800659B2 (en) 2015-02-02 2017-10-24 International Business Machines Corporation Enterprise peer-to-peer storage and method of managing peer network storage
US10242014B2 (en) * 2015-02-04 2019-03-26 International Business Machines Corporation Filesystem with isolated independent filesets
US9906510B2 (en) * 2015-02-10 2018-02-27 Airwatch Llc Virtual content repository
US9720601B2 (en) 2015-02-11 2017-08-01 Netapp, Inc. Load balancing technique for a storage array
US10013682B2 (en) 2015-02-13 2018-07-03 International Business Machines Corporation Storage and recovery of digital data based on social network
US10148748B2 (en) * 2015-02-26 2018-12-04 Microsoft Technology Licensing, Llc Co-locating peer devices for peer matching
US20160259836A1 (en) 2015-03-03 2016-09-08 Overland Storage, Inc. Parallel asynchronous data replication
US10652322B2 (en) * 2015-03-09 2020-05-12 International Business Machines Corporation Scalable parallel messaging process
US9762460B2 (en) 2015-03-24 2017-09-12 Netapp, Inc. Providing continuous context for operational information of a storage system
US9781024B2 (en) * 2015-03-25 2017-10-03 International Business Machines Corporation Supporting low latency applications at the edge of wireless communication networks
US9710317B2 (en) 2015-03-30 2017-07-18 Netapp, Inc. Methods to identify, handle and recover from suspect SSDS in a clustered flash array
US9922201B2 (en) 2015-04-01 2018-03-20 Dropbox, Inc. Nested namespaces for selective content sharing
US10963430B2 (en) 2015-04-01 2021-03-30 Dropbox, Inc. Shared workspaces with selective content item synchronization
US9772920B2 (en) * 2015-04-29 2017-09-26 Apollo Education Group, Inc. Dynamic service fault detection and recovery using peer services
US10216418B2 (en) * 2015-06-01 2019-02-26 Samsung Electronics Co., Ltd. Storage apparatus and method for autonomous space compaction
US11042328B2 (en) 2015-06-01 2021-06-22 Samsung Electronics Co., Ltd. Storage apparatus and method for autonomous space compaction
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
RU2634223C2 (ru) * 2015-06-30 2017-10-24 Общество С Ограниченной Ответственностью "Яндекс" Способ (варианты) и система (варианты) управления данными, связанными с иерархической структурой
US10496669B2 (en) 2015-07-02 2019-12-03 Mongodb, Inc. System and method for augmenting consensus election in a distributed database
US9740566B2 (en) 2015-07-31 2017-08-22 Netapp, Inc. Snapshot creation workflow
WO2017042978A1 (ja) * 2015-09-11 2017-03-16 株式会社日立製作所 計算機システム、ストレージ装置、及びデータの管理方法
US10846411B2 (en) 2015-09-25 2020-11-24 Mongodb, Inc. Distributed database systems and methods with encrypted storage engines
US10394822B2 (en) 2015-09-25 2019-08-27 Mongodb, Inc. Systems and methods for data conversion and comparison
US10673623B2 (en) 2015-09-25 2020-06-02 Mongodb, Inc. Systems and methods for hierarchical key management in encrypted distributed databases
US10423626B2 (en) 2015-09-25 2019-09-24 Mongodb, Inc. Systems and methods for data conversion and comparison
CN106559246B (zh) * 2015-09-30 2020-01-10 新华三技术有限公司 集群的实现方法和服务器
US20170097893A1 (en) * 2015-10-01 2017-04-06 Tridib Chakravarty Systems and methods for tape data access
US9571573B1 (en) * 2015-10-29 2017-02-14 Dropbox, Inc. Peer-to-peer synchronization protocol for multi-premises hosting of digital content items
US10691718B2 (en) 2015-10-29 2020-06-23 Dropbox, Inc. Synchronization protocol for multi-premises hosting of digital content items
CN106649412B (zh) * 2015-11-04 2021-05-04 阿里巴巴集团控股有限公司 一种数据处理方法和设备
US11100073B2 (en) * 2015-11-12 2021-08-24 Verizon Media Inc. Method and system for data assignment in a distributed system
US10079883B2 (en) 2015-12-03 2018-09-18 International Business Machines Corporation Primary device selection at operating system initialization
US10127238B1 (en) * 2015-12-08 2018-11-13 EMC IP Holding Company LLC Methods and apparatus for filtering dynamically loadable namespaces (DLNs)
US20170171021A1 (en) * 2015-12-09 2017-06-15 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Automatic deployment of a new server in a peer-to-peer network of servers
US10511505B2 (en) * 2015-12-09 2019-12-17 Keysight Technologies Singapore (Sales) Pte. Ltd. Systems and methods to recreate real world application level test packets for network testing
US9613046B1 (en) * 2015-12-14 2017-04-04 Netapp, Inc. Parallel optimized remote synchronization of active block storage
US9858011B2 (en) * 2015-12-16 2018-01-02 International Business Machines Corporation Repopulating failed replicas through modified consensus recovery
US10567500B1 (en) * 2015-12-21 2020-02-18 Amazon Technologies, Inc. Continuous backup of data in a distributed data store
US10021184B2 (en) 2015-12-31 2018-07-10 Dropbox, Inc. Randomized peer-to-peer synchronization of shared content items
US9479578B1 (en) * 2015-12-31 2016-10-25 Dropbox, Inc. Randomized peer-to-peer synchronization of shared content items
US9954958B2 (en) * 2016-01-29 2018-04-24 Red Hat, Inc. Shared resource management
US9537952B1 (en) 2016-01-29 2017-01-03 Dropbox, Inc. Apparent cloud access for hosted content items
CN107045422B (zh) 2016-02-06 2020-12-01 华为技术有限公司 分布式存储方法和设备
US9996541B2 (en) 2016-02-10 2018-06-12 Red Hat, Inc. Hash-based mount point lookup in virtual file systems
US10540165B2 (en) 2016-02-12 2020-01-21 Nutanix, Inc. Virtualized file server rolling upgrade
US10476957B2 (en) * 2016-02-26 2019-11-12 Red Hat, Inc. Granular entry self-healing
CN107133086B (zh) * 2016-02-29 2020-09-04 阿里巴巴集团控股有限公司 基于分布式系统的任务处理方法、装置和系统
US10452490B2 (en) 2016-03-09 2019-10-22 Commvault Systems, Inc. Data management and backup of distributed storage environment
US10929022B2 (en) 2016-04-25 2021-02-23 Netapp. Inc. Space savings reporting for storage system supporting snapshot and clones
US10264072B2 (en) * 2016-05-16 2019-04-16 Carbonite, Inc. Systems and methods for processing-based file distribution in an aggregation of cloud storage services
US11100107B2 (en) 2016-05-16 2021-08-24 Carbonite, Inc. Systems and methods for secure file management via an aggregation of cloud storage services
US10404798B2 (en) 2016-05-16 2019-09-03 Carbonite, Inc. Systems and methods for third-party policy-based file distribution in an aggregation of cloud storage services
US10356158B2 (en) 2016-05-16 2019-07-16 Carbonite, Inc. Systems and methods for aggregation of cloud storage
US10116629B2 (en) 2016-05-16 2018-10-30 Carbonite, Inc. Systems and methods for obfuscation of data via an aggregation of cloud storage services
US11218418B2 (en) 2016-05-20 2022-01-04 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US10749921B2 (en) * 2016-06-01 2020-08-18 Netflix, Inc. Techniques for warming up a node in a distributed data store
CN105915633B (zh) * 2016-06-02 2019-12-10 北京百度网讯科技有限公司 自动化运维系统和方法
US10970175B2 (en) 2016-06-15 2021-04-06 Sap Se Flexible per-request data durability in databases and other data stores
US10180812B2 (en) * 2016-06-16 2019-01-15 Sap Se Consensus protocol enhancements for supporting flexible durability options
US10178186B2 (en) 2016-06-16 2019-01-08 Sap Se Connection reestablishment protocol for peer communication in distributed systems
US10621050B2 (en) 2016-06-27 2020-04-14 Mongodb, Inc. Method and apparatus for restoring data from snapshots
US10360103B2 (en) * 2016-07-18 2019-07-23 International Business Machines Corporation Focused storage pool expansion to prevent a performance degradation
US11240305B2 (en) 2016-07-28 2022-02-01 At&T Intellectual Property I, L.P. Task allocation among devices in a distributed data storage system
CN107707583B (zh) * 2016-08-08 2020-11-17 环旭电子股份有限公司 云端数据传输系统及其动态分流方法
US9971594B2 (en) * 2016-08-16 2018-05-15 Sonatype, Inc. Method and system for authoritative name analysis of true origin of a file
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US10592546B2 (en) * 2016-09-23 2020-03-17 Amazon Technologies, Inc. System for optimizing access to an indexed database
US10346458B2 (en) 2016-09-23 2019-07-09 Amazon Technologies, Inc. Media asset access control system
US10614043B2 (en) * 2016-09-30 2020-04-07 Adobe Inc. Document replication based on distributional semantics
JP7004463B2 (ja) 2016-09-30 2022-01-21 ローレンス リチャード オリバー， 分散型の識別解除ブリッジングネットワークプラットフォーム
CN108023969A (zh) * 2016-11-02 2018-05-11 华为技术有限公司 一种ip地址续租方法及装置
US11126740B2 (en) * 2016-11-04 2021-09-21 Microsoft Technology Licensing, Llc Storage isolation for containers
CN106775446B (zh) * 2016-11-11 2020-04-17 中国人民解放军国防科学技术大学 基于固态硬盘加速的分布式文件系统小文件访问方法
US10776342B2 (en) * 2016-11-18 2020-09-15 Tuxena, Inc. Systems and methods for recovering lost clusters from a mounted volume
US10728090B2 (en) * 2016-12-02 2020-07-28 Nutanix, Inc. Configuring network segmentation for a virtualization environment
US11568073B2 (en) 2016-12-02 2023-01-31 Nutanix, Inc. Handling permissions for virtualized file servers
US10824455B2 (en) 2016-12-02 2020-11-03 Nutanix, Inc. Virtualized server systems and methods including load balancing for virtualized file servers
US11562034B2 (en) 2016-12-02 2023-01-24 Nutanix, Inc. Transparent referrals for distributed file servers
US11294777B2 (en) 2016-12-05 2022-04-05 Nutanix, Inc. Disaster recovery for distributed file servers, including metadata fixers
US11288239B2 (en) 2016-12-06 2022-03-29 Nutanix, Inc. Cloning virtualized file servers
US11281484B2 (en) 2016-12-06 2022-03-22 Nutanix, Inc. Virtualized server systems and methods including scaling of file system virtual machines
EA036442B1 (ru) * 2016-12-13 2020-11-11 Автономная некоммерческая организация высшего образования "Университет Иннополис" Верификация хранимых данных через определение параметров хранения с использованием распределенной базы данных с неизменяемыми объектами
US10389743B1 (en) 2016-12-22 2019-08-20 Symantec Corporation Tracking of software executables that come from untrusted locations
US10579587B2 (en) 2017-01-03 2020-03-03 International Business Machines Corporation Space management for a hierarchical set of file systems
US10657102B2 (en) 2017-01-03 2020-05-19 International Business Machines Corporation Storage space management in union mounted file systems
US10649955B2 (en) 2017-01-03 2020-05-12 International Business Machines Corporation Providing unique inodes across multiple file system namespaces
US10592479B2 (en) 2017-01-03 2020-03-17 International Business Machines Corporation Space management for a hierarchical set of file systems
US10585860B2 (en) 2017-01-03 2020-03-10 International Business Machines Corporation Global namespace for a hierarchical set of file systems
US10579598B2 (en) 2017-01-03 2020-03-03 International Business Machines Corporation Global namespace for a hierarchical set of file systems
US20180189124A1 (en) * 2017-01-03 2018-07-05 International Business Machines Corporation Rebuilding the namespace in a hierarchical union mounted file system
CN106844584B (zh) * 2017-01-10 2019-12-17 清华大学 元数据结构和基于其的操作方法、定位方法、切分方法
US10530857B2 (en) 2017-01-19 2020-01-07 International Business Machines Corporation Smart mounting of storage devices
US10387383B2 (en) * 2017-02-15 2019-08-20 Google Llc Systems and methods for providing access to a data file stored at a data storage system
US11182340B2 (en) * 2017-02-15 2021-11-23 Paypal, Inc. Data transfer size reduction
US11809384B2 (en) * 2017-03-06 2023-11-07 Microsoft Technology Licensing, Llc Optimized data storage for fast retrieval
US11210270B2 (en) * 2017-03-09 2021-12-28 Microsoft Technology Licensing, Llc Mapping storage across storage providers
TWI629885B (zh) * 2017-03-24 2018-07-11 中華電信股份有限公司 Software defined heterogeneous controller network environment high availability system and method thereof
US10296425B2 (en) 2017-04-20 2019-05-21 Bank Of America Corporation Optimizing data processing across server clusters and data centers using checkpoint-based data replication
US10552389B2 (en) * 2017-04-28 2020-02-04 Oath Inc. Object and sequence number management
US20180314957A1 (en) * 2017-04-28 2018-11-01 Hewlett Packard Enterprise Development Lp Inferring a label namespace
US10929341B2 (en) * 2017-04-28 2021-02-23 Netapp, Inc. Iterative object scanning for information lifecycle management
US10812342B2 (en) 2017-04-28 2020-10-20 Hewlett Packard Enterprise Development Lp Generating composite network policy
US10540189B2 (en) * 2017-05-22 2020-01-21 Analytical Graphics Inc. Formalized execution of model integrated descriptive architecture languages
JP2018200641A (ja) * 2017-05-29 2018-12-20 富士通株式会社 異常検知プログラム、異常検知方法および情報処理装置
US10659561B2 (en) * 2017-06-09 2020-05-19 Microsoft Technology Licensing, Llc Service state preservation across nodes
US10866868B2 (en) 2017-06-20 2020-12-15 Mongodb, Inc. Systems and methods for optimization of database operations
US10536548B2 (en) 2017-06-20 2020-01-14 Western Digital Technologies, Inc. Redundant network routing with proxy servers
US10324652B2 (en) * 2017-06-23 2019-06-18 Netapp, Inc. Methods for copy-free data migration across filesystems and devices thereof
US10324855B2 (en) * 2017-06-23 2019-06-18 International Business Machines Corporation Associating a processing thread and memory section to a memory device
US10601917B2 (en) * 2017-06-27 2020-03-24 Red Hat, Inc. Containerized high-performance network storage
EP3649558B8 (en) * 2017-07-06 2024-04-17 Chromaway AB Method and system for a distributed computing system
US10747778B2 (en) * 2017-07-31 2020-08-18 Cohesity, Inc. Replication of data using chunk identifiers
US10609139B2 (en) * 2017-08-10 2020-03-31 Vmware, Inc. Coordinator ownership authentication in a distributed system with multiple storage object coordinators
CN107360041A (zh) * 2017-08-18 2017-11-17 郑州云海信息技术有限公司 一种网络管理方法及装置
US10635632B2 (en) 2017-08-29 2020-04-28 Cohesity, Inc. Snapshot archive management
US11321192B2 (en) 2017-09-07 2022-05-03 Cohesity, Inc. Restoration of specified content from an archive
US11874805B2 (en) 2017-09-07 2024-01-16 Cohesity, Inc. Remotely mounted file system with stubs
US10719484B2 (en) 2017-09-07 2020-07-21 Cohesity, Inc. Remotely mounted file system with stubs
US10614028B2 (en) 2017-09-14 2020-04-07 Microsoft Technology Licensing, Llc Network traffic routing in distributed computing systems
CN109522902B (zh) 2017-09-18 2023-07-07 微软技术许可有限责任公司 空-时特征表示的提取
CN107707639A (zh) * 2017-09-22 2018-02-16 郑州云海信息技术有限公司 一种虚拟子目录管理方法、装置、设备及存储介质
US10852966B1 (en) * 2017-10-18 2020-12-01 EMC IP Holding Company, LLC System and method for creating mapped RAID group during expansion of extent pool
US10852951B1 (en) * 2017-10-18 2020-12-01 EMC IP Holding Company, LLC System and method for improving I/O performance by introducing extent pool level I/O credits and user I/O credits throttling on Mapped RAID
CN107770170B (zh) * 2017-10-18 2020-08-18 陕西云基华海信息技术有限公司 一种数据共享平台系统
US10877992B2 (en) * 2017-11-30 2020-12-29 International Business Machines Corporation Updating a database
US10733110B1 (en) * 2017-12-04 2020-08-04 Amazon Technologies, Inc. Collecting statistics for persistent memory
US10802932B2 (en) 2017-12-04 2020-10-13 Nxp Usa, Inc. Data processing system having lockstep operation
WO2019122971A1 (en) * 2017-12-20 2019-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Datafall: a policy-driven algorithm for decentralized placement and reorganization of replicated data
US10866963B2 (en) 2017-12-28 2020-12-15 Dropbox, Inc. File system authentication
CN108334333B (zh) * 2018-01-05 2021-07-23 武汉斗鱼网络科技有限公司 一种源代码库更新方法及装置
US10972335B2 (en) 2018-01-24 2021-04-06 Hewlett Packard Enterprise Development Lp Designation of a standby node
US10936540B2 (en) 2018-03-14 2021-03-02 Netapp, Inc. Methods for accelerating storage media access and devices thereof
CN108536554A (zh) * 2018-04-26 2018-09-14 威海海洋职业学院 一种数据文件的备份方法
US11086826B2 (en) 2018-04-30 2021-08-10 Nutanix, Inc. Virtualized server systems and methods including domain joining techniques
US10853327B2 (en) 2018-05-25 2020-12-01 Gbt Technologies Inc. Systems and methods of mobile database management and sharing
CN110659250B (zh) * 2018-06-13 2022-02-22 中国电信股份有限公司 文件处理方法和系统
US11194680B2 (en) 2018-07-20 2021-12-07 Nutanix, Inc. Two node clusters recovery on a failure
US11216420B2 (en) * 2018-07-31 2022-01-04 Nutanix, Inc. System and method for high replication factor (RF) data replication
JP7111882B2 (ja) 2018-08-02 2022-08-02 ヒタチ ヴァンタラ エルエルシー サーバ情報の分散回復
US10917314B1 (en) * 2018-08-08 2021-02-09 Amazon Technologies, Inc. Distributed health management using peer leases
CN110825461B (zh) * 2018-08-10 2024-01-05 北京百度网讯科技有限公司 数据处理方法和装置
US11068440B2 (en) * 2018-08-17 2021-07-20 Jimmy C Lin Application-specific computing system and method
EP3623955A1 (de) * 2018-09-13 2020-03-18 Siemens Aktiengesellschaft Verfahren zum erzeugen von identifikatoren für informationseinheiten in einem verteilten system
US10765952B2 (en) 2018-09-21 2020-09-08 Sony Interactive Entertainment LLC System-level multiplayer matchmaking
US11086616B2 (en) * 2018-09-25 2021-08-10 Vmware, Inc. Near zero downtime application upgrade
US10695671B2 (en) 2018-09-28 2020-06-30 Sony Interactive Entertainment LLC Establishing and managing multiplayer sessions
CN109271390B (zh) * 2018-09-30 2022-03-01 天津大学 一种基于神经网络的索引数据结构及其数据检索方法
US10944850B2 (en) 2018-10-29 2021-03-09 Wandisco, Inc. Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
CN111936960B (zh) * 2018-12-25 2022-08-19 华为云计算技术有限公司 分布式存储系统中数据存储方法、装置及计算机程序产品
US11237963B2 (en) * 2019-02-01 2022-02-01 Red Hat, Inc. Shared filesystem metadata caching
US10944801B1 (en) * 2019-02-25 2021-03-09 Amazon Technologies, Inc. Serverless signaling in peer-to-peer session initialization
US11775475B2 (en) * 2019-03-05 2023-10-03 Microsoft Technology Licensing, Llc Deferred path resolution during container deployment
US11106554B2 (en) 2019-04-30 2021-08-31 JFrog, Ltd. Active-active environment control
TWI701557B (zh) * 2019-05-24 2020-08-11 威聯通科技股份有限公司 多複製資料源系統的資料讀取方法
US11388136B2 (en) 2019-06-18 2022-07-12 Nutanix, Inc. Dynamic distributed service location discovery
US11169723B2 (en) 2019-06-28 2021-11-09 Amazon Technologies, Inc. Data storage system with metadata check-pointing
US11556367B2 (en) * 2019-08-06 2023-01-17 Microsoft Technology Licensing, Llc Dynamic image composition for container deployment
US12210912B2 (en) * 2019-09-11 2025-01-28 Synchronoss Technologies, Inc Method and system for uniform, consistent, stateless and deterministic consistent hashing for fixed size partitions
US11853615B2 (en) * 2019-10-16 2023-12-26 Hitachi Vantara Llc Including network storage with direct attached storage
US11290531B2 (en) 2019-12-04 2022-03-29 Dropbox, Inc. Immediate cloud content item creation from local file system interface
CN111028931B (zh) * 2019-12-11 2023-08-22 医渡云（北京）技术有限公司 医疗数据处理方法及装置、电子设备、存储介质
GB2590661B (en) * 2019-12-23 2022-02-09 Graphcore Ltd Sync network
CN115397766A (zh) 2020-01-08 2022-11-25 纳努森有限公司 使用固态半导体工艺的beol金属层构建的mems装置
US11893064B2 (en) * 2020-02-05 2024-02-06 EMC IP Holding Company LLC Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace
CN111355777A (zh) * 2020-02-14 2020-06-30 西安奥卡云数据科技有限公司 一种分布式文件系统的管理方法装置及服务器
CN111475469B (zh) * 2020-03-19 2021-12-14 中山大学 Kubernetes用户态应用中基于虚拟文件系统的小文件存储优化系统
CN111538789B (zh) * 2020-04-27 2023-08-15 咪咕文化科技有限公司 数据同步方法、装置、电子设备及存储介质
EP4143699A4 (en) * 2020-04-28 2024-05-08 Editshare, LLC HETEROGENEOUS MEDIA EDITING ACROSS STORAGE PLATFORMS
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up
US11182096B1 (en) * 2020-05-18 2021-11-23 Amazon Technologies, Inc. Data storage system with configurable durability
US11727283B2 (en) * 2020-05-19 2023-08-15 International Business Machines Corporation Rule distribution across instances of rules engine
JP2022029976A (ja) * 2020-08-06 2022-02-18 富士通株式会社 メタデータ管理プログラム及び情報処理装置
US11487701B2 (en) 2020-09-24 2022-11-01 Cohesity, Inc. Incremental access requests for portions of files from a cloud archival storage tier
CN114328375A (zh) * 2020-09-29 2022-04-12 伊姆西Ip控股有限责任公司 用于存储管理的方法、设备和计算机程序产品
US12050553B2 (en) * 2020-10-01 2024-07-30 Netapp, Inc. Supporting a lookup structure for a file system implementing hierarchical reference counting
US12248435B2 (en) 2021-03-31 2025-03-11 Nutanix, Inc. File analytics systems and methods
US11436104B2 (en) * 2020-10-29 2022-09-06 EMC IP Holding Company LLC Decreasing data restoration times using advanced configuration and power interface (ACPI)
US11537555B2 (en) * 2020-12-15 2022-12-27 EMC IP Holding Company LLC Managing network shares utilizing filesystem snapshots comprising metadata characterizing network shares
US11611618B2 (en) 2020-12-31 2023-03-21 Nutanix, Inc. Orchestrating allocation of shared resources in a datacenter
US11734044B2 (en) 2020-12-31 2023-08-22 Nutanix, Inc. Configuring virtualization system images for a computing cluster
CN112783444A (zh) * 2021-01-18 2021-05-11 深圳市科思科技股份有限公司 集群磁盘共享方法、系统及存储介质
US11573931B2 (en) * 2021-01-21 2023-02-07 Microsoft Technology Licensing, Llc Smart near-real-time folder scan based on a breadth first search
CN112905557B (zh) * 2021-03-03 2023-01-24 山东兆物网络技术股份有限公司 支持异步提交的海量文件整合存储方法及系统
US12131192B2 (en) 2021-03-18 2024-10-29 Nutanix, Inc. Scope-based distributed lock infrastructure for virtualized file server
US12248434B2 (en) 2021-03-31 2025-03-11 Nutanix, Inc. File analytics systems including examples providing metrics adjusted for application operation
US12242455B2 (en) 2021-03-31 2025-03-04 Nutanix, Inc. File analytics systems and methods including receiving and processing file system event data in order
US12197398B2 (en) 2021-03-31 2025-01-14 Nutanix, Inc. Virtualized file servers and methods to persistently store file system event data
US11561935B2 (en) 2021-06-17 2023-01-24 Netapp, Inc. Methods for ensuring correctness of file system analytics and devices thereof
US11595495B2 (en) 2021-07-30 2023-02-28 Morgan Stanley Services Group Inc. Process isolation via application-level blue-green topology
US20230046788A1 (en) * 2021-08-16 2023-02-16 Capital One Services, Llc Systems and methods for resetting an authentication counter
US12072770B2 (en) 2021-08-19 2024-08-27 Nutanix, Inc. Share-based file server replication for disaster recovery
US12117972B2 (en) 2021-08-19 2024-10-15 Nutanix, Inc. File server managers and systems for managing virtualized file servers
US12021963B2 (en) 2021-08-25 2024-06-25 Pensando Systems Inc. Methods and systems for distributed high speed state synchronization
US20230185559A1 (en) * 2021-10-29 2023-06-15 JFrog Ltd. Managing a federated software repository across multiple devices
TWI806341B (zh) * 2022-01-06 2023-06-21 威聯通科技股份有限公司 主機的容器系統、動態掛載主機資料至容器的方法及應用程式
US12153690B2 (en) 2022-01-24 2024-11-26 Nutanix, Inc. Consistent access control lists across file servers for local users in a distributed file server environment
US12182264B2 (en) 2022-03-11 2024-12-31 Nutanix, Inc. Malicious activity detection, validation, and remediation in virtualized file servers
US12153495B2 (en) * 2022-07-18 2024-11-26 Dell Products L.P. Preventing attacks on protection storage using delete restriction
US12189499B2 (en) 2022-07-29 2025-01-07 Nutanix, Inc. Self-service restore (SSR) snapshot replication with share-level file system disaster recovery on virtualized file servers
US11892919B1 (en) * 2023-06-07 2024-02-06 Intuit Inc. Zero downtime and zero failure cutover
CN118410094B (zh) * 2024-07-01 2024-09-06 北京科杰科技有限公司 一种网络化的Hive表数据加载方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200814619A (en) * 2006-09-15 2008-03-16 Thomson Licensing Method for file repair system for distributing content

Family Cites Families (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555404A (en) 1992-03-17 1996-09-10 Telenor As Continuously available database server having multiple groups of nodes with minimum intersecting sets of database fragment replicas
US5548724A (en) 1993-03-22 1996-08-20 Hitachi, Ltd. File server system and file access control method of the same
US5504897A (en) * 1994-02-22 1996-04-02 Oracle Corporation Method and apparatus for processing electronic mail in parallel
US5956715A (en) * 1994-12-13 1999-09-21 Microsoft Corporation Method and system for controlling user access to a resource in a networked computing environment
US5832529A (en) * 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
US5905990A (en) 1997-06-23 1999-05-18 International Business Machines Corporation File system viewpath mechanism
FR2792087B1 (fr) * 1999-04-07 2001-06-15 Bull Sa Procede d'amelioration des performances d'un systeme multiprocesseur comprenant une file d'attente de travaux et architecture de systeme pour la mise en oeuvre du procede
US7428540B1 (en) * 2000-03-03 2008-09-23 Intel Corporation Network storage system
US7565651B1 (en) * 2000-05-25 2009-07-21 Oracle International Corporation Parallel task scheduling system for computers
US20020124137A1 (en) * 2001-01-29 2002-09-05 Ulrich Thomas R. Enhancing disk array performance via variable parity based load balancing
WO2002071191A2 (en) * 2001-03-02 2002-09-12 Kasenna, Inc. Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
AU2002313583A1 (en) * 2001-08-01 2003-02-17 Actona Technologies Ltd. Virtual file-sharing network
US7685126B2 (en) * 2001-08-03 2010-03-23 Isilon Systems, Inc. System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
US7240211B2 (en) * 2001-10-09 2007-07-03 Activcard Ireland Limited Method of providing an access request to a same server based on a unique identifier
US20050091376A1 (en) * 2001-10-12 2005-04-28 Helfman Nadav B. Apparatus and method for optimized and secured reflection of network services to remote locations
CA2408766A1 (en) * 2001-10-17 2003-04-17 Telecommunications Research Laboratory Content delivery network bypass system
JP4154893B2 (ja) 2002-01-23 2008-09-24 株式会社日立製作所 ネットワークストレージ仮想化方法
US7010528B2 (en) 2002-05-23 2006-03-07 International Business Machines Corporation Mechanism for running parallel application programs on metadata controller nodes
US20030225899A1 (en) * 2002-05-28 2003-12-04 Murphy Walter Vincent Enhancing system performance using a network-based multi-processing technique
WO2004044786A2 (en) * 2002-11-08 2004-05-27 Manugistics, Inc. Design for highly-scalable, distributed replenishment planning algorithm
EP1561159A4 (en) 2002-11-12 2007-08-29 Zetera Corp ELECTRICAL DEVICES WITH IMPROVED COMMUNICATION
US20040153473A1 (en) * 2002-11-21 2004-08-05 Norman Hutchinson Method and system for synchronizing data in peer to peer networking environments
US7080060B2 (en) * 2003-01-08 2006-07-18 Sbc Properties, L.P. System and method for intelligent data caching
US7391772B2 (en) * 2003-04-08 2008-06-24 Intel Corporation Network multicasting
US7143170B2 (en) * 2003-04-30 2006-11-28 Akamai Technologies, Inc. Automatic migration of data via a distributed computer network
US7577750B2 (en) * 2003-05-23 2009-08-18 Microsoft Corporation Systems and methods for peer-to-peer collaboration to enhance multimedia streaming
JP4291077B2 (ja) * 2003-07-29 2009-07-08 株式会社日立製作所 分散ストレージ装置のファイル管理方法及び分散ストレージシステム
GB0319251D0 (en) * 2003-08-15 2003-09-17 British Telecomm System and method for selecting data providers
US20050080982A1 (en) 2003-08-20 2005-04-14 Vasilevsky Alexander D. Virtual host bus adapter and method
US20050086384A1 (en) * 2003-09-04 2005-04-21 Johannes Ernst System and method for replicating, integrating and synchronizing distributed information
US8086747B2 (en) 2003-09-22 2011-12-27 Anilkumar Dominic Group-to-group communication over a single connection
US7631100B2 (en) * 2003-10-07 2009-12-08 Microsoft Corporation Supporting point-to-point intracluster communications between replicated cluster nodes
US7526672B2 (en) * 2004-02-25 2009-04-28 Microsoft Corporation Mutual exclusion techniques in a dynamic peer-to-peer environment
JP4272105B2 (ja) * 2004-04-27 2009-06-03 株式会社日立製作所 ストレージグループ設定方法および装置
US20060015505A1 (en) 2004-07-16 2006-01-19 Henseler David A Role-based node specialization within a distributed processing system
US7657581B2 (en) * 2004-07-29 2010-02-02 Archivas, Inc. Metadata management for fixed content distributed data storage
US7688838B1 (en) * 2004-10-19 2010-03-30 Broadcom Corporation Efficient handling of work requests in a network interface device
CA2483760A1 (en) 2004-10-25 2006-04-25 Thomas E. Chalker System and method for a secure, scalable wide area file system
US20060114847A1 (en) * 2004-12-01 2006-06-01 Rachida Dssouli User agent and super user agent for cluster-based multi-party conferencing in ad-hoc networks
US20060224687A1 (en) * 2005-03-31 2006-10-05 Popkin Laird A Method and apparatus for offline cooperative file distribution using cache nodes
US7983943B2 (en) * 2005-05-27 2011-07-19 Xerox Corporation Method and system for workflow process node synchronization
US7760727B2 (en) * 2005-06-27 2010-07-20 Lsi Corporation System & method for fabric storage utilizing multicast with distributed intelligence
US20070041388A1 (en) * 2005-08-17 2007-02-22 Russell Thomas C Device having an embedded Ethernet networking automated link for facilitating configuration of the device and connection of the device to a network
US8010485B1 (en) 2005-10-20 2011-08-30 American Megatrends, Inc. Background movement of data between nodes in a storage cluster
US7643491B2 (en) * 2005-12-16 2010-01-05 Microsoft Corporation Scheduling connections between peers in a peer-to-peer file sharing environment
CN101371241B (zh) * 2006-01-20 2012-09-12 美国唯美安视国际有限公司 网络安全系统和方法
US8510404B2 (en) * 2006-04-03 2013-08-13 Kinglite Holdings Inc. Peer to peer Synchronization system and method
US20080077635A1 (en) * 2006-09-22 2008-03-27 Digital Bazaar, Inc. Highly Available Clustered Storage Network
KR101490327B1 (ko) * 2006-12-06 2015-02-05 퓨전-아이오, 인크. 뱅크 인터리브를 이용한 솔리드-스테이트 스토리지의 명령 관리 장치, 시스템 및 방법
US20080147821A1 (en) * 2006-12-19 2008-06-19 Dietrich Bradley W Managed peer-to-peer content backup service system and method using dynamic content dispersal to plural storage nodes
US20080154976A1 (en) * 2006-12-21 2008-06-26 Ogle David M Policy management of local document replica leasing in a collaborative environment
US7657769B2 (en) * 2007-01-08 2010-02-02 Marcy M Scott N-way synchronization of data
US20080320011A1 (en) * 2007-06-20 2008-12-25 Microsoft Corporation Increasing file storage scale using federated repositories
US20130100947A9 (en) * 2007-07-09 2013-04-25 Qualcomm Incorporated Methods and apparatus for timing synchronization using multiple different timing signal sources
US8090685B2 (en) * 2007-09-14 2012-01-03 Microsoft Corporation Knowledge based synchronization of subsets of data with no move condition
US8037197B2 (en) * 2007-10-26 2011-10-11 International Business Machines Corporation Client-side selection of a server
US8180747B2 (en) * 2007-11-12 2012-05-15 F5 Networks, Inc. Load sharing cluster file systems
US8432908B2 (en) * 2008-02-06 2013-04-30 Broadcom Corporation Efficient packet replication
TWI476610B (zh) * 2008-04-29 2015-03-11 Maxiscale Inc 同級間冗餘檔案伺服器系統及方法
US8301654B2 (en) * 2009-02-24 2012-10-30 Hitachi, Ltd. Geographical distributed storage system based on hierarchical peer to peer architecture
US8769105B2 (en) * 2012-09-14 2014-07-01 Peaxy, Inc. Software-defined network attachable storage system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200814619A (en) * 2006-09-15 2008-03-16 Thomson Licensing Method for file repair system for distributing content

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Butt, Ali Raza and Johnson, Troy A. and Zheng, Yili and Hu, Y. Charlie. Kosha: A Peer-to-Peer Enhancement for the Network File System. . In J. Grid Comput., (4) 3: 323-341, Year 2006. Broekstra, Jeen and Ehrig, Marc and Haase, Peter and van Harmelen, Frank and Kampman, Arjohn and Sabou, Marta and Siebes, Ronny and Staab, Steffen and Stuckenschmidt, Heiner and Tempich, Christoph. A Metadata Model for Semantics-Based Peer-to-Peer Systems . Proceedings of the WWW'03 Workshop on Semantics in Peer-to-Peer and Grid Computing. Year 2003. Delmastro, Franca and Passarella, Andrea and Conti, Marco. P2P multicast for pervasive ad hoc networks. . In Pervasive and Mobile Computing, (4) 1: 62-91, Available online 4 April 2007. Daswani, Neil and Garcia-Molina, Hector and Yang, Beverly. Open Problems in Data-Sharing Peer-to-Peer Systems. . ICDT. editor(s) Calvanese, Diego and Lenzerini, Maurizio and Motwani, Rajeev. Lecture Notes in Computer Science, (2572) 1-15, Springer, Year 2003. *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI688869B (zh) * 2015-05-27 2020-03-21 香港商阿里巴巴集團服務有限公司 資料即時傳輸的方法和裝置
TWI755417B (zh) * 2016-10-18 2022-02-21 香港商阿里巴巴集團服務有限公司 計算任務分配方法、流計算任務的執行方法、控制伺服器、流計算中心伺服器集群、流計算系統及異地多活系統
TWI747349B (zh) * 2020-06-30 2021-11-21 大陸商合肥沛睿微電子股份有限公司 儲存裝置之低級格式化方法
TWI820814B (zh) * 2022-07-22 2023-11-01 威聯通科技股份有限公司 儲存系統與其硬碟恢復方法
TWI860122B (zh) * 2023-10-12 2024-10-21 技嘉科技股份有限公司 編號式檔案的資料結構、交握方法及交握系統

Also Published As

Publication number Publication date
US20130066830A1 (en) 2013-03-14
WO2009134772A3 (en) 2010-04-08
US20130018928A1 (en) 2013-01-17
US20090271412A1 (en) 2009-10-29
US20130066931A1 (en) 2013-03-14
US20180011874A1 (en) 2018-01-11
US20130018930A1 (en) 2013-01-17
US9740707B2 (en) 2017-08-22
US20130013619A1 (en) 2013-01-10
US8856233B2 (en) 2014-10-07
US9122698B2 (en) 2015-09-01
US20130013655A1 (en) 2013-01-10
US9213719B2 (en) 2015-12-15
US20130013654A1 (en) 2013-01-10
US9396206B2 (en) 2016-07-19
US8296398B2 (en) 2012-10-23
US20130013675A1 (en) 2013-01-10
US20130013639A1 (en) 2013-01-10
US9305015B2 (en) 2016-04-05
US9213720B2 (en) 2015-12-15
TW201007489A (en) 2010-02-16
WO2009134772A2 (en) 2009-11-05
US9449019B2 (en) 2016-09-20

Similar Documents

Publication Publication Date Title
TWI476610B (zh) 同級間冗餘檔案伺服器系統及方法
ES2881606T3 (es) Sistema de ficheros geográficamente distribuido que usa replicación de espacio de nombres coordinada
US7512673B2 (en) Rule based aggregation of files and transactions in a switched file system
CA2734675C (en) Shared namespace for storage clusters
CA2512312C (en) Metadata based file switch and switched file system
US7509322B2 (en) Aggregated lock management for locking aggregated files in a switched file system
US6950833B2 (en) Clustered filesystem
US7617292B2 (en) Multi-class heterogeneous clients in a clustered filesystem
US8005953B2 (en) Aggregated opportunistic lock and aggregated implicit lock management for locking aggregated files in a switched file system
US9275058B2 (en) Relocation of metadata server with outstanding DMAPI requests
US6889249B2 (en) Transaction aggregation in a switched file system
US20190370362A1 (en) Multi-protocol cloud storage for big data and analytics
US20040133606A1 (en) Directory aggregation for files distributed over a plurality of servers in a switched file system
Poveda SDKV: A Smart and Distributed Key-Value Store for the Edge-Cloud Continuum
Pye et al. MASTER OF SCIENCE in COMPUTER SCIENCE

Legal Events

Date Code Title Description
MM4A Annulment or lapse of patent due to non-payment of fees