以下にリンク論文がある。
<li><a href="https://209.85.163.132/papers/gfs-sosp2003.pdf" title="Google File System" target="_blank">https://labs.google.com/papers/gfs-sosp2003.pdf</a></li>
日本語の解説は
<li><span class="itemTitle" align="left"><a href="https://dev.ariel-networks.com/modules/xfsection/article.php?articleid=50" title="Google File System(GFS)技術メモ" target="_blank">Google File System(GFS)技術メモ</a></span></li>
が詳しい。以下、私も重要だと思ったポイントを挙げておこう。
（システム構成）<li>マスター、チャンクサーバ 、クライアントの3種類。基本的に安いPCでシステムが構築できるようにしている。</li>
<li>PC は壊れる（信頼はしていない）のが前提のもとにシステムを設計している。 </li>
<li>チャンクサーバにデータを格納する。</li>
<li>データは可用性向上（万一のため）3つのチャンクサーバに格納している。チャンクサーバが同じ電源を使っていたりしたら全部データが飛ぶ可能性があるので、さすがに別のラックのチャンクサーバ同士に保存するとか、空きディスク容量が多いチャンクサーバ（すなわち新品）へ、とか考慮している。データは基本的に64MBの固定長。分断されたデータをチャンクと呼ぶ。</li>
<li>マスターはチャンクサーバの位置、ファイル名（ディレクトリツリー）、ファイルのロックなどの管理。その情報はオンメモリで。</li>
<li>操作ログが大事で、マスターは永続ストレージに情報を保存せず、その代わりに操作ログは保存している。もし再起動が必要で環境を再構築する必要に迫られたら、操作ログから復元する。操作ログは適宜チェックポイントを設けているので、再構築はチェックポイントからとなる。</li>
<li>マシンが異常終了して落ちたとか、シャットダウン処理を行って終了したとかの区別はない。その2つは同じ「終了」としてみなしている（要は、常に異常終了してもいいように、マシン終了、再起動の場合は最悪の事態を想定して備えていれば間違いない、ということだろう）。</li>
<li>チャンクサーバはマスタにハートビート（キープアライブ）を打って生存を示している。</li>
<li>データは、アプリからは<b>追記</b>（append）と読み出しがメインのユースケースを想定。データが更新されたらランダム書き込みとかは考えない。どんどん新しいバージョンを追記していく方針。</li>
<li>データのキャッシュはしない。読み出しはどっちみちストリームだから。</li>
<li>3台ものマシンに同じデータを分散させるので、データの一貫性（consitency）が問題となる。これは、データのチェックサムでアプリが対処したり、マスターサーバがデータの参照カウント（バージョン）を保持して対応している。</li>
<li>3台ものマシンにデータを複製するので、レイテンシー（latency; 遅延）も問題となるように思うが、それはあまり重視していない。</li>
<li> ファイルの削除は、まずは削除したいファイルにマークするだけなので高速。3日後、バッチ的な処理で消す。</li>