？GFS將機器故障視為正常現象，可以很好地處理系統故障。GFS系統通常部署在數百甚至數千臺廉價服務器上，相當壹部分廉價服務器會部署GFS客戶端來訪問GFS服務，所以應用程序故障、操作系統bug、連接故障、網絡故障，甚至機器電源故障都是經常發生的故障。GFS系統可以支持系統監控、故障檢測、容錯和自動恢復，提供非常高的可靠性。其次，GFS系統中的文件壹般都是大文件，大多數場景下文件操作都是追加而不是覆蓋。壹旦文件被寫入，大多數操作都是讀取文件並按順序讀取。
？GFS提供了非標準(如POSIX)文件系統接口，支持創建、刪除、打開、關閉、讀寫。此外，GFS支持快照和記錄追加操作。Snapshot可以以非常低的成本創建文件或目錄樹的副本，record append可以支持多個客戶端並發地向同壹個文件追加數據，同時保證每個客戶端追加操作的原子性。
？Master記錄文件系統的元數據，包括命名空間、權限控制信息、文件到塊的映射以及塊的分布。Master還負責組塊的租用管理、無用組塊的垃圾收集、組塊遷移等。Master定期與chunkserver通信，向chunkserver發送指令，並收集chunkserver的狀態。GFS客戶端通過GFS API與GFS系統通信(讀取和寫入數據)。客戶端請求master獲取元數據，真正的讀寫數據是直接和chunkserver交互。客戶端和chunkserver都不會緩存文件數據。因為大多數應用程序基於API流讀取大文件，並且系統中有太多的文件數據，所以客戶端緩存文件數據是沒有意義的。Chunkserver的Linux緩沖區緩存和頻繁訪問的數據被緩存，chunkserver也不緩存文件數據。
？單點master大大簡化了系統設計，因為master知道所有元信息，所以可以執行更復雜的塊位置分配和復制策略。但讀寫數據時必須減少master的參與，避免單點master被稱為系統瓶頸。客戶端不會通過master讀寫文件數據，但是會向master發送請求，查詢chunk的位置分布，然後客戶端會緩存chunk的分布信息，然後直接向chunkserver讀寫數據。壹般的閱讀過程如下:
1.客戶端根據文件名、字節偏移量和塊大小計算要讀取的文件的塊索引。
2.客戶端通過文件名和塊索引向主機查詢塊的分布情況。
3.主服務器回復塊處理程序和副本分發。
4.客戶端緩存塊的元信息，關鍵字由文件名和塊索引組成。
5.客戶端從組塊的分布信息中找到最近的組塊服務器，並發送查詢請求。查詢請求包括塊處理器和字節範圍。對同壹個塊的後續查詢不需要再次向主服務器查詢元信息，因為客戶端已經緩存了元信息。
？Chunk size是GFS系統的關鍵參數，通常設置為64MB，遠大於文件系統的塊大小。每個塊的副本作為Linux文件存儲在chunkserver所在的機器上。我們所做的是將塊大小設置為64MB，主要考慮以下幾點:
1，可以減少客戶端訪問主機查詢元信息的次數，減輕主機的訪問壓力。因為組塊大小設計比較大，所以順序訪問超大文件時，組塊數量少，客戶端緩存組塊元信息，所以訪問master的次數會減少。甚至客戶端可以緩存所有文件的chunk的元信息，即使文件被隨機讀取，主端也不會成為系統性能的瓶頸。
2.可以減少網絡開銷，保持客戶端和chunkserver之間的TCP連接，執行更多的chunk操作。
3.它可以減少需要記錄在主機上的存儲器中的元數據數據的量，並減少主機的存儲器占用。
？大尺寸缺點是小文件包含很少的塊，甚至只有壹個。在這種情況下，當多個客戶端查詢高並發的小文件時，相應的組塊就會成為熱點。事實上，這種情況在GFS系統中很少發生，因為客戶端的大部分操作都是順序讀取大文件。然而，考慮以下場景:我們將服務的二進制文件部署到GFS系統，然後數百個服務器同時查詢二進制文件並啟動服務。此時，二進制文件副本所在的chunkserver會立即成為查詢瓶頸。當然，這種場景下的問題可以通過增加副本數量，分散服務器的查詢時間來解決。
？Master主要存儲三種類型的元數據:文件和塊名稱空間、從文件到塊的映射信息以及塊的副本分布。所有元數據都存儲在主服務器的內存中。前兩種元信息可以持久存儲，操作日誌存儲在主機的本地磁盤上，備份日誌存儲在遠程機器上。Master並不持久存儲chunk的副本分布信息，而是通過與chunkserver交互獲取chunkserver上的chunk信息。
4.1內存數據結構
？元信息在內存中，所有的主操作都非常快。此外，master還可以在後臺高效、定時地掃描所有元數據，進行垃圾收集、副本修復、平衡等。元數據是記錄在內存中的，所以GFS系統會更加關註chunk的數量和master的可用內存。但在實際場景中，這不是問題。每個64MB區塊的元數據小於64個字節，大多數區塊都是滿容量存儲的，只是文件最後壹個區塊的空間沒有完全占用。因為文件命名空間是通過前綴壓縮存儲的，所以單個文件的元信息少於64個字節。如果需要擴展系統規模，可以簡單的增加主控的內存。相對於系統的高可靠性、高性能和簡單性，增加內存是成本最小的。
4.2組塊分布
？我們不是持久存儲chunk的副本分布信息，而是在主服務器啟動時向chunkserver查詢其chunk信息，然後通過heartbeat不斷更新主服務器的副本分布信息，與chunkserver的數據保持壹致。起初，GFS試圖將chunk的分布信息永久存儲在主服務器中，後來發現通過主服務器啟動拉取chunk信息，然後通過heartbeat進行同步更簡單。因為，chunkserver在頻繁加入、退出、改名、重啟的時候，維護master的Chunkmetadata的正確性會非常困難。從另壹個角度來看，集群中只有chunkserver上報的塊信息才是最真實的塊分布，因為主節點不需要自己維護壹個塊分布狀態，只需要服從chunkserver的狀態報告即可。
4.3操作日誌
？該日誌記錄GFS集群數據更改的歷史。操作日誌對於GFS來說非常重要，因為它不僅是元數據的持久記錄，還記錄了並發操作的時間順序。因為操作日誌非常重要，所以必須可靠地存儲。在元數據的改變被持久化之前，客戶端看不到數據的改變。當客戶端修改數據時，需要將操作記錄保存在多個遠程機器上，只有將操作記錄永久保存在本地和遠程，客戶端的數據更改才會成功。
？您可以通過回放操作日誌來恢復文件系統。為了減少系統啟動時的重播時間，有必要減少重播日誌的數量。主服務器可以定期存儲元數據的檢查點。當主服務器重新啟動時，它可以從檢查點加載元數據，然後回放檢查點之後的壹些日誌。
1.客戶端向主服務器查詢壹個chunk的主服務器所在的chunkserver和其他副本的分布情況。如果沒有主花，主花將選擇壹朵作為該花塊的主花。
2.主回復客戶端主副本和其他副本的分發信息。客戶端緩存返回的元數據。
3.客戶端發送數據的所有副本。客戶端可以以任何順序執行。每個chunkserser在內存的LRUbuffer中記錄數據。
4.在所有拷貝成功返回接收到的數據後，客戶端將向主節點發送寫入請求。Primary將為每個數據更改請求附加壹個序列號，數據更改按序列號的順序執行。
5.主服務器將數據更改同步到其他副本服務器，副本服務器也根據序列號執行數據更改。
6.主服務器收到其他副本回復的數據操作完成。
7.primary返回客戶端結果。在此期間發生的所有錯誤都將報告給客戶。
？GFS集群通常有數百個chunkserver，分布在多個機架上。Chunkserver還將接收來自該機架或其他機架中的數百個客戶端的查詢請求。不同機架中的服務器流量可以通過壹個或多個交換機轉發。chunk的副本分布選擇策略的主要目的是盡可能提高數據的可靠性和可用性，同時盡可能充分利用網絡帶寬。因此，僅僅跨機器部署副本是不夠的。GFS跨機架部署副本，這可確保當機架損壞或脫機時，至少有壹份數據塊副本可用。
？將在以下情況下創建區塊的副本:創建區塊、復制修復、重新平衡。當master創建塊時，它選擇存儲塊副本的chunkserver。主要考慮以下幾點:
1.新副本所在的chunkserver的磁盤利用率低於系統平均水平。
2.限制最近壹段時間內每個chunkserver創建的塊的數量。
3.每個區塊的所有副本不能在壹個機架中。
？Chunk的副本數量少於特定數量。是的，師父會復印壹份。當chunkserver關閉，或者chunkserver報告其副本損壞，或者chunkserver所在機器的磁盤損壞等等時，可能會發生這種情況。每個塊復制任務都有壹個優先級，在子主機中按從高到低的順序排隊等待執行。Master還會定期掃描當前副本的分布情況，壹旦發現磁盤使用或機器負載不平衡，就會啟動負載平衡操作。無論是組塊創建、組塊復制還是負載均衡，選擇組塊副本位置的策略都是壹樣的，需要限制副本修復和均衡的速度，否則會影響系統的正常讀寫服務。
？谷歌的成功表明，單壹的主設計師是可行的。這不僅簡化了系統，而且可以很好地實現壹致性。考慮到性能，GFS提出了“至少原子地添加記錄”的壹致性模型。每個chunk的修改通過租借授權給chunkserver，這樣減輕了master的負荷，通過管道復制多個副本來減少延遲。Master維護大量元數據，需要設計高效的數據結構，並保證占用內存少，支持快照操作。b樹支持COW可以滿足需求，但是實現真的挺復雜的。