标签：6.824 GFS chunk record master checksum MIT append

文章目录

本文是MIT 6.824 Lec3 关于GFS的课前问题和答案。

Why is atomic record append at-least-once, rather than exactly once?

根据论文Section 3.1，Step 7。如果writer在某一个secondaries失败，client会重新尝试write操作，这会导致数据在正常的replicas上被写入了超过一次。

How does an application know what sections of a chunk consist of padding and duplicate records?

为了检测padding，applications可以在每个合法的record前加入一个可预测的随机数或加入一个只有当record valid的时候才valid的checksum。为了检测duplicate records，可以给每个record一个唯一的ID。当application读到的record与之前的record含有相同的id，则说明存在replicate records。

How can clients find their data given that atomic record append writes it at an unpredictable offset in the file?

采用append操作的应用大多都需要顺序地读取整个文件，因此它们并不需要知道record的具体位置。例如，文件中可能包含了由多个web爬虫爬取的url，及时不知道某个url在文件中具体的offset也无所谓，因为reader只是向读取整个文件的内容。

What’s a checksum

checksum算法将一个block内的bytes作为输入并输出一个数字。例如，输出的结果可能是所有输入bytes的简单加和。GFS将每个chunk的checksum存储起来。当一个chunkserver将一个chunk写入到disk中时，它会首先计算new chunk的checksum，然后将checksum和chunk存储到disk上。当checkserver从disk上读取chunk时，它会读取之前存储的checksum，然后根据chunk内容重新计算checksum，并检查两个checksum是否相同。如果数据发生了损坏，则checksum会不一致，并且checkserver会返回相应的错误。

The papaer mentions reference counts, what are they?

实现snapshot copy-on-write机制的一种技术。当GFS创建一个snapshot时，它并不会直接拷贝chunk，而是增加每个chunk的引用计数。如果一个client向chunk内写入内容，并且master发现该chunk的引用计数大于1，master会首先生成该chunk的拷贝以便client可以修改该拷贝。

If an application uses the standard POSIX file APIs, would it need
to be modified in order to use GFS?

是的

How does GFS determine the location of the nearest replica?

文章中指出它们当时使用的时IP地址来判断最近的replica，如果两个机器的IP地址距离很近，那么它们的物理距离就很近

Suppose S1 is the primary for a chunk, and the network between the
master and S1 fails. The master will notice and designate some other
server as primary, say S2. Since S1 didn’t actually fail, are there
now two primaries for the same chunk?

GFS中不会出现这种现象。当master赋予S1 lease时，lease的过期时间为60s，在S1的lease过期之前，master不会选举出新的primary。

How acceptable is it that GFS trades correctness for performance
and simplicity?

strong consistency通常需要大量的网络通信。GFS的设计目的是提供一个高速率的大规模文件处理系统，因此GFS放宽了对一致性的要求。例如在GFS的append操作中，record可能出现多次，GFS允许多个文件的append record不一致。一致性和性能的平衡性也是分布式系统中一个非常常见的问题。

What if the master fails?

GFS的设计中包含有master结点的replica，当master发生故障时，需要外部的集群监控系统认为的进行master结点的切换。

Why 3 replicas?

副本的数量应该最大可能的保证数据不会产生丢失，同时不会过多的影响系统的性能。这个数字应该跟disk的可靠性以及创建副本的时间相关。

Did having a single master turn out to be a good idea?

单Master结点的设计在最初看起来是非常易用的，但是并不适合一个长期运行的系统。谷歌在长期使用GFS后，发现单结点有以下问题：

• 文件数量的不断增长，导致metadata无法存放在一个master的RAM中
• client数量的增加，倒是master没有足够的性能来监管多个clients状态
• 当master故障时，需要人为进行master切换

谷歌后来使用了新的分布式文件系统Colossus，该系统采用了多master结点的架构。

What is internal fragmentation? Why does lazy allocation help?

internal fragmentation是大chunk带来的问题。如果我们需要创建一个1B大小的文件，由于chunksize大小为64MB，那么如果我们创建64MB大小的chunkfile，就会产生64MB-1B大小的内部碎片，从而大大的浪费空间。使用lazy allocation机制，当需要一个1B大小的文件时，GFS先创建一个1B大小的chunk linux file，如果后续有追加数据的需要，再扩充chunkfile。

标签：6.824,GFS,chunk,record,master,checksum,MIT,append
来源： https://blog.csdn.net/weixin_46840831/article/details/121851040

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。