Google File System原理

時間 2019-11-16

標籤 google file system 原理欄目 Google 简体版

原文原文鏈接

1. Introduction

本文是讀GFS論文的總結，收錄在個人github中papers項目，papers項目旨在學習和總結分佈式系統相關的論文。git

全文主要分爲如下幾方面：github

Design Motivation
Architecture
System Interactions
Master Operation
Fault Tolerance and Diagnose
Discussion

2. Design Motivation

google對現有系統的運行狀態以及應用系統進行總結，抽象出對文件系統的需求，主要分爲如下幾個方面。後端

普通商用的機器硬件發生故障是常態
存儲的問題廣泛比較大，幾個G的文件很常見
大部分的文件操做都是在追加數據，覆蓋原來寫入的數據的狀況比較少見，隨機寫幾乎不存在
讀操做主要包括兩種，large streaming read和small random read
爲了應用使用方便，多客戶端並行地追加同一個文件須要很是高效
帶寬的重要性大於時延，目標應用是高速讀大塊數據的應用，對響應時間沒有過多的需求

3. Architecture

本部分討論gfs的整體架構，以及在此架構上須要考慮的一些問題。緩存

3.1 Overview

GFS的總體架構以下圖：微信

(圖片來源：gfs論文)網絡

GFS中有四類角色，分別是數據結構

GFS chunkserver
GFS master
GFS client
Application

3.1.1 GFS chunkserver

在GFS chunkserver中，文件都是分紅固定大小的chunk來存儲的，每一個chunk經過全局惟一的64位的chunk handle來標識，chunk handle在chunk建立的時候由GFS master分配。GFS chunkserver把文件存儲在本地磁盤中，讀或寫的時候須要指定文件名和字節範圍，而後定位到對應的chunk。爲了保證數據的可靠性，一個chunk通常會在多臺GFS chunkserver上存儲，默認爲3份，但用戶也能夠根據本身的須要修改這個值。架構

3.1.2 GFS master

GFS master管理全部的元數據信息，包括namespaces，訪問控制信息，文件到chunk的映射信息，以及chunk的地址信息（即chunk存放在哪臺GFS chunkserver上）。併發

3.1.3 GFS client

GFS client是GFS應用端使用的API接口，client和GFS master交互來獲取元數據信息，可是全部和數據相關的信息都是直接和GFS chunkserver來交互的。app

3.1.4 Application

Application爲使用gfs的應用，應用經過GFS client於gfs後端(GFS master和GFS chunkserver)打交道。

3.2 Single Master

GFS架構中只有單個GFS master，這種架構的好處是設計和實現簡單，例如，實現負載均衡時能夠利用master上存儲的全局的信息來作決策。可是，在這種架構下，要避免的一個問題是，應用讀和寫請求時，要弱化GFS master的參與度，防止它成爲整個系統架構中的瓶頸。

從一個請求的流程來討論上面的問題。首先，應用把文件名和偏移量信息傳遞給GFS client，GFS client轉換成(文件名，chunk index)信息傳遞給GFS master，GFS master把(chunk handle, chunk位置信息)返回給客戶端，客戶端會把這個信息緩存起來，這樣，下次再讀這個chunk的時候，就不須要去GFS master拉取chunk位置信息了。

另外一方面，GFS支持在一個請求中同時讀取多個chunk的位置信息，這樣更進一步的減小了GFS client和GFS master的交互次數，避免GFS master成爲整個系統的瓶頸。

3.3 Chunk Size

對於GFS來講，chunk size的默認大小是64MB，比通常文件系統的要大。

優勢

能夠減小GFS client和GFS master的交互次數，chunk size比較大的時候，屢次讀多是一塊chunk的數據，這樣，能夠減小GFS client向GFS master請求chunk位置信息的請求次數。
對於同一個chunk，GFS client能夠和GFS chunkserver之間保持持久鏈接，提高讀的性能。
chunk size越大，chunk的metadata的總大小就越小，使得chunk相關的metadata能夠存儲在GFS master的內存中。

缺點

chunk size越大時，可能對部分文件來說只有1個chunk，那麼這個時候對該文件的讀寫就會落到一個GFS chunkserver上，成爲熱點。

對於熱點問題，google給出的解決方案是應用層避免高頻地同時讀寫同一個chunk。還提出了一個可能的解決方案是，GFS client找其餘的GFS client來讀數據。

64MB應該是google得出的一個比較好的權衡優缺點的經驗值。

3.4 Metadata

GFS master存儲三種metadata，包括文件和chunk namespace，文件到chunk的映射以及chunk的位置信息。這些metadata都是存儲在GFS master的內存中的。對於前兩種metadata，還會經過記操做日誌的方式持久化存儲，操做日誌會同步到包括GFS master在內的多臺機器上。GFS master不持久化存儲chunk的位置信息，每次GFS master重啓或者有新的GFS chunkserver加入時，GFS master會要求對應GFS chunkserver把chunk的位置信息彙報給它。

3.4.1 In-Memory Data Structures

使用內存存儲metadata的好處是讀取metadata速度快，方便GFS master作一些全局掃描metadata相關信息的操做，例如負載均衡等。

可是，之內存存儲的的話，須要考慮的是GFS master的內存空間大小是否是整個系統能存儲的chunk數量的瓶頸所在。在GFS實際使用過程當中，這通常不會成爲限制所在，由於GFS中一個64MBchunk的metadata大小不超過64B，而且，對於大部分chunk來說都是使用的所有的空間的，只有文件的最後一個chunk會存儲在部分空間沒有使用，所以，GFS master的內存空間在實際上不多會成爲限制系統容量的因素。即便真的是現有的存儲文件的chunk數量超過了GFS master內存空間大小的限制，也能夠經過加內存的方式，來獲取內存存儲設計帶來的性能、可靠性等多種好處。

3.4.2 Chunk Locations

GFS master不持久化存儲chunk位置信息的緣由是，GFS chunkserver很容易出現宕機，重啓等行爲，這樣GFS master在每次發生這些事件的時候，都要修改持久化存儲裏面的位置信息的數據。

3.4.3 Operation Log

operation log的做用

持久化存儲metadata
它的存儲順序定義了並行的操做的最終的操做順序

怎麼存

operation log會存儲在GFS master和多臺遠程機器上，只有當operation log在GFS master和多臺遠程機器都寫入成功後，GFS master纔會向GFS client返回成功。爲了減小operation log在多臺機器落盤對吞吐量的影響，能夠將一批的operation log造成一個請求，而後寫入到GFS master和其餘遠程機器上。

check point

當operation log達到必定大小時，GFS master會作checkpoint，至關於把內存的B-Tree格式的信息dump到磁盤中。當master須要重啓時，能夠讀最近一次的checkpoint，而後replay它以後的operation log，加快恢復的時間。

作checkpoint的時候，GFS master會先切換到新的operation log，而後開新線程作checkpoint，因此，對新來的請求是基本是不會有影響的。

4. System Interactions

本部分討論GFS的系統交互流程。

4.1 Leases and Mutation Order

GFS master對後續的數據流程是不作控制的，因此，須要一個機制來保證，全部副本是按照一樣的操做順序寫入對應的數據的。GFS採用lease方式來解決這個問題，GFS對一個chunk會選擇一個GFS chunkserver，發放lease，稱做primary，由primary chunkserver來控制寫入的順序。

Lease的過時時間默認是60s，能夠經過心跳信息來續時間，若是一個primary chunkserver是正常狀態的話，這個時間通常是無限續下去的。當primary chunkserver和GFS master心跳斷了後，GFS master也能夠方便的把其餘chunk副本所在的chunkserver設置成primary。

4.1.1 Write Control and Data Flow

(圖片來源：gfs論文)

GFS client向GFS master請求擁有具備當前chunk的lease的chunkserver信息，以及chunk的其餘副本所在的chunkserver的信息，若是當前chunk沒有lease，GFS master會分配一個。
GFS master把primary chunkserver以及其餘副本的chunkserver信息返回給client。client會緩存這些信息，只有當primary chunkserver連不上或者lease發生改變後，才須要再向GFS master獲取對應的信息。
client把數據推送給全部包含此chunk的chunkserver，chunkserver收到後會先把數據放到內部的LRU buffer中，當數據被使用或者過時了，才刪除掉。注意，這裏沒有將具體怎麼來發送數據，會在下面的Data Flow講。
當全部包含chunk副本的chunkserver都收到了數據，client會給primary發送一個寫請求，包含以前寫的數據的信息，primary會分配對應的序號給這次的寫請求，這樣能夠保證從多個客戶端的併發寫請求會獲得惟一的操做順序，保證多個副本的寫入數據的順序是一致的。
primary轉發寫請求給全部其餘的副本所在的chunkserver(Secondary replica)，操做順序由primary指定。
Secondary replica寫成功後會返回給primary replica。
Primary replica返回給client。任何副本發生任何錯誤都會返回給client。

這裏，寫數據若是發生錯誤可能會產生不一致的狀況，會在consistency model中討論。

4.2 Data Flow

4.1中第三步的Data Flow採用的是pipe line方式，目標是爲了充分利用每臺機器的網絡帶寬。假設一臺機器總共有三個副本S1-S3。整個的Data Flow爲：

client選擇離它最近的chunkserver S1，開始推送數據
當chunkserver S1收到數據後，它會立馬轉發到離它最近的chunkserver S2
chunkserver S2收到數據後，會立馬轉發給離它最近的chunkserver S3

不斷重複上述流程，直到全部的chunkserver都收到client的全部數據。

以上述方式來傳送B字節數據到R個副本，並假設網絡吞吐量爲T，機器之間的時延爲L，那麼，整個數據的傳輸時間爲B/T+RL。

4.3 Atomic Record Appends

Append操做流程和寫差很少，主要區別在如下

client把數據推送到全部副本的最後一個chunk，而後發送寫請求到primary
primary首先檢查最後一個chunk的剩餘空間是否能夠知足當前寫請求，若是能夠，那麼執行寫流程，不然，它會把當前的chunk的剩餘空間pad起來，而後告訴其餘的副本也這麼幹，最後告訴client這個chunk滿了，寫入下個chunk。

這裏須要討論的是，若是append操做在部分副本失敗的狀況下，會發生什麼？

例如，寫操做要追加到S1-S3，可是，僅僅是S1,S2成功了，S3失敗了，GFS client會重試操做，假如第二次成功了，那麼S1,S2寫了兩次，S3寫了一次，目前的理解是GFS會先把失敗的記錄進行padding對齊到primary的記錄，而後再繼續append。

4.4 Snapshot

Snapshot的整個流程以下：

client向GFS master發送Snapshot請求
GFS master收到請求後，會回收全部此次Snapshot涉及到的chunk的lease
當全部回收的lease到期後，GFS master寫入一條日誌，記錄這個信息。而後，GFS會在內存中複製一份snapshot涉及到的metadata

當snapshot操做完成後，client寫snapshot中涉及到的chunk C的流程以下：

client向GFS master請求primary chunkserver和其餘chunkserver
GFS master發現chunk C的引用計數超過1，即snapshot和自己。它會向全部有chunk C副本的chunkserver發送建立一個chunk C的拷貝請求，記做是chunk C'，這樣，把最新數據寫入到chunk C'便可。本質上是copy on write。

4.5 Consistency Model

(圖片來源：gfs論文)

GFS中consistent、defined的定義以下：

consistent：全部的客戶端都能看到同樣的數據，無論它們從哪一個副本讀取
defined：當一個文件區域發生操做後，client能夠看到剛剛操做的全部數據，那麼說此次操做是defined。

下面分析表格中出現的幾種狀況。

Write(Serial Success)，單個寫操做，而且返回成功，那麼全部副本都寫入了此次操做的數據，所以全部客戶端都能看到此次寫入的數據，因此，是defined。
Write(Concurrent Successes)，多個寫操做，而且返回成功，因爲多個客戶端寫請求發送給priamary後，由primary來決定寫的操做順序，可是，有可能多個寫操做多是有區域重疊的，這樣，最終寫完成的數據多是多個寫操做數據疊加在一塊兒，因此這種狀況是consistent和undefined。
Write(Failure)，寫操做失敗，則可能有的副本寫入了數據，有的沒有，因此是inconsistent。
Record Append(Serial Success and Concurrent Success)，因爲Record Append可能包含重複數據，所以，是inconsistent，因爲整個寫入的數據都能看到，因此是defined。
Record Append(Failure)，可能部分副本append成功，部分副本append失敗，因此，結果是inconsistent。

GFS用version來標記一個chunkserver掛掉的期間，是否有client進行了write或者append操做。每進行一次write或者append，version會增長。

須要考慮的點是client會緩存chunk的位置信息，有可能其中某些chunkserver已經掛掉又起來了，這個時候chunkserver的數據多是老的數據，讀到的數據是會不一致的。讀流程中，好像沒有看到要帶version信息來讀的。這個論文中沒看到避免的措施，目前尚未結果。

4.5.1 Implications for Applications

應用層須要採用的機制：用append而不是write，作checkpoint，writing self-validating和self-identifying records。具體地，以下：

應用的使用流程是append一個文件，到最終寫完後，重命名文件
對文件作checkpoint，這樣應用只須要關注上次checkpoint時的文件區域到最新文件區域的數據是不是consistent的，若是這期間發生不一致，能夠從新作這些操做。
對於並行作append的操做，可能會出現重複的數據，GFS client提供去重的功能。

5. Master Operation

GFS master的功能包括，namespace Management， Replica Placement，Chunk Creation，Re-replication and Rebalancing以及Garbage Collection。

5.1 Namespace Management and Locking

每一個master操做都須要得到一系列的鎖。若是一個操做涉及到/d1/d2/.../dn/leaf，那麼須要得到/d1,/d1/d2,/d1/d2/.../dn的讀鎖，而後，根據操做類型，得到/d1/d2/.../dn/leaf的讀鎖或者寫鎖，其中leaf多是文件或者路徑。

一個例子，當/home/user被快照到/save/user的時候，/home/user/foo的建立是被禁止的。

對於快照，須要得到/home和/save的讀鎖，/home/user和/save/user的寫鎖。對於建立操做，會得到/home,/home/user的讀鎖，而後/home/user/foo的寫鎖。其中，/home/user的鎖產生衝突，/home/user/foo建立會被禁止。

這種加鎖機制的好處是對於同一個目錄下，能夠並行的操做文件，例如，同一個目錄下並行的建立文件。

5.2 Replica Placement

GFS的Replica Placement的兩個目標：最大化數據可靠性和可用性，最大化網絡帶寬的使用率。所以，把每一個chunk的副本分散在不一樣的機架上，這樣一方面，能夠抵禦機架級的故障，另外一方面，能夠把讀寫數據的帶寬分配在機架級，重複利用多個機架的帶寬。

5.3 Creation, Re-replication, Rebalancing

5.3.1 Chunk Creation

GFS在建立chunk的時候，選擇chunkserver時考慮的因素包括：

磁盤空間使用率低於平均值的chunkserver
限制每臺chunkserver的最近的建立chunk的次數，由於建立chunk每每意味着後續須要寫大量數據，因此，應該把寫流量儘可能均攤到每臺chunkserver上
chunk的副本放在處於不一樣機架的chunkserver上

5.3.2 Chunk Re-replication

當一個chunk的副本數量少於預設定的數量時，須要作複製的操做，例如，chunkserver宕機，副本數據出錯，磁盤損壞，或者設定的副本數量增長。

chunk的複製的優先級是按照下面的因素來肯定的：

丟失兩個副本的chunk比丟失一個副本的chunk的複製認爲優先級高
文件正在使用比文件已被刪除的chunk的優先級高
阻塞了client進程的chunk的優先級高(這個靠什麼方法獲得?)

chunk複製的時候，選擇新chunkserver要考慮的點：

磁盤使用率
單個chunkserver的複製個數限制
多個副本須要在多個機架
集羣的複製個數限制
限制每一個chunkserver的複製網絡帶寬，經過限制讀流量的速率來限制

5.3.3 Rebalancing

週期性地檢查副本分佈狀況，而後調整到更好的磁盤使用狀況和負載均衡。GFS master對於新加入的chunkserver，逐漸地遷移副本到上面，防止新chunkserver帶寬打滿。

5.4 Garbage Collection

在GFS刪除一個文件後，並不會立刻就對文件物理刪除，而是在後面的按期清理的過程當中才真正的刪除。

具體地，對於一個刪除操做，GFS僅僅是寫一條日誌記錄，而後把文件命名成一個對外部不可見的名稱，這個名稱會包含刪除的時間戳。GFS master會按期的掃描，當這些文件存在超過3天后，這些文件會從namespace中刪掉，而且內存的中metadata會被刪除。

在對chunk namespace的按期掃描時，會掃描到這些文件已經被刪除的chunk，而後會把metadata從磁盤中刪除。

在與chunkserver的heartbeat的交互過程當中，GFS master會把不在metadata中的chunk告訴chunkserver，而後chunkserver就能夠刪除這些chunk了。

採用這種方式刪除的好處：

利用心跳方式交互，在一次刪除失敗後，還能夠經過下次心跳繼續重試操做
刪除操做和其餘的全局掃描metadata的操做能夠放到一塊兒作

壞處：

有可能有的應用須要頻繁的建立和刪除文件，這種延期刪除方式會致使磁盤使用率偏高，GFS提供的解決方案是，對一個文件調用刪除操做兩次，GFS會立刻作物理刪除操做，釋放空間。

5.5 Stale Replication Detection

當一臺chunkserver掛掉的時候，有新的寫入操做到chunk副本，會致使chunkserve的數據不是最新的。

當master分配lease到一個chunk時，它會更新chunk version number，而後其餘的副本都會更新該值。這個操做是在返回給客戶端以前完成的，若是有一個chunkserver當前是宕機的，那麼它的version number就不會增長。當chunkserver重啓後，會彙報它的chunk以及version number，對於version number落後的chunk，master就認爲這個chunk的數據是落後的。

GFS master會把落後的chunk當垃圾來清理掉，而且不會把落後的chunkserver的位置信息傳給client。

備註：

１. GFS master把落後的chunk看成垃圾清理，那麼，是不是走re-replication的邏輯來生成新的副本呢？沒有，是走當即複製的邏輯。

6. Fault Tolerance and Diagnose

6.1 High Availability

爲了實現高可用性，GFS在經過兩方面來解決，一是fast recovery，二是replication

6.1.1 Fast Recovery

master和chunkserver都被設計成都能在秒級別重啓

6.1.2 Chunk Replications

每一個chunk在多個機架上有副本，副本數量由用戶來指定。當chunkserver不可用時，GFS master會自動的複製副本，保證副本數量和用戶指定的一致。

6.1.3 Master Replication

master的operation log和checkpoint都會複製到多臺機器上，要保證這些機器的寫都成功了，才認爲是成功。只有一臺master在來作garbage collection等後臺操做。當master掛掉後，它能在不少時間內重啓；當master所在的機器掛掉後，監控會在其餘具備operation log的機器上重啓啓動master。

新啓動的master只提供讀服務，由於可能在掛掉的一瞬間，有些日誌記錄到primary master上，而沒有記錄到secondary master上（這裏GFS沒有具體說同步的流程）。

6.2 Data Integrity

每一個chunkserver都會經過checksum來驗證數據是否損壞的。

每一個chunk被分紅多個64KB的block，每一個block有32位的checksum，checksum在內存中和磁盤的log中都有記錄。

對於讀請求，chunkserver會檢查讀操做所涉及block的全部checksum值是否正確，若是有一個block的checksum不對，那麼會報錯給client和master。client這時會從其餘副本讀數據，而master會clone一個新副本，當新副本clone好後，master會刪除掉這個checksum出錯的副本。

6.3 Diagnose Tools

主要是經過log，包括重要事件的log(chunkserver上下線)，RPC請求，RPC響應等。

7. Discussion

本部分主要討論大規模分佈式系統一書上，列出的關於gfs的一些問題，具體以下。

7.1 爲何存儲三個副本？而不是兩個或者四個？

若是存儲的是兩個副本，掛掉一個副本後，系統的可用性會比較低，例如，若是另外一個沒有掛掉的副本出現網絡問題等，整個系統就不可用了
若是存儲的是四個副本，成本比較高

7.2 chunk的大小爲什麼選擇64MB？這個選擇主要基於哪些考慮？

優勢

能夠減小GFS client和GFS master的交互次數，chunk size比較大的時候，屢次讀多是一塊chunk的數據，這樣，能夠減小GFS client向GFS master請求chunk位置信息的請求次數。
對於同一個chunk，GFS client能夠和GFS chunkserver之間保持持久鏈接，提高讀的性能。
chunk size越大，chunk的metadata的總大小就越小，使得chunk相關的metadata能夠存儲在GFS master的內存中。

缺點

chunk size越大時，可能對部分文件來說只有1個chunk，那麼這個時候對該文件的讀寫就會落到一個GFS chunkserver上，成爲熱點。

64MB應該是google得出的一個比較好的權衡優缺點的經驗值。

7.3 gfs主要支持追加，改寫操做比較少，爲何這麼設計？如何設計一個僅支持追加操做的文件系統來構建分佈式表格系統bigtable？

由於追加多，改寫少是google根據現有應用需求而肯定的
bigtable的問題等讀到bigtable論文再討論

7.4 爲何要將數據流和控制流分開？若是不分開，如何實現追加流程？

主要是爲了更有效地利用網絡帶寬。把數據流分開，能夠更好地優化數據流的網絡帶寬使用。

若是不分開，須要討論下。

7.5 gfs有時會出現重複記錄或者padding記錄，爲何？

padding出現場景：

last chunk的剩餘空間不知足當前寫入量大小，須要把last chunk作padding，而後告訴客戶端寫入下一個chunk
append操做失敗的時候，須要把以前寫入失敗的副本padding對齊到master

重複記錄出現場景：

append操做部分副本成功，部分失敗，而後告訴客戶端重試，客戶端會在成功的副本上再次append，這樣就會有重複記錄出現

7.6 lease是什麼？在gfs中起到了什麼做用？它與心跳有何區別？

lease是gfs master把控制寫入順序的權限下放給chunkserver的機制，以減小gfs master在讀寫流程中的參與度，防止其成爲系統瓶頸。心跳是gfs master檢測chunkserver是否可用的標誌。

7.7 gfs追加過程當中若是出現備副本故障，如何處理？若是出現主副本故障，應該如何處理？

對於備副本故障，寫入的時候會失敗，而後primary會返回錯誤給client。按照通常的系統設計，client會重試必定次數，發現仍是失敗，這時候client會把狀況告訴給gfs master，gfs master能夠檢測chunkserver的狀況，而後把最新的chunkserver信息同步給client，client端再繼續重試。

對於主副本故障，寫入的時候會失敗，client端應該是超時了。client端會繼續重試必定次數，發現仍是一直超時，那麼把狀況告訴給gfs master，gfs master發現primary掛掉，會從新grant lease到其餘chunkserver，並把狀況返回給client。

7.8 gfs master須要存儲哪些信息？master的數據結構如何設計？

namespace、文件到chunk的映射以及chunk的位置信息

namespace採用的是B-Tree，對於名稱採用前綴壓縮的方法，節省空間；（文件名，chunk index）到chunk的映射，能夠經過hashmap；chunk到chunk的位置信息，能夠用multi_hashmap，由於是一對多的映射。

7.9 假設服務一千萬個文件，每一個文件1GB，master中存儲元數據大概佔多少內存？

1GB/64MB = 1024 / 64 = 16。總共須要16 10000000 64 B = 10GB

7.10 master如何實現高可用性？

metadata中namespace，以及文件到chunk信息持久化，並存儲到多臺機器
對metadata的作checkpoint，保證重啓後replay消耗時間比較短，checkpoint能夠直接映射到內存使用，不用解析
在primary master發生故障的時候，而且沒法重啓時，會有外部監控將secondary master，並提供讀服務。secondary master也會監控chunkserver的狀態，而後把primary master的日誌replay到內存中

7.11 負載的影響因素有哪些？如何計算一臺機器的負載值？

主要是考慮CPU、內存、網絡和I/O，但如何綜合這些參數並計算仍是得看具體的場景，每部分的權重隨場景的不一樣而不一樣。

7.12 master新建chunk時如何選擇chunkserver？若是新機器上線，負載值特別低，如何避免其餘chunkserver同時往這臺機器上遷移chunk？

如何選擇chunkserver

磁盤空間使用率低於平均值的chunkserver
限制每臺chunkserver最近建立chunk的次數，由於建立chunk每每意味着後續須要寫入大量數據，因此，應該把寫流量均攤到每臺chunkserver
chunk的副本放置於不一樣機架的chunkserver上

如何避免同時遷移

經過限制單個chunkserver的clone操做的個數，以及clone使用的帶寬來限制，即從源chunkserver度數據的頻率作控制。

7.13 若是chunkserver下線後過一會從新上線，gfs如何處理？

由於是過一會，因此假設chunk re-replication尚未執行，那麼在這期間，可能這臺chunkserver上有些chunk的數據已經處於落後狀態了，client讀數據的時候或者chunkserver按期掃描的時候會把這些狀態告訴給master，master告訴上線後的chunkserver從其餘機器複製該chunk，而後master會把這個chunk看成是垃圾清理掉。

對於沒有落後的chunk副本，能夠直接用於使用。

7.14 如何實現分佈式文件系統的快照操做？

Snapshot的整個流程以下：

client向GFS master發送Snapshot請求
GFS master收到請求後，會回收全部此次Snapshot涉及到的chunk的lease
當全部回收的lease到期後，GFS master寫入一條日誌，記錄這個信息。而後，GFS會在內存中複製一份snapshot涉及到的metadata

當snapshot操做完成後，client寫snapshot中涉及到的chunk C的流程以下：

client向GFS master請求primary chunkserver和其餘chunkserver
GFS master發現chunk C的引用計數超過1，即snapshot和自己。它會向全部有chunk C副本的chunkserver發送建立一個chunk C的拷貝請求，記做是chunk C'，這樣，把最新數據寫入到chunk C'便可。本質上是copy on write。

7.15 chunkserver數據結構如何設計？

chunkserver主要是存儲64KB block的checksum信息，須要由chunk+offset，可以快速定位到checksum，能夠用hashmap。

7.16 磁盤可能出現位翻轉錯誤，chunkserver如何應對？

利用checksum機制，分讀和寫兩種狀況來討論：

對於讀，要檢查所讀的全部block的checksum值
對於寫，分爲append和write。對於append，不檢查checksum，延遲到讀的時候檢查，由於append的時候，對於最後一個不完整的block計算checksum時候採用的是增量的計算，即便前面存在錯誤，也能在後來的讀發現。對於overwrite，由於不能採用增量計算，要覆蓋checksum，因此，必需要先檢查只寫入部分數據的checksum是否不一致，不然，數據錯誤會被隱藏。