在 2003 年那个时间点，可能还没有现在主流的 Paxos/Raft 一致性算法工程实现。 Paxos made simple 论文是 2001 年发表的。 Raft 是 2014 年发表的论文。 所以 GFS 的 master 和 chunkserver 都没有采用 Paxos/Raft 强一致性算法来维护强一致性。 Master 是个单点，由主从日志同步来保证可用性。 Chunkserver 管理三副本，采用与 Client 协调的宽松一致性。
设计上，传统的文件系统接口复杂且低效， GFS 放弃传统文件系统语义的完全兼容，提供了适合大多数业务场景的语义模型：大文件，追加写，客户端校验文件完整性。从而实现了一个满足企业内部需求的高性能简单可靠的分布式文件系统。数据修改可以是普通写入或记录追加。 写操作会在应用程序指定的文件偏移量处写入数据。 记录追加操作至少会原子地在并发修改的情况下附加一次数据（第 3.3 节），但以 GFS 指定的偏移量进行附加。
写数据的流程也与常见的系统不一样。在 GFS 中一次写操作，数据和控制流是分开的。客户端先向 chunkserver 链式推送数据，然后再由 primary chunkserver 来决定数据写入顺序和位置。在主流的一些系统中，写操作都没这么做，比如 GFS 的开源实现 HDFS以及另一个常见存储系统 Ceph。 GFS 这个实现上肯定是要复杂很多。我求证了一下 AI，结论是这样的。GFS的机制（数据推送+主副本协调）在开源系统中未被广泛采用，主要原因包括：
- 复杂度高 ：租约机制、主副本故障切换等实现难度大，HDFS等系统选择简化设计以降低工程成本。
- 场景差异 ：多数开源系统面向批处理（如HDFS）或小文件存储（如TFS），无需GFS的高并发追加能力.
PS：现在大模型作为工具，来辅助阅读论文已经非常非常好用了，大大的提高像我这样英语不是特别好的人的阅读效率。推荐大家可以使用像沉浸式阅读这样的工具，再配置上 deepseek v3 这样的大模型，翻译的同时还可以提问。另外还可以使用元宝/qwen的论文阅读工具。