GFS論文：
Design Assumptions：
Failure detection, recovery
對大文件multi-gb優化
Large streaming read。（支持small random read但不是主要場景）
Large, sequential write, appending to theend of the file。一旦寫入，很少更改。（支持隨機寫，但不是主要場景，不對其優化）
多個client併發append同一個文件
高帶寬比低延遲重要
接口：
Create/delete/open/close/read/write/snapshot(createa copy of a file or directory)/record append(多個client併發append同一個文件
)
架構：
Single master, multiple chunk servers.
Chunk: 基本分配單元，master會分配全局唯一64位 chunk handle
Chunk server將chunk存爲linux file，指定chunk handle和byte range來read/write數據。每個chunk複製多份。
Master維護文件系統meta data。包括namespace, access control信息，文件-chunk的映射，chunk的位置，Chunk的管理。（chunk lease management, garbagecollection of orphaned chunks, and chunk migration between chunkservers）.master和chunk server之間heart beat傳遞指令、收集狀態信息。
Meta data操作，Client需要和master通信，但數據操作直接通過chunk server(singlemaster可能成爲瓶頸，所以需要儘量減少操作)。Client/chunkserver都不cache filedata.(使用場景是streamingthrough large files。對於chunk server來講，chunk由local file實現，linux 文件系統會cache)，但client會cache metadata.
讀的過程：
app/client library將filename,offset轉換爲該文件的chunk index（由於chunk固定大小），將<filename, chunk index>發送給master，master回覆client <chunk handle，location of replicas>. Client將其cache。然後client發送請求<chunk handle， byte range>到某一replica。之後對該chunk的讀就不再需要client-master通信，除非cache失效或文件重新打開。
Chunk size：64M。每個chunk存爲一個Linux file.
Chunk過大，若有hotspot怎麼辦？多個client頻繁讀寫一個小文件，可能只有一個chunk---不是google主要場景。
Metadata:
Fileand chunk namespace
Mappingfrom files to chunks
Thelocation of each chunk’s replicas
所有meta data保存在內存。前兩者會記錄operation log，寫入master本地磁盤，並複製到其他機器（解決master crash問題）
Master不在本地存儲chunk位置，在啓動時或一個chunkserver加入時，會讓chunkserver報告chunk信息。(避免了chunk server加入、退出cluster、失效、重啓等的數據同步問題，而且chunk server對這個數據是最有話語權的)
Inmemory data structure:
後臺週期性scan數據結構：chunk garbage collection，re-replicate when chunk serverfails，chunkmigration。
Operationlog：
Serve as a logical timeline which definethe order of concurrent operations
Client-master：若有更改，只有當flush log併發送到replica之後纔會迴應client。Flush時會合並日志記錄以減少開銷。
Master recovery依賴於replay log。爲了減少replay時間，日誌要儘量小。因此設置checkpoint，日誌增大到一定尺寸就checkpoint its state。（checkpoint是B tree結構）
新checkpoint創建不會delay incoming改變。The master switch to a new logfile and create new checkpoint in a separate thread。
一致性模型：
File namespace操作比如file creation是原子的。
一個file region發生數據更改後的狀態取決於更改類型，更改是否成功，是否有併發更改。
Region的狀態：
consistent:
ifall client will always see the same data, regardless of which replica they readfrom.
defined:
afterfile data mutation if it is consistent and the clients will see what themutation writes in its entirety.
如果一個mutation沒有concurrent writers。The region is defined—all clientswill always see the mutation
Concurrent successful mutation leave theregion undefined but consistent.—all clients see the same data, but itmay not reflect what anyone mutation has written.
A failed mutation makes regioninconsistent.---different cilents may see differentdata at different time
Data mutation類型：write, record append.
Write操作在應用指定的offset寫入數據，
Record append: 以原子方式append至少一次，但是在GFS選擇的offset。
Gfs對一個chunk的replic的更改採用相同順序
每個Chunk有version number。---檢測stale replica。Stale的replica不apply mutation
Client cache chunk location失效窗口：cache entries’s timeout或next open of file
實際上所有應用修改文件的方式都是append，而不是overwrite。
Application的checkpoint。每寫一段就check一次？
實現流程：
使用lease保證在所有replica上使用一致的修改操作順序。原則是儘量減少master端的管理開銷。
Master將chunk lease授權給其中一個replica，稱爲primary。Primary負責制定lease內的修改操作順序。
Lease初始超時60秒，但若chunk上更改一直在進行，primary可以無限申請延期。
Extension request和grant包括在master和chunk server間的heat beat信息裏。
Master可能會在超時之前提前revoke一個lease。（比如master想disable一個正在rename的文件上的更改）。
即便master和primary失去通信，master可以在lease超時後grant給另外一個replica新lease.
1. client->server：client請求，對於一個chunk，哪個chunk server擁有當前lease，以及其他replica的位置。如果lease不存在，那麼master將其授權給一個他選擇的replica。
2. master回覆primary標識和其他replica的location. Client將其cache。只有當primary無法聯繫或primary回覆他不再擁有lease時，client才需要和master再次聯繫。
3. client將data push到所有replica？每個chunk server在LRU buffer cache保存這些數據，直到數據被使用或aged out。這種方式解耦了數據流和控制流（section 3.2）
4. 當所有replica確認收到數據後，client發送寫請求到priamry。請求identify了之前push過去的數據。Primary對收到的每一個更改（serialization，可能是多個client發過來的）賦值一個序列號。按順序Apply更改到本地狀態
5. primary將寫請求轉發到其他replica，他們會按primary同樣的順序依次更改。
6. secondary完成更改後會回覆primary。
7. primary回覆client。若有任何replica出錯，出錯信息會返回給client。此時client請求會被認爲失敗，the modified region變爲inconsistent狀態。Client代碼通過retry更改來處理這種錯誤。注意步驟3-7會嘗試幾次，若仍然失敗則會觸發retry邏輯重新做更改。
如果一次寫操作較大跨越了多個chunk，則client代碼將其分爲多次寫操作。因此有可能因併發操作導致被插入或覆蓋，最終導致該文件region fragments from different clients，即所謂的undefined狀態（consistent依然保證）
數據流：
控制流和數據流解耦策略。
控制流：client到primary，然後到其他secondary。
數據流：client將數據以管道模式在chunk server chain中傳遞（線性的鏈式傳遞，而不是其他拓撲結構比如tree），充分利用每個機器的outbound網絡帶寬來傳輸數據
爲儘量避免網絡瓶頸和highlatency鏈路，每個機器將數據傳遞到網絡拓撲中離他最近的機器。
（通過網絡中ip地址精確預估’distance’）
Chunkserver一旦收到一定量數據就開始轉發，採用tcp鏈接。Pipeline機制對google尤其有效因爲他們使用full-duplex鏈路的交換網絡。（發送數據不會影響接收數據）
Atomicrecord append：
Record append操作只指定data，不指定fileoffset。Gfs保證會選擇一個offset，將該數據原子地append至少一次，並將offset返回給client。（傳統實現需要distributed lock manager？？）
這種文件可以當做multiple-producer/single-consumerqueue通信機制或多路歸併結果文件。
Record append操作遵循section 3.1的流程，但在primary上多了一點額外的邏輯。
Client將數據push到所有replica，然後發送請求到primary。Primary檢查將數據append到當前chunk是否會超過chunk最大size。如果是，則將chunk 填充到最大size，並告訴其他replica做同樣事，然後回覆client要在下一個chunk上重複該操作。如果要append的record在chunk size以內，則primary告訴replica在primary所在的offset寫數據，最後返回成功給client。
如果append在某replica失敗，client會retry更改。因此replica上的同一chunk可能包含不同數據，比如某個record的整個或部分duplicate。---GFS並不保證replica上字節相同，只保證數據以原子方式至少寫了一次。即當client收到操作success時，數據必然已經在所有replica的某個chunk上的同一offset寫入。操作完成後所有replica上至少同樣長度。（問題：如何校驗讀到的數據是否正確呢？？）
從一致性模型來看，成功recordappend的region是defined狀態，而intervening region是inconsistent。（應用層面可以處理inconsistent情況）
Snapshot：
快速的拷貝一個文件或目錄樹，對正在進行的更改影響最小化。
如AFS，使用copy-on-write技術來實現snapshot。
當master收到snapshot request，首先revoke 所要操作文件的chunk的outstanding leases（保證了之後對這些chunk的更改要重新和master通信得到lease holder，master也得到機會來創建新的chunk拷貝）
當lease被revoke（或timeout？）後，master首先記錄日誌，然後在內存中複製所要copy的文件或目錄的meta data，新創建的snapshot文件指向源chunks。
Snapshot操作完成後，當client第一次要寫入一個chunkC時，它會向master發送請求以得到當前lease holder。master會意識到該chunk reference count大於1，因此延遲迴復client，先創建一個新的chunkhandler C’，然後告訴所有每個server，根據chunk C在本地來創建一個新的chunk C’，因此所有複製都是本地進行的，避免了網絡開銷。之後master 將lease grant給某一個C’的replica並返回給client。---client並不知道該chunk是剛剛建立的。
Master操作：
All namespace operations。
Namespacemanagement and locking
很多Master操作是很費時的。比如snapshot操作，master要revoke該snapshot所涉及到的所有chunk的lease。因此設計要考慮不能delay其他masteroperation。---master上允許有多個operation在運行，在namespace region上使用lock來保證同步。
與傳統文件系統不同，GFS沒有per-direction數據結構（列出該目錄包含的文件），也不支持別名（hard link orsymbol link）。GFS的namespace是一個lookup table來影射full pathnames到metadata。採用prefix compression後，該lookup table可以保存在內存中。Namespace tree上的每一個節點有一個讀寫鎖。
每個masteroperation運行之前要accquire一系列的鎖。比如，如果路徑是/d1/d2/.../dn/leaf，它需要在/d1，/d1/d2，...，/d1/.../dn上獲得讀鎖，並在/d1/d2/.../dn/leaf上獲得讀鎖或寫鎖。（leaf可以使文件也可以是目錄）
比如，我們要snapshot/home/user到/save/user/，類似/home/user/foo這樣的文件時不能被創建的。
因此snapshot在/home和/save上得到讀鎖，在/home/user和/save/user上得到寫鎖。而文件創建操作會在/home和/home/user上得到讀鎖，在/home/user/foo上得到寫鎖。因此兩個操作可以被正確同步。注意文件創建並不在父目錄得到寫鎖，因爲沒有類似inode這樣的數據結構。
對目錄名的讀鎖足以保證該目錄不會被刪除。
這種鎖機制允許在同一個目錄併發更改操作。比如併發在一個目錄創建文件---對目錄名獲得讀鎖，對文件名獲得寫鎖。對目錄名的讀鎖足以保證該目錄不會被刪除、重命名或快照。
由於namespace下可能有很多node，每個node的讀寫鎖延遲分配，使用完後立即釋放。另外lock的獲取採用一致的全序以避免死鎖。比如先按namespace tree 的level的順序，同一level上再按字典序。
Replicaplacement:
Chunk replica replacement策略的兩個目標：
最大化datareliability和availability。最大化網絡帶寬使用率。因此簡單的複製到不同機器是不夠的，它只是解決了machine/diskfailure，最大化使用了該機器的網絡帶寬。還要在不同rack層面來複制，解決整個rack失效問題，
Creation,re-replication，rebanlancing
master創建chunk時，chunk server的選擇取決於：
1）磁盤使用率低於平均水平
2）近期創建的chunk數不要太多
3）Spread chunks across racks
一旦chunk的現有replica數量低於用戶設定值（比如chunk server失效，chunk server報告chunk corrupted，磁盤失效等），master會立即觸發re-replica。
需要re-replicate的chunk優先級依賴於：距離設定的replication目標有多遠。越遠的優先級越高。爲了減少對應用影響，對於阻塞應用的chunk提高其優先級。
Master選擇最高優先級的chunk，然後選擇某個chunkserver直接複製這個chunk。Chunk server的選擇和創建chunk時的策略相同。爲了防止clone產生的流量影響應用，master除了控制單個chunk server上的複製，還會控制整個cluster的複製數量。此外chunk server通過控制讀請求來控制複製時使用的網絡帶寬。
Master定期rebanlance replicas：檢查當前replica分佈，將replica移動以得到更好地磁盤使用率和負載均衡。Master還決定刪除哪個replica。
Garbagecollection
當文件刪除後，GFS並不立刻回收空間，而是在垃圾回收時處理，file level和chunk level都是如此。這樣系統簡潔、穩定
機制：
應用刪除一個文件時，master記錄日誌，然後將文件重命名爲隱藏名字（包含刪除時間戳）。
Master定期掃描整個文件系統namespace，刪除超過3天（可配置）的隱藏名字文件。當隱藏文件刪除後，其內存meta data也被釋放。
Master還回定期掃描chunk namespace。標識孤兒chunk（不屬於任何文件），刪除對應的meta data。Chunk server在heartbeat中定期報告他所有的chunk，master則回覆metadata中已經不存在的chunk標識。Chunk server根據此信息刪除這些chunk。
Chunk標識：master的file->chunk映射中
Chunk replica標識：chunk server上的linux file
垃圾回收、掃描、心跳等都是後臺執行。Master可以選擇閒時執行。
用戶可以對namespace不同部分採用不同的複製、回收策略。
Stalereplication detection:
Chunk server失效宕機，那麼其後的更改他都會漏掉，導致stale replica
對於每一個chunk,master維護一個versionnumber來區分是否stale。當master grant一個新lease時，增加version number並通知replica。Master和replica都在磁盤保存version number。
Master回覆Client哪個replica擁有lease時也會包含version number信息，複製時chunk server間也會傳遞該信息，因此client和chunk server都可以驗證version
容錯、問題診斷設計
Master, chunk server啓動、恢復狀態必須在數秒內
Master複製：
日誌和檢查點被複制到多個機器。如果master機器失效，gfs之外的監控設施會在其他機器上啓動master進程。
Shadow master（從某個operation log複製讀取日誌記錄並replay。啓動時也會pollchuck server， heartbeat等）：當primary master宕機時可提供只讀訪問，但shadow數據可能比primary延遲數秒。實際上文件數據讀自chunk server，因爲不stale，stale的可能是master上的file metadata。
Dataintegrity:
Gfs的更改特別是record append操作允許各replica不完全一樣。每個chunk server必須獨立校驗數據完整性（通過checksum）
每個chunk由數個64kb的block組成，每個block維護一個32位校驗（checksum在內存中，並記入日誌，）。chunk server讀數據時計算checksum並和存儲的checksum比較，若不匹配，向requester（可能是client或其他chunk server）返回錯誤，並報告master。Requester會從其他replica讀取，master會從其他replica clone這個chunk。當new chunk完成後，master會命令chunk server刪除舊chunk。
