《Google File System》思考
阅读完《Google File System》论文后，心中有不少疑惑，一些问题在网上查询后整理如下：
单master节点如何做到高可用
GFS论文中对master的高可用描述是5.1.3节中的Master Replication一节，为了可用性，一个操作日志和checkpoint会在多个机器上存有master副本。一个更改操作日志只有刷入所有机器的磁盘中才算成功。为简单起见，一个master进程仍然负责所有的更改操作以及后台活动，如在内部更改系统的垃圾收集。当它失败时，几乎可以立即重启。如果其机器或磁盘发生故障，位于GFS之外的监控基础设施会启动一个其它地方含有副本操作日志的新master进程。此外，影子master提供文件系统只读的访问权限，即使当主master异常时也是这样。但是影子master的信息会落后主master大概不到1秒。
实际应用中，应该存在一组master集群，进行选主后，会选择出来一个主master，其它的机器都当做备master。当主master异常之后，集群中剩下的机器再次进行选主。
引出的新问题
(1) 如何选主？(2) 当主master异常后，客户端如何处理？
master如何维护文件和目录的关系
GFS论文中对命名空间管理的描述在4.1节的Namespace Management and Locking一节，不像许多传统文件系统，GFS没有描述列出所有文件的目录结构，也不支持文件和目录的别名（也不支持链接）。GFS用一个查找表映射全路径到元数据来逻辑表示命名空间，通过前缀压缩，可以在内存中有效地表示这个查找表。名称空间树中的每个节点(绝对文件名或绝对目录名)都有一个关联的读写锁。
所以文件系统的目录结构在内存中用一个字典树之类的结构表示，GFS中的文件和目录用全路径表示的话，就会有很多重复的前缀，因此利用字典树存储可以节省很多内存。下图就是一棵字典树，树中存放{in, inn, int, tea, ten, to}字符串。利用字典树可以很容易的确定一个目录或者文件的父目录，往上查找即可。所以操作/dir1/dir2/file文件时，很容易找到/dir1和/dir2目录，以及/dir1/dir2/file文件，可以很容易对着三个加锁。
?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQxMDQ1ODg=,size_16,color_FFFFFF,t_70)
针对用户态文件系统目录结构的表示，Ceph存储引擎BlueStore的用户态文件系统BlueFs利用C++中的map容器来表示父目录和子文件的联系。
GFS原子记录追加操作的chunk内偏移是由谁指定的？master还是chunk的主副本？
GFS论文3.3节Atomic Record Appends一节说到，传统的追加操作是由客户端指定文件的末尾偏移，而GFS将数据至少一次原子性的追加到由GFS选择的末尾偏移位置。而其中一段说到
The primary checks to see if appending the record to the current chunkwould cause the chunkto exceed the maximum size (64 MB). If so, it pads the chunkto the maximum size, tells secondaries to do the same, and replies to the client indicating that the operation should be retried on the next chunk.
意思是主副本检查append记录是否超过了当前chunk的最大大小，如果超过就pad当前chunk，并提示客户端从下一个chunk开始追加。因此chunk的末尾偏移应该是由chunk的主副本决定。
部分副本执行记录追加写失败会发生什么？
GFS论文3.3节Atomic Record Appends一节说到，主副本首先将记录追加到chunk末尾，然后让从副本也在chunk相同的位置执行相同的追加操作。现在考虑如下情况：
数据A追加成功，追加数据B时，一个从副本追加失败，于是返回给客户端失败的消息，并且下一个追加数据C依然从B数据之后的位置追加。之所以这么做的原因是主副本追加B成功了，但是可能还不知道其它副本追加的情况，这时候数据C要追加到末尾，为了性能着想，主副本不判断数据B的副本是否都追加成功，直接将数据C追加到B之后。随后主副本获悉有副本追加B失败后，就会让客户端重试B的追加。追加D的时候，主副本失败，而从副本追加成功，这时下一个数据E会从D的位置开始追加，因为主副本失败就必定意味着追加操作失败，原本D这个位置就可以重复利用。
追加失败后，如何判断文件偏移和chunk偏移的映射关系
GFS论文2.7.1 Guarantees by GFS一节中提到，当记录追加成功后，会返回客户端GFS选择的追加偏移。但是论文没有说明master如何知道文件和chunk的映射关系的。2.4 Single Master一节中提到，GFS客户端会将文件和文件内偏移转换chunk索引，然后客户端会把文件和chunk索引发送给master，master恢复chunk handle和chunk所有副本的位置。这说明GFS客户端也知道文件和chunk的映射？？？？
在数据追加期间，版本号没有变化的情况下，一个chunk副本下线一段时间，这段时间内，其它chunk副本均已更新，该chunk副本再次上电会发生什么？
在主chunk向该chunk副本发送更新请求的时候，就已经联系不上该chunkserver，这时候主chunkserver会向master报告，让master再次选择一个chunk副本。