吴小智2021-10-01老师能否抽时间讲一下 GFS 中 5.2 Data Integrity 章节关于数据完整性的内容，论文说是不同的 chunkserver 独立检查数据的完整性，不怎么看懂，老师能否解答下。作者回复: 对于数据完整性和校验的基本问题，可以去看「深入浅出计算机组成原理」里面的49和50两讲。 关于GFS我简单回单一下： GFS其实包括后面的BigTable这些数据都是用类似的方式来保障 Data Integrity。 * 把数据按照固定尺寸打包，比如GFS里就是64K大小一个包 * 针对这个包计算一个Checksum验证码，通常用CRC33 * 然后读的时候会校验，发现数据和校验码不一致，就认为Data Corrupted，然后从别的副本拿到正确的数据 这个事情chunkserver不需要任何额外信息，只需要本地的数据就好了，所以叫独立检查数据的完整性。
共 2 条评论6
峰2021-09-29如果在写入时就保证文件是ok的，那么就是要做个失败重试，即，写入失败就整个放弃重新写一个文件。 另一个思路是，记录下每次发其写入请求是失败还是成功，以及每次写入的大小，也就形成了一个list（成功失败，写入大小）每次读电影文件的时候，就可以根据这个信息，读文件了，比如开始读失败了，所以跳过这次写入大小，读成功了，则读取这次写入大小。 怎么保存这个信息存的是ok的，又可以专门为gfs，设计一种文件格式来保证或者当作文件的元数据信息存入master（当然不是好思路）。作者回复: 👍 这是一个合理的思路，就是在写的时候保障，并且通过元数据管理来做这个事情。这样的话，也能够分段并行写。
共 2 条评论6
zhanyd2021-09-29如果我们通过 GFS 的客户端要写入一部电影到 GFS，然后过一阵再读出来，我们都可以有哪些方式，来保障这个电影读取之后能够正常播放呢？ 可以按照老师说的，给每一条要写入的数据生成一个唯一的ID，并且在里面带上当时的时间戳，读取的时候再按ID的顺序去重读取即可。作者回复: 这份分组传输的方式的确是一个有效的办法
3
在路上2021-09-29徐老师好，非常感谢对CAP问题的分享，希望能多分享一些中文资料。回答老师的问题，如果保证一部电影写入GFS之后，读出来能正常播放？可以将电影数据拆分成k份，每一份的大小小于GFS单次追加的数据，在每一份数据前面增加电影编号和数据块编号，以便在读取时重新组装数据。如果数据顺序写入GFS，读取时只需要去重，如果数据并发写入GFS，读取时既需要去重，也需要重排序。考虑到播放电影这个业务场景，可以采用64位数据保存电影id，32位数据保存数据块编号，减掉这12B的数据，剩余的数据（16MB-12B）存储电影数据。电影通常是顺序播放的，所以数据最好顺序写入GFS，便于快速读取电影接下来的内容。作者回复: 在读取数据的时候排序不是一个好办法，主要是电影这么大的数据肯定是流式传输获取，不太可能全都读过来排序。 不过分组组装的思路是没错的。
共 2 条评论1
密码1234562023-03-27 来自江苏提个问题，文中提到当前chunk写不下填充数据，换下一个chunk。如果遇到多个chunk都写不下当前数据，怎么优化？如果都填充数据，感觉又浪费不少空间。作者回复: 我没太理解你的问题。 数据本身会先分片，分片后，一个分片一定是小于一个block大小的。 在一个chunk肯定是空的一定写得下。但是的确如果所有文件都是略大约1/2 block大小，那么就会存在一半空间被浪费的情况。
webmin2021-10-01一个chunk有64MB，追加一次16MB，这个是不是有点像是一个嵌套数组，第一维定位chunk，第二维定位每次追加写入，管理文件块与管理内存块比较类似。 思考题： 可以参考TCP协议，TCP是流式协议，向网络写入1MB，在传输的过程中，这一1MB会被切分为若干包，在包外套上一层TCP协议的头，其中有Seq等信息，交换机在传输的过程中有可能会通过多条路径来传输数据，数据到达目标机器的先后顺序不一定和发送顺序一至，包到达目标机器后，如果前序还未达到，OS是不会让应用程序读取到这些数据的，只有Seq按序的包到达OS才提供给应用程序，那么同理GFS也可以给16MB的块加上一个协议头其中可以包含序号等信息。作者回复: 不太一样，追加一次不是一定16MB，是最多16MB。实际存储还是连续的，比如你可以追加一条1KB的日志，不然空间利用也太浪费了。 的确，通过分组传输是一个常见的计算机领域的办法。
Amon Tin2022-01-04“客户端可能读出来的数据里，前一小时是《星球大战》，后一小时是《星际迷航》。” 我理解这个问题是因为在并发随机写的场景下，两个客户端从master拿到的写入chunk handle和写入的偏移位置是相同的，虽然主副本在写入缓存区时对多个客户端的写入顺序做了排序，但由于这两个写入操作都指定了是要往同一个偏移位置写，所以不管排序结果是先执行《星球大战》的写入，还是先执行《星际迷航》的写入，他们都一定会写到同一个偏移位置上，导致数据被覆盖。 而追加写入过程中，客户端不需要获取具体的写入偏移位置，所以主副本在对多个写入请求排序后，一定会保证后写入的是追加在先写入的偏移位置之后的，就不会写入覆盖的情况发生。 不知道我的理解正不正确。6
thomas2021-11-29老师请问： 本节介绍的追加写为什么没有用到上一节课介绍的流水线式的数据存储，而是由主副本节点分别向次副本节点同步？ 而且追加写是GFS保存数据的主要方式，那依然存在网络传输的瓶颈共 2 条评论6- thomas2021-10-19为什么要给空间不足的chunk 填满空数据后，再寻找下一个chunk? 不填充空数据有什么问题？共 2 条评论3
稻草人2022-06-12“至少一次”那里1、产生的脏数据如何处理的呢？ 是否会造成空间浪费；2、另外的两个并发客户端也产生了数据，这部分数据也是没用的，又是怎么处理的呢？2