Google File System疑问

今天花了一天看完了Google File System的论文，平时不注意专业名词的积累，确实蛮累的。其中碰到了一些疑问，赶紧记下来，不一定是对的答案，而是一些现在的想法。

1、Snapshot是如何实现的？
快照其实就是复制、备份。当进行快照之后，master马上在内存中对需要快照的文件标记一下。比如说文件foo需要快照，master就把foo的引用计数加1，foo的引用计数就变成2了。之后坐等copy-on-write发生。

什么是copy-on-write（COW）？
有N个进程同时读一个文件，系统只需要提供一份这个文件就行了。但如果有一个进程对这个这个文件修改，这个文件就会被系统单独复制一下，唯一的交给这个进程，这个进程以后就对复制的部分进行操作。详看《深入理解计算机系统》虚拟存储器，存储器映射。

就拿上面那个例子来说，当client要求改foo时，原先在内存中有2个指针（1个是snapshot生成的指针）指向foo，foo的引用记录是2，现在赶紧把foo复制一份，将这2个指针分别指向两个foo文件。然后把新生成的foo文件返回给client，client对它进行更改。

2、GFS是如何处理小文件的？
小文件应该就跟平时处理一样，gfs会提供小文件操作的api，不然一个文件至少就要占用一个64MB大的chunk么？

3、各个副本的数据是不是一样的？
GFS只保证所有并发操作都会被执行，lease过的primary chunk保证所有并发操作的顺序一样。这样能保证数据的一致性，但是要说到底哪个并发改了哪些数据，那就不清楚了，所以会被GFS标为undefined。

有了前2点还不能保证数据一样么？
对的，只能保证client在使用数据时感觉是一样。再精确来讲，是内容一样，但是数据不一样，不能保证bytewise identical。可能每个副本的经历不一样，比如某些副本在某些chunkserver上操作的时候，重试了好几次，造成gfs添加了一些padding数据在其中。

4、在现实的cluster测试当中，为什么第六部分所讲的写速率上限是66.7MB/s？
每个chunk是100Mb/s，16个chunk加起来是200MB/s。但是每个文件要复制3份，所以实际的写入速度还要除以3。

5、Record Append的速度为什么随着client的增加而减少？要是client继续增加，那速度岂不是慢地稀里哗啦？
论文中这里的速度是单独一个文件的record append速度。16个client一起上的时候，难免有congestion，所以追加速度会慢。（因为这里有并行，所以要么加锁，要么就要排队列）
实际上倒是不用担心，因为client可能有上千个，而client要进行的操作可能不仅是这一个，它可以选择先去操作其它文件。（不知道是不是这样）