Google File System(簡稱GFS)是適用於大規模且可擴展的分布式文件系統，可以部署在廉價的商務伺服器上，在保證系統可靠性和可用 性的同時，大大降低了系統的成本。GFS的設計目標是高性能、高可靠、高可用性。
GFS把機器故障視為正常現象，可以很好地處理系統故障。GFS系統通常會部署在上百台甚至上千台廉價伺服器上，並會有相當多台廉價伺服器上部署GFS Client來訪問GFS服務，所以應用故障、操作系統bug、連接故障、網路故障、甚至機器供電故障都是經常發生的故障。GFS系統可以支持系統監控、故障檢測、故障容忍和自動恢復，提供了非常高的可靠性。其次，GFS系統中的文件一般都是大文件，且文件操作大部分場景下都是append而不是overwrite。一旦文件寫入完成後，大部分操作都是讀文件且是順序讀。
GFS提供了非標准（比如POSIX）的文件系統介面，支持 create、delete、open、close、read以及write。另外GFS支持snapshot和record append操作。snapshot可以以很低的代價創建文件或者目錄樹的拷貝，record append可以支持多個client並發地向同一個文件append data，同時還能保證每個client的append操作的原子性。
master記錄了文件系統的metadata，包括名字空間、許可權控制信息、文件到chunk的mapping以及chunk的分布。master也負責chunk的lease管理、無用chunk的垃圾回收、chunk遷移等。master定期與chunkserver通信，向chunkserver發送指令並搜集chunkserver的狀態。GFS client通過GFS的API與GFS系統通信（讀寫數據）。client向master請求獲取metadata，真正的讀寫數據是直接與chunkserver交互。client和chunkserver都不cache文件數據。因為大部分應用都是基於API來streaming read 大文件且系統的文件數據太多，所以client緩存文件數據沒有意義。chunkserver所在機器的linux的buffer cache以及cache了頻繁訪問的數據，chunkserver也是沒有去cache文件數據的。
單點master大大簡化了系統設計，因為master知曉所有的meta信息，所以可以執行更加復雜的chunk位置分配和副本策略。但是，在讀寫數據時必須降低master的參與，以避免單點的master稱為系統瓶頸。client不會通過master來讀寫文件數據，但是client會向master發送查詢chunk位置分布的請求，然後client端緩存chunk的分布信息，然後直接向chunkserver讀寫數據。大致的讀過程如下：
1、client根據文件名、byte offset以及chunk size計算出要讀取的文件的chunk index
2、client通過文件名、chunk index向master查詢chunk的分布
3、master回復chunk handler以及副本分布
4、client 緩存chunk的meta信息，key由文件名和chunk index組成
5、client從chunk的分布信息中查找距離自己最新的chunkserver，並發送查詢請求。查詢請求中包括chunk hander以及byte range。後續對相同chunk的查詢不需要再次向master查詢meta信息，因為client已經緩存了meta信息。
chunk size是GFS系統的關鍵參數，通常設置為64MB，遠大於文件系統的block大小。每個chunk的副本都chunkserver所在機器上以Linux file存儲。之所為將chunk size定為64MB，主要有以下考慮：
1、可以減少client訪問master查詢meta信息的次數，降低master的訪問壓力。因為chunk size設計比較大，順序訪問一個超大文件時因為chunk數較少且client緩存了chunk meta信息，所以訪問master的次數就會降低。甚至，client可以緩存所有文件的chunk的meta信息，就算是隨機讀文件，master也不會成為系統性能瓶頸。
2、可以減少網路開銷，保持client與chunkserver的TCP連接，可以執行更多的chunk操作。
3、可以減少master上需要在內存中記錄的meta data數據量，降低master的內存佔用。
size大的缺點是：小文件包含很少的chunk，甚至只有一個。這樣的話，在多個client高並發查詢該小文件時對應的chunk會成為熱點。實際上，這種情況在GFS系統中很少發生，因為大部分client的操作都是順序讀大文件。但是，考慮以下場景，我們部署一個服務的二進制文件到GFS系統中，然後數百台的伺服器同時查詢二進制文件並啟動服務，此時該二進制文件副本所在的chunkserver立馬就會成為查詢瓶頸。當然，可以通過增加副本數和分散伺服器的查詢時間來解決這種場景下的問題。
master主要存儲三種類型的metadata：file和chunk的名字空間，file到chunk的mapping信息以及chunk的副本分布。所有的metadata都在master的內存中存儲。前兩種meta信息可以持久化存儲，將操作日誌存儲在master的本地磁碟以及將備份日誌存儲在遠端機器上。master不持久化存儲chunk的副本分布信息，而是通過與chunkserver交互來獲取chunkserver上的chunk信息。
4.1 in-memory data structure
meta信息在內存中，所有master的操作很快。另外，master可以高效地定期在後台scan所有的meta數據，來執行垃圾回收、副本修復、均衡等。metadata都記錄在內存中，所以GFS系統會比較關注chunk的數量以及master的可用內存量。但是在實際場景下，這不是問題。每個64MB的chunk的metadata小於64位元組，大部分的chunk都是滿負荷存儲的，除了文件最後一個chunk的空間是沒有完全被佔用。由於文件的名字空間採用了前綴壓縮的方式存儲，單個文件的meta信息也是小於64位元組。如果需要擴大系統規模的話，可以很簡單地通過增大master的內存就可以了。相比於系統的高可靠、高性能和簡潔性，增加內存是很最小的代價了。
4.2 chunk 分布
並沒有持久化存儲chunk的副本分布信息，而是在master啟動時向chunkserver查詢其chunk信息，然後通過heartbeat來持續更新master的副本分布信息，以與chunkserver數據保持一致。GFS起初設計時嘗試將chunk的分布信息持久化存儲在master端，隨後發現通過master啟動時拉取然後通過heartbeat同步chunk信息的方式更簡單。因為，當chunkserver加入、退出、名字改變、重啟等行為經常發生，這會導致維護master的chunk meta數據的正確性是非常困難的。從另一個角度考慮就是，只有chunkserver匯報的chunk信息才是集群中最真實的chunk分布，因為master不需要自己維護一個chunk分布狀態，只需要以chunkserver的狀態匯報為准即可。
4.3 操作日誌
日誌記錄了GFS集群數據更改的歷史記錄。操作日誌對GFS來說是至關重要的，因為它不僅是metadata的持久化記錄，還記錄了並發操作的時序。因為操作日誌很重要，所以必須可靠地存儲。在metadata的change沒有持久化之前，client是不能看到的數據的更改。當client修改數據時，操作記錄需要保存在多個遠端機器上，而且只有當操作記錄持久化存儲在本地和遠端以後，才會回復client數據更改成功。
可以通過回放操作日誌來恢復文件系統。為了減少系統啟動時replay的時間，必須縮減回放的日誌量。master可以定期存儲metadata的checkpoint，master重啟時可以從checkpoint載入metadata，然後回放checkpoint之後的少量日誌即可。
1、client向master查詢chunk的primary所在的chunkserver以及其他副本的分布，如果沒有primary的花，master會選擇一個作為該chunk的primary
2、master回復client primary和其他副本的分布信息。client會cache返回的metadata
3、client將數據發送所有的副本。client可以以任意順序執行。每個chunkserser都會在內存的LRUbuffer中記錄數據。
4、當所有的副本都返回已經接收數據成功後，client會向primary發送一個寫請求。primary會為每一個數據更改的請求附加一個序列號，數據更改是按照序列號的順序執行的。
5、primary將數據更改同步到其他副本中，副本也是按照序列號執行數據更改操作。
6、primary接收到其他副本回復的數據操作完成
7、primary返回client結果。期間發生的所有錯誤都會報給client。
GFS集群一般都會有上百台的chunkserver，分布在多個機架上。chunkserver也會接收來自本機架或者其他機架的上百個client的查詢請求。不同機架的伺服器通信可能會途徑一個或者多個交換機轉發。chunk的副本分布選擇策略主要目的是盡量提高數據的可靠性和可用性，同時最大化地充分利用網路帶寬。所以，僅僅將副本跨機器部署是不夠的。GFS將副本是跨機架部署的，這樣可以保證在一個機架被損壞或者下線時，chunk至少會有副本是可用的。
chunk的副本在下列情況下會被創建：創建chunk、副本修復、rebalance。當master創建chunk時，會選擇存儲該chunk副本的chunkserver。主要考慮以下幾點：
1、新副本所在chunkserver的磁碟利用率低於系統的平均水平
2、限制每個chunkserver最近一段時間創建chunk的數量
3、每個chunk的所有副本不能都在一個機架
chunk的副本數少於一定數量是，master會復制一個副本。這可能發生在chunkserver宕機或者chunkserver匯報自己的副本損壞或者chunkserver所在機器的磁碟損壞等等。每個chunk 復制任務都有優先順序，按照優先順序由高到低子master中排隊等待執行。master還會定期掃描當前副本的分布情況，一旦發現磁碟使用量或者機器負載不均衡，就會發起負載均衡操作。無論是chunk創建、chunk復制還是負載均衡，選擇chunk副本的位置的策略都是相同的，並且需要限制副本修復和均衡的速度，否則會影響系統的正常讀寫服務。
Google的成功表明單master的設計師可行的。這不僅簡化了系統，而且能夠較好地實現一致性，給予性能考慮，GFS提出了「記錄至少原子性追加一次」的一致性模型。通過租約的方式將每個chunk的修改授權到chunkserver從而減少了master的負載，通過流水線的方式復制多個副本以減少延時。master維護的元數據很多，需要設計高效的數據結構，且要保證佔用內存小和支持快照操作。支持COW的B樹可以滿足需求，但是實現確實相當復雜。
B. 在大數量級的數據存儲上，比較靠譜的分布式文件存儲有哪些
一、 Ceph
Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表，並隨後貢獻給開源社區。經過多年的發展之後，已得到眾多雲計算和存儲廠商的支持，成為應用最廣泛的開源分布式存儲平台。
二、 GFS
GFS是google的分布式文件存儲系統，是專為存儲海量搜索數據而設計的，2003年提出，是閉源的分布式文件系統。適用於大量的順序讀取和順序追加，如大文件的讀寫。注重大文件的持續穩定帶寬，而不是單次讀寫的延遲。
三、 HDFS
HDFS(Hadoop Distributed File System)，是一個適合運行在通用硬體(commodity hardware)上的分布式文件系統，是Hadoop的核心子項目，是基於流數據模式訪問和處理超大文件的需求而開發的。該系統仿效了谷歌文件系統(GFS)，是GFS的一個簡化和開源版本。
C. 什麼是google的分布式數據存儲管理系統
GFS是谷歌的分布式數據儲存管理系統。文件系統是計算機存儲、管理數據的基本方式，當信息量足夠大（單台伺服器無法支撐現有業務量時），通過多個文件系統節點組成文件系統網路，通過網路進行節點間的通信。分布式文件系統是建立在客戶機/伺服器技術基礎之上的，一個或多個文件伺服器與客戶機文件系統協同操作。
D. Google的GFS和開源的HDFS是()中的代表性方案
Hadoop項目。
1、HDFS（HadoopDistributedFileSystem），作為GoogleFileSystem（GFS）的實現，是Hadoop項目的核心子項目，是分布式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率等特徵為海量數據提供了不怕故障的存儲，為超大數據集（LargeDataSet）的應用處理帶來了很多便利。
2、GoogleGFS，BigTable，MapRece稱為Google的三駕馬車，是許多基礎服務的基石GFS於2003年提出，是一個分布式的文件系統，與此前的很多分布式系統的前提假設存在很大的不同，適用於以下場景）認為組件失效是一種常態，提供了容錯機制，自動負載均衡，使得分布式文件系統可以在廉價機器上運行）面向大文件存儲，系統主要的工作負載是大規模的流式讀取，寫操作主要是追加方式寫，很少有隨機寫）一次寫入，多次讀取。
3、開源HDFS。分布式文件存儲系統，源自於Google的GFS論文，HDFS是GFS的克隆版HDFS是Hadoop中數據存儲和管理的基礎，是一個高容錯的系統，能夠自動解決硬體故障。
E. 分布式存儲有哪些
問題一：當前主流分布式文件系統有哪些?各有什麼優缺點 目前幾個主流的分布式文件系統除GPFS外，還有PVFS、Lustre、PanFS、GoogleFS等。
1.PVFS(Parallel Virtual File System)項目是Clemson大學為了運行Linux集群而創建的一個開源項目,目前PVFS還存在以下不足：
1）單一管理節點:只有一個管理節點來管理元數據，當集群系統達到一定的規模之後，管理節點將可能出現過度繁忙的情況，這時管理節點將成為系統瓶頸;
2）對數據的存儲缺乏容錯機制:當某一I/O節點無法工作時，數據將出現不可用的情況;
3）靜態配置:對PVFS的配置只能在啟動前進行，一旦系統運行則不可再更改原先的配置。
2.Lustre文件系統是一個基於對象存儲的分布式文件系統，此項目於1999年在Carnegie Mellon University啟動，Lustre也是一個開源項目。它只有兩個元數據管理節點,同PVFS類似,當系統達到一定的規模之後，管理節點會成為Lustre系統中的瓶頸。
3.PanFS(Panasas File System)是Panasas公司用於管理自己的集群存儲系統的分布式文件系統。
4.GoogleFS(Google File System)是Google公司為了滿足公司內部的數據處理需要而設計的一套分布式文件系統。
5.相對其它的文件系統，GPFS的主要優點有以下三點：
1)使用分布式鎖管理和大數據塊策略支持更大規模的集群系統,文件系統的令牌管理器為塊、inode、屬性和目錄項建立細粒度的鎖，第一個獲得鎖的客戶將負責維護相應共享對象的一致性管理，這減少了元數據伺服器的負擔;
2)擁有多個元數據伺服器,元數據也是分布式,使得元數據的管理不再是系統瓶頸;
3)令牌管理以位元組作為鎖的最小單位,也就是說除非兩個請求訪問的是同一文件的同一位元組數據,對於數據的訪問請求永遠不會沖突.
問題二：分布式存儲是什麼？選擇什麼樣的分布式存儲更好？ 分布式存儲系統，是將數據分散存儲在多 *** 立的設備上。傳統的網路存儲系統採用集中的存儲伺服器存放所有數據，存儲伺服器成為系統性能的瓶頸，也是可靠性和安全性的焦點，不能滿足大規模存儲應用的需要。分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，它不但提高了系統的可靠性、可用性和存取效率，還易於擴展。
聯想超融合ThinkCloud AIO超融合雲一體機是聯想針對企業級用戶推出的核心產品。ThinkCloud AIO超融合雲一體機實現了對雲管理平台、計算、網路和存儲系統的無縫集成，構建了雲計算基礎設施即服務的一站式解決方案，為用戶提供了一個高度簡化的一站式基礎設施雲平台。這不僅使得業務部署上線從周縮短到天，而且與企業應用軟體、中間件及資料庫軟體完全解耦，能夠有效提升企業IT基礎設施運維管理的效率和關鍵應用的性能
問題三：什麼是分布式存儲系統？ 就是將數據分散存儲在多 *** 立的設備上
問題四：什麼是分布式數據存儲 定義：
分布式資料庫是指利用高速計算機網路將物理上分散的多個數據存儲單元連接起來組成一個邏輯上統一的資料庫。分布式資料庫的基本思想是將原來集中式資料庫中的數據分散存儲到多個通過網路連接的數據存儲節點上，以獲取更大的存儲容量和更高的並發訪問量。近年來，隨著數據量的高速增長，分布式資料庫技術也得到了快速的發展，傳統的關系型資料庫開始從集中式模型向分布式架構發展，基於關系型的分布式資料庫在保留了傳統資料庫的數據模型和基本特徵下，從集中式存儲走向分布式存儲，從集中式計算走向分布式計算。
特點：
1.高可擴展性：分布式資料庫必須具有高可擴展性，能夠動態地增添存儲節點以實現存儲容量的線性擴展。
2 高並發性：分布式資料庫必須及時響應大規模用戶的讀/寫請求，能對海量數據進行隨機讀/寫。
3. 高可用性：分布式資料庫必須提供容錯機制，能夠實現對數據的冗餘備份，保證數據和服務的高度可靠性。
問題五：分布式文件系統有哪些主要的類別？ 分布式存儲在大數據、雲計算、虛擬化場景都有勇武之地，在大部分場景還至關重要。munity.emc/message/655951 下面簡要介紹*nix平台下分布式文件系統的發展歷史：
1、單機文件系統
用於操作系統和應用程序的本地存儲。
2、網路文件系統（簡稱：NAS）
基於現有乙太網架構，實現不同伺服器之間傳統文件系統數據共享。
3、集群文件系統
在共享存儲基礎上，通過集群鎖，實現不同伺服器能夠共用一個傳統文件系統。
4、分布式文件系統
在傳統文件系統上，通過額外模塊實現數據跨伺服器分布，並且自身集成raid保護功能，可以保證多台伺服器同時訪問、修改同一個文件系統。性能優越，擴展性很好，成本低廉。
問題六：分布式文件系統和分布式資料庫有什麼不同 分布式文件系統（dfs）和分布式資料庫都支持存入，取出和刪除。但是分布式文件系統比較暴力，可以當做key/value的存取。分布式資料庫涉及精煉的數據，傳統的分布式關系型資料庫會定義數據元組的schema，存入取出刪除的粒度較小。
分布式文件系統現在比較出名的有GFS（未開源），HDFS（Hadoop distributed file system）。分布式資料庫現在出名的有Hbase，oceanbase。其中Hbase是基於HDFS，而oceanbase是自己內部實現的分布式文件系統，在此也可以說分布式資料庫以分布式文件系統做基礎存儲。
問題七：分布式存儲有哪些 華為的fusionstorage屬於分布式 您好，很高興能幫助您，首先，FusionDrive其實是一塊1TB或3TB機械硬碟跟一塊128GB三星830固態硬碟的組合。我們都知道，很多超極本同樣採用了混合型硬碟，但是固態硬碟部分的容量大都只有8GB到32GB之間，這個區間無法作為系統盤來使用，只能作
問題八：linux下常用的分布式文件系統有哪些 這他媽不是騰訊今年的筆試題么
NFS（tldp/HOWTO/NFS-HOWTO/index）
網路文件系統是FreeBSD支持的文件系統中的一種，也被稱為NFS。
NFS允許一個系統在網路上與它人共享目錄和文件。通過使用NFS， 用戶和程序可以象訪問本地文件一樣訪問遠端系統上的文件。它的好處是：
1、本地工作站使用更少的磁碟空間，因為通常的數據可以存放在一台機器上而且可以通過網路訪問到。
2、用戶不必在每個網路上機器裡面都有一個home目錄。home目錄可以被放在NFS伺服器上並且在網路上處處可用。
3、諸如軟碟機、CDROM、和ZIP之類的存儲設備可以在網路上面被別的機器使用。可以減少整個網路上的可移動介質設備的數量。
開發語言c/c++,可跨平台運行。
OpenAFS（openafs）
OpenAFS是一套開放源代碼的分布式文件系統，允許系統之間通過區域網和廣域網來分享檔案和資源。OpenAFS是圍繞一組叫做cell的文件伺服器組織的，每個伺服器的標識通常是隱藏在文件系統中，從AFS客戶機登陸的用戶將分辨不出他們在那個伺服器上運行，因為從用戶的角度上看，他們想在有識別的Unix文件系統語義的單個系統上運行。
文件系統內容通常都是跨cell復制，一便一個硬碟的失效不會損害OpenAFS客戶機上的運行。OpenAFS需要高達1GB的大容量客戶機緩存，以允許訪問經常使用的文件。它是一個十分安全的基於kerbero的系統，它使用訪問控制列表(ACL）以便可以進行細粒度的訪問，這不是基於通常的Linux和Unix安全模型。開發協議IBM Public，運行在linux下。
MooseFs（derf.homelinux）
Moose File System是一個具備容錯功能的網路分布式文件統，它將數據分布在網路中的不同伺服器上，MooseFs通過FUSE使之看起來就 是一個Unix的文件系統。但有一點問題，它還是不能解決單點故障的問題。開發語言perl,可跨平台操作。
pNFS（pnfs）
網路文件系統(Network FileSystem,NFS)是大多數區域網(LAN）的重要的組成部分。但NFS不適用於高性能計算中苛刻的輸入書櫥密集型程序，至少以前是這樣。NFS標準的罪行修改納入了Parallel NFS(pNFS），它是文件共享的並行實現，將傳輸速率提高了幾個數量級。
開發語言c/c++,運行在linu下。
googleFs
據說是一個比較不錯的一個可擴展分布式文件系統，用於大型的，分布式的，對大量數據進行訪問的應用。它運行於廉價的普通硬體上，但可以提供容錯功能，它可以給大量的用戶提供性能較高的服務。google自己開發的。
問題九：分布式存儲都有哪些，並闡述其基本實現原理 神州雲科 DCN NCS DFS2000（簡稱DFS2000）系列是面向大數據的存儲系統，採用分布式架構，真正的分布式、全對稱群集體系結構，將模塊化存儲節點與數據和存儲管理軟體相結合，跨節點的客戶端連接負載均衡，自動平衡容量和性能，優化集群資源，3-144節點無縫擴展，容量、性能歲節點增加而線性增長，在 60 秒鍾內添加一個節點以擴展性能和容量。
問題十：linux 分布式系統都有哪些？ 常見的分布式文件系統有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自適用於不同的領域。它們都不是系統級的分布式文件系統，而是應用級的分布式文件存儲服務。
GFS（Google File System）
--------------------------------------
Google公司為了滿足本公司需求而開發的基於Linux的專有分布式文件系統。。盡管Google公布了該系統的一些技術細節，但Google並沒有將該系統的軟體部分作為開源軟體發布。
下面分布式文件系統都是類 GFS的產品。
HDFS
--------------------------------------
Hadoop 實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。 Hadoop是Apache Lucene創始人Doug Cutting開發的使用廣泛的文本搜索庫。它起源於Apache Nutch，後者是一個開源的網路搜索引擎，本身也是Luene項目的一部分。Aapche Hadoop架構是MapRece演算法的一種開源應用，是Google開創其帝國的重要基石。
Ceph
---------------------------------------
是加州大學聖克魯茲分校的Sage weil攻讀博士時開發的分布式文件系統。並使用Ceph完成了他的論文。
說 ceph 性能最高，C++編寫的代碼，支持Fuse，並且沒有單點故障依賴， 於是下載安裝， 由於 ceph 使用 btrfs 文件系統， 而btrfs 文件系統需要 Linux 2.6.34 以上的內核才支持。
可是ceph太不成熟了，它基於的btrfs本身就不成熟，它的官方網站上也明確指出不要把ceph用在生產環境中。
Lustre
---------------------------------------
Lustre是一個大規模的、安全可靠的，具備高可用性的集群文件系統，它是由SUN公司開發和維護的。
該項目主要的目的就是開發下一代的集群文件系統，可以支持超過10000個節點，數以PB的數據量存儲系統。
目前Lustre已經運用在一些領域，例如HP SFS產品等。
F. 谷歌的分布式文件系統的優缺點
Google File System 文件系統
為了滿足Google迅速增長的數據處理需求，Google設計並實現了Google文件系統(GFS，Google File System)。GFS與過去的分布式文件系統擁有許多相同的目標，例如性能、可伸縮性、可靠性以及可用性。然而，它的設計還受到Google應用負載和技術環境的影響。主要體現在以下四個方面:
1. 集群中的節點失效是一種常態，而不是一種異常。由於參與運算與處理的節點數目非常龐大，通常會使用上千個節點進行共同計算，因此，每時每刻總會有節點處在失效狀態。需要通過軟體程序模塊，監視系統的動態運行狀況，偵測錯誤，並且將容錯以及自動恢復系統集成在系統中。
2. Google系統中的文件大小與通常文件系統中的文件大小概念不一樣，文件大小通常以G位元組計。另外文件系統中的文件含義與通常文件不同，一個大文件可能包含大量數目的通常意義上的小文件。所以，設計預期和參數，例如I/O操作和塊尺寸都要重新考慮。
3. Google文件系統中的文件讀寫模式和傳統的文件系統不同。在Google應用(如搜索)中對大部分文件的修改，不是覆蓋原有數據，而是在文件尾追加新數據。對文件的隨機寫是幾乎不存在的。對於這類巨大文件的訪問模式，客戶端對數據塊緩存失去了意義，追加操作成為性能優化和原子性(把一個事務看做是一個程序。它要麼被完整地執行，要麼完全不執行)保證的焦點。
4. 文件系統的某些具體操作不再透明，而且需要應用程序的協助完成，應用程序和文件系統API的協同設計提高了整個系統的靈活性。例如，放鬆了對GFS一致性模型的要求，這樣不用加重應用程序的負擔，就大大簡化了文件系統的設計。還引入了原子性的追加操作，這樣多個客戶端同時進行追加的時候，就不需要額外的同步操作了。
總之，GFS是為Google應用程序本身而設計的。據稱，Google已經部署了許多GFS集群。有的集群擁有超過1000個存儲節點，超過300T的硬碟空間，被不同機器上的數百個客戶端連續不斷地頻繁訪問著。