这是我参与「第四届青训营 」笔记创作活动的第4天
gfs是谷歌十几年前的分布式存储系统实现，这篇论文中的设计有许多值得学习的地方，我们想将其中的一些设计应用到大作业中。
gfs中的设计细节收集
- 将文件分块（但是不同的是GFS的chunk非常大，大小为64MB）
- 每一个chunk有一个global id (chunk handle即句柄)
- master的操作会有备份以及checkpoints ，这些东西会被被分到别的机器上，为了保证master的高可用， GFS中存在一些shadow master，这些shadow master会读master的log，然后在自己的本地维护metadata。另外一种方案是Google实现了一套master能够容错的系统--chubby（开源版本就是大名鼎鼎的zookeeper），从这可以看出容错也是有限的，七个九是很高的安全性了。
- 每一个chunk会被复制大概3份,热点数据可能会被分成更多份
- master会管理所有的metadata （包括 文件名到句柄的映射 全局5.唯一id映射到chunk所具体存在的server上），mater还会管理chunk的垃圾回收，chunk迁移，健康情况检测
- 将控制序列与数据序列分开 ，具体就是 master只负责metadata，client会找mater去要metadata，然后client拿到metadata后会直接去找GFS的chunk server，最后拿到实际的数据。其将一次IO的过程分为了2部分，第一步是找master拿metadata，第二步是找chunk server拿真实的数据
- GFS没有cache，GFS基本上都是顺序扫描文件（append操作），cache的存在不会有太大的作用。唯一可能的cache就是client端可能会缓存metadata，方便下次在lease时间内（60s）直接访问chunkserver。
- master对primary发布的租约时间可以续租
- master在需要时也可以收回lease
- 一个chunk大小是64mb，一个chunk会被分成64kb大小的block，也就是1024个block。每一个block会有一个32bit的checksum。chunkserver会在自己空闲时检查每个块的完整性，如果它认为某一个块被污染了，那它会报告给master，master会让它把这个块删除。也就是说chunkserver不能自作主张把chunk删除，它需要master给它的指令。
