Colossus：Google 第二代集群级文件系统的设计与演进

基于公开资料的系统性综述（学习笔记）

摘要

Colossus 是 Google 的集群级（cluster-level）分布式文件系统，接替 2003 年在 SOSP 发表的 Google File System（GFS）。GFS 的元数据全部放在单台 Master 的内存里，大约在 5000 万文件、10 PB 量级就遇到扩展上限；面对 Gmail 这类延迟敏感业务，它分钟级的故障切换也无法接受。Colossus 主要做了四件事：

元数据分布化：把文件系统元数据存进 Bigtable，由可水平扩展的 Curator 服务管理，单集群规模比最大的 GFS 集群扩大 100 倍以上；
简化编程模型：采用 append-only、单写者（single-writer）语义，去掉 GFS 中代价高、语义模糊的并发 RecordAppend 和快照等特性；
客户端驱动的冗余：复制与 Reed-Solomon / LRC 纠删码都在客户端库里完成，数据在客户端与 D 文件服务器之间直接传输；
以 TCO 为目标的放置：Custodian 做后台均衡和重建，借助 L4 分布式 SSD 缓存和机器学习驱动的准入/放置策略，把 SSD 与 HDD 混合使用。

据 2025 年的公开数据，多个 Colossus 文件系统容量达到数 EB，其中两个超过 10 EB；最大的文件系统读吞吐超过 50 TB/s、写吞吐超过 25 TB/s，最繁忙的单集群 IOPS 超过 6 亿。Colossus 支撑着 YouTube、Gmail、BigQuery、Spanner、Bigtable 和 Cloud Storage 等几乎所有 Google 产品。本文还整理了 GFS 迁移到 Colossus 的 “Moonshot” 工程（2010–2012），并把 Colossus 与 HDFS、Meta Tectonic 做了对比，最后列出公开资料尚未覆盖的开放问题。

关键词：分布式文件系统；元数据扩展；纠删码；存储分层；Flash 缓存；存储 TCO；Google 基础设施

文档性质说明：Google 至今未发表过专门介绍 Colossus 的学术论文。本文按照学术论文的组织方式，汇总 Google 官方博客、技术演讲幻灯片、SRE 报告，以及以 Colossus 为背景的同行评审论文（ATC / FAST / SOSP / ASPLOS / OSDI），对 Colossus 的设计动机、架构、数据路径、冗余机制、存储效率优化和工程演进做系统性还原。

为了区分信息的可信程度，正文用三种标记：

【官方】：Google 官方博客、演讲或论文中的明确表述。

【论文】：以 Colossus 或 Google 存储集群为背景、经同行评审的论文。

【推断】：本文作者根据多份资料归纳得出、官方没有直接确认的结论，阅读时请谨慎对待。

1 引言

1.1 研究动机

2003 年发表的 GFS 论文 [1] 奠定了现代大数据存储的基础，Hadoop HDFS 等开源系统直接沿用了它的设计。但 GFS 发表时，Google 内部其实已经在为它的局限付出越来越高的代价。2009 年，GFS 技术负责人 Sean Quinlan 在 ACM Queue 访谈 [2] 中坦言，单 Master 设计”最初只是权宜之计”，并透露 Google 已经开发了两年的”分布式 Master 系统”。2010 年，Andrew Fikes 在 Faculty Summit 的演讲 [3] 中第一次公开提到 Colossus 这个名字。

此后十多年，Colossus 一直是 Google 存储栈的基石，但只有零散的演讲和博客介绍过它。对存储系统研究者和工程师来说，Colossus 的价值在于它代表了一条与 HDFS 不同的演进路线：用分布式数据库托管文件系统元数据、用客户端承担冗余编码、用集群级资源解耦提升 TCO。这条路线后来在 Meta Tectonic [16] 等系统中得到了印证。

1.2 本文贡献

资料整合：把 2009–2025 年间分散的官方资料与 9 篇相关论文整合成一个连贯的技术叙事；
架构还原：系统梳理 Curator、Custodian、D Server、Client Library、L4 等组件的职责与交互；
数据路径分析：以 2017 年 PDSW 主题演讲 [4] 和 2025 年 Rapid Storage 博客 [7] 为主要依据，还原文件元数据格式、stripe 状态机、有状态 handle 协议和所有权 fencing 机制；
效率机制剖析：深入介绍 Colossus Flash Cache 的 CacheSack 准入算法 [8] 和 L4 writeback 放置；
对比与反思：横向对比 GFS、HDFS、Tectonic，总结设计启示和尚未公开的问题。

1.3 资料来源概览

编号	资料	年份	类型	主要贡献
[1]	The Google File System (SOSP)	2003	论文	前身系统
[2]	GFS: Evolution on Fast-forward (ACM Queue)	2009	访谈	GFS 局限与新设计方向
[3]	Storage Architecture and Challenges (Fikes)	2010	幻灯片	首次公开 Colossus
[4]	Cluster-Level Storage @ Google (Serenyi, PDSW)	2017	幻灯片	元数据设计、TCO 理念
[5]	Colossus under the hood (Cloud Blog)	2021	博客	组件架构
[6]	How Colossus delivers SSD performance at HDD prices	2025	博客	规模数据、SSD 放置、L4
[7]	Colossus: secret ingredient in Rapid Storage	2025	博客	有状态协议、追加写、fencing
[8]	CacheSack (USENIX ATC / ACM TOS)	2022/2023	论文	Flash Cache 准入算法
[9]	Case Studies in Infrastructure Change Mgmt (SRE)	2020	报告	GFS→Colossus 迁移史
[10]	SRE Book, Ch.2 Production Environment	2016	书	存储栈分层
[11]	Spanner (OSDI)	2012	论文	首篇明确提及 Colossus 的论文
[12]	Wide LRCs (FAST)	2023	论文	生产环境宽条带纠删码
[13]	Morph (SOSP)	2024	论文	文件生命周期冗余转换
[14]	Thesios (ASPLOS)	2024	论文	基于 I/O 采样的反事实分析
[15]	Availability in Globally Distributed Storage Systems (OSDI)	2010	论文	故障模型
[16]	Facebook’s Tectonic Filesystem (FAST)	2021	论文	同类系统对照
[17]	Disks for Data Centers (Google 白皮书)	2016	白皮书	磁盘”集合视角”
[18]	Snap (SOSP)	2019	论文	主机网络栈

2 背景：GFS 及其局限

2.1 GFS 设计回顾

GFS [1] 于 2001 年设计，2003 年发表，核心假设是：

组件故障是常态而不是例外；
文件以大文件为主（数百 MB 到数 GB）；
写入以追加为主，读取以大块顺序读为主；
高持续带宽比低延迟更重要。

据此，GFS 采用了以下架构：

                 ┌──────────────┐
  控制流         │  GFS Master  │  单进程；全部元数据常驻内存
 ┌──────────────▶│ (namespace,  │  shadow master 只提供只读服务
 │               │  chunk map)  │
 │               └──────────────┘
┌┴─────────┐
│GFS Client│      数据流（流水线复制，3 副本）
└┬─────────┘
 │     ┌────────────┐   ┌────────────┐   ┌────────────┐
 └────▶│Chunkserver │──▶│Chunkserver │──▶│Chunkserver │  64 MB chunk
       └────────────┘   └────────────┘   └────────────┘  存在本地 Linux FS 上

2.2 规模化后暴露的问题

GFS 上线约六年后（2007 年前后），它的局限开始集中暴露 [9]。综合 [2][3][4][9]，主要问题如下：

问题类别	具体表现	出处
元数据容量	每个文件和 chunk 的元数据必须放进 Master 内存，受单机内存上限约束；GFS 实际扩展到约 5000 万文件、10 PB	[3][9]
元数据吞吐	Master 每秒只能处理”几千次操作”；MapReduce 一次启动上千个任务、各自打开大量文件时，Master 压力很大	[2]
可用性	Master 是”容错但不是高可用”（fault tolerant, not HA）；故障切换从早期人工处理的约 1 小时，优化到分钟级，最后到数十秒级，对面向用户的应用仍然不可接受	[2][4]
重启恢复	chunk 位置没有持久化索引，Master 重启要重新收集所有 chunk 的位置，耗时 10–30 分钟	[9]
CPU 利用	Master 部分代码是单线程，无法充分利用 SMP 硬件	[9]
文件数量	平均文件小于 64 MB 时，元数据与数据量之比恶化；共享 cell 中最常被用户撞到的就是文件数配额	[2]
尾延迟	chunk 恢复限速在 5–10 MB/s，一个 64 MB chunk 恢复约需 10 秒；为提高吞吐，大量操作排进队列，可能卡住数秒	[2]
语义问题	RecordAppend 不防重放：数据可能重复、乱序，不同副本内容不一致；Quinlan 评价它”事后看来弊大于利”	[2]
快照复杂度	通用快照（更像 clone）实现代价高，实际使用很少	[2]
上层复杂度	大文件设计把复杂度推给了上层应用（”Large files increased upstream app complexity”）	[3]

2.3 过渡方案：Multi-cell 与 Namespace

在 Colossus 成熟之前，GFS 采用了两类”打补丁”式的扩展方案 [2]：

Multi-cell：在同一个 chunkserver 池上部署多个 GFS Master（例如 8 个），由应用自行把数据分到不同 cell；
静态 Namespace：用一个 “namespace 文件” 描述日志等数据在多个 cell 之间的分区方式，对应用隐藏分区细节，但分区是静态的。

此外，Bigtable 的日志会同时打开两个 GFS 文件写入，一个卡住就切到另一个；Gmail 则依靠多数据中心多宿主来规避 GFS 的停顿 [2]。这些手段说明，在应用层绕过存储层的缺陷，代价已经越来越高。

2.4 新系统的设计目标

2009 年，Quinlan 透露了新的”分布式 Master 系统”的目标 [2]：

按平均 1 MB 文件设计，而不是 64 MB；他认为 1 MB 是合理的折中，再小会带来过多磁盘寻道；
每个 Master 支持约 1 亿个文件，可以部署数百个 Master；
“没有任何一个 Master 持有全部数据”；
充分利用 Bigtable。

2017 年 Serenyi 把 “GFSv2” 的目标概括为三点 [4]：更大（Bigger）、更快（Faster）、尾延迟更可预测（More predictable tail latency）。

3 设计目标与核心取舍

3.1 “解决一个更简单的问题”

Colossus 最关键的设计决策之一是收窄文件系统语义。根据 [4]，Colossus 最初的定位是”一个给 Bigtable 用的文件系统”，因此可以：

语义特性	GFS	Colossus（初始定位）
写入模型	随机写 + 并发 RecordAppend	仅追加（append-only）
并发写者	多写者	单写者、多读者
快照	支持（类 clone）	不支持
重命名	支持	不支持（初始定位）
目录	有层次目录	认为目录没有必要

【官方】2025 年的博客 [6] 也确认：”Colossus 把 GFS 的编程模型简化为 append-only 存储系统，兼具文件系统熟悉的编程接口与对象存储的可扩展性。”

【推断】这种收窄有三层意义：

消除 RecordAppend 的语义陷阱：单写者让副本间的顺序由唯一写者决定，不再需要 GFS 那种”至少一次、可能重复”的弱语义；
元数据操作简化：没有 rename 和目录树，元数据可以按完整路径做扁平的键值组织，天然适合 Bigtable 的有序键空间（同一”目录”的文件在键空间里相邻，仍然可以做前缀扫描）；
大幅降低分布式元数据的一致性难度：rename 和快照是分布式文件系统元数据层最难做的跨分片操作。

注：后来的生产版 Colossus 是否加入了 rename 等能力，公开资料没有说明。2021 年博客提到 Colossus 支撑了”home directories”等负载 [5]，所以生产版本对外暴露的语义可能比 2017 年描述的初始定位更丰富。

3.2 核心设计原则

原则	体现	出处
元数据水平扩展	自动分片的元数据层，存于 Bigtable	[3][4][5]
控制面与数据面分离	Client 只向 Curator 请求元数据，数据直接读写 D Server	[5][6]
复杂度下沉到客户端	软件 RAID、编码、复制由 client library 完成；”client 可能是整个文件系统最复杂的部分”	[5]
前台与后台分离	Curator 处理交互式操作，Custodian 做后台维护	[5][6]
存储节点极简	D 只做磁盘读写和校验	[9][10]
资源解耦与共享	一个集群一个 Colossus，多业务共享存储池	[4][5][6]
以 TCO 为优化目标	“让磁盘既满又忙”（keep disks full and busy）	[4]

4 系统架构

4.1 整体架构

综合 [4][5][6][7][8]，Colossus 的组件关系如下：

┌──────────────────────────── 应用进程（Borg task）────────────────────────────┐
│  Bigtable / Spanner / BigQuery / GCS / YouTube ...                           │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │ Colossus Client Library（进程内）                                      │  │
│  │  - 软件 RAID / 复制 / Reed-Solomon / LRC 编码                          │  │
│  │  - 缓存文件 handle（含数据所在磁盘的地址）                             │  │
│  │  - 并行写多副本 + quorum；读重建                                       │  │
│  └───────┬──────────────────────┬───────────────────────────┬─────────────┘  │
└──────────┼──────────────────────┼───────────────────────────┼────────────────┘
           │ ① 控制操作           │ ③ 缓存查询                │ ② 数据读写（类 RDMA 协议）
           ▼ (open/create/delete) ▼                           ▼
┌─────────────────────┐  ┌──────────────────────┐   ┌──────────────────────────┐
│ Curators（控制平面）│  │ L4 / Flash Cache     │   │ D File Servers           │
│ 可水平扩展          │  │ Cache Index Servers  │   │ HDD D servers            │
│ 运行在 Bigtable     │  │ (CacheSack 准入)     │   │ SSD D servers            │
│ tablet server 中    │  └──────────────────────┘   │ 仅负责读写原始数据 + 校验│
└─────────┬───────────┘                             └──────────────────────────┘
          │ 读写文件元数据                                     ▲
          ▼                                                    │ 均衡 / 重建 / 迁移
┌──────────────────────┐        ┌──────────────────────────────┴───┐
│ 元数据库：Bigtable   │        │ Custodians（后台存储管理）       │
│ 一行 = 一个文件      │◀──────▶│ 磁盘空间均衡、RAID 重建、        │
│ 内存 locality group  │        │ 冷热数据迁移、持久性与可用性维护 │
└─────────┬────────────┘        └──────────────────────────────────┘
          │ Bigtable 自身的数据又存在一个更小的 Colossus 上（递归）
          ▼
   ……  元元数据  →  …  →  Chubby（递归终点）

整个系统都运行在 Borg 之上 [5][9]。Google 的三大基础构件是 Colossus（集群级文件系统）、Spanner（全球一致数据库）、Borg（调度器）：Borg 分配资源，Spanner 存储权限与数据位置等元数据（指 Cloud 存储服务一层），Colossus 负责存储和访问数据本身 [5]。

4.2 Client Library

【官方】[5] 原文：”The client is probably the most complex part of the entire file system.” 客户端库的职责包括：

软件 RAID 与编码：按应用需求选择不同的编码方式（复制或 RS 编码等），在性能和成本之间权衡；
客户端驱动的复制：Fikes 的幻灯片写作 “Client-driven replication, encoding and replication” [3]；这和 GFS/HDFS 的 chunkserver 流水线复制不同，由客户端直接并行写多个目标；
handle 缓存：open 后缓存 handle，后续读写直接使用其中的磁盘地址 [7]；
数据重建：据社区资料，RS 编码数据的重建在客户端和服务端都可以进行，从而支持 on-the-fly 恢复（来自 CockroachDB 社区评论，为非官方信息）。

【推断】把编码放在客户端有几个好处：(1) 写放大只发生在客户端到 D 的网络上，不需要存储节点之间额外转发；(2) 不同应用可以使用不同编码而不影响服务端；(3) 读重建可以绕开慢节点或故障节点，改善尾延迟。代价是客户端库升级困难，需要多版本共存，而且客户端要消耗 CPU 做编码。

4.3 Curator：可扩展的元数据服务

【官方】[5][6]：

Colossus 的基础是由众多 Curator 组成的可扩展元数据服务；
客户端直接与 Curator 交互，执行文件创建、删除等控制操作；
Curator 可以水平扩展；
在追加流程中，Curator 负责构造 handle并发给客户端 [7]；
接管写入所有权时，Curator 递增各数据副本上的版本号来实现 fencing [7]；
在 L4 writeback 模式下，Curator 按 L4 的建议决定新文件放 SSD 还是 HDD，到期后负责把数据从 SSD 迁到 HDD [6]。

【官方】[4]：CFS（Colossus File System）的 Curator 运行在 Bigtable 的 tablet server 中。

【推断】Curator 运行在 tablet server 进程内，元数据操作就能在本地访问对应的 tablet，省掉一跳 RPC。Curator 的分片自然和 Bigtable 的 tablet 划分对齐，由 Bigtable 自动完成 split 和负载均衡。

4.4 元数据存储：为什么是 Bigtable

4.4.1 选型过程

Serenyi 在 [4] 中回顾了当时的选项：

候选方案	评价（原文）
GFS	lacks useful database features（缺乏有用的数据库特性）
分片 MySQL + 本地盘 + 复制（Ads 数据库在用）	poor load balancing, complicated（负载均衡差、复杂）
本地 KV + Paxos 复制（Chubby）	doesn’t scale（无法扩展）
Bigtable	“hmmmmmm….” —— 最终选择

选择 Bigtable 的理由 [4]：

自动把数据分片到各个 tablet；
通过元数据查找定位 tablet；
语义易用；
点查和范围扫描都高效。

文件系统元数据放在 Bigtable 的内存 locality group 中，以保证低延迟 [4]。

【官方】[5]：把文件元数据存入 Bigtable，使 Colossus 的规模比最大的 GFS 集群扩大 100 倍以上。Colossus 最初的动机，就是解决 GFS 存放 Search 相关元数据时遇到的扩展瓶颈。

4.4.2 元数据行格式

[4] 给出了一个文件元数据的示意：

Row key: /cfs/ex-d/home/denis/myfile          ← 一行对应一个文件
├── is-finalized?  mtime, ctime, ...           ← 文件属性
├── encoding  r=3.2                            ← 编码方式
├── stripe 0: checksum, length  → chunk0  chunk1  chunk2
├── stripe 1: checksum, length  → chunk0  chunk1  chunk2
└── stripe 2: OPEN              → chunk0  chunk1  chunk2

要点：

一个 Bigtable 行对应一个文件；
文件由一系列 stripe 组成，stripe 是复制组（replication group）；
stripe 有三种状态：open → closed → finalized；
每个 stripe 记录校验和与长度，下挂若干 chunk（分布在不同 D server 上）；
示例中的 encoding r=3.2 表示编码参数。幻灯片没有解释其精确含义，可能指 3 副本加某个写入/持久化阈值，本文不做确定解释。

【推断】append-only 加上 stripe 状态机，使”文件尾部”成为唯一可变区域：只有最后一个 stripe 处于 OPEN 状态，此前的 stripe 一旦 closed/finalized 即不可变。这让元数据更新高度局部化（只改一行中的末尾列），后台转码（例如副本转 RS）也可以以 finalized stripe 为单位安全进行。

4.4.3 递归托管：Colossus on Colossus

Bigtable 本身的数据（SSTable 和日志）也要存在文件系统上，这就产生了”先有鸡还是先有蛋”的问题。[4] 的解决方式是递归：

100 PB 数据           → 10 TB 元数据（元数据约为数据量的 1/10000）
10 TB 元数据          → 1 GB 元元数据（存在一个更小的 Colossus 上）
1 GB 元元数据         → 100 KB 元元元数据
100 KB                → 放进 Chubby！

【官方】[4] 还展示了迁移期的过渡形态：应用 Bigtable 的数据存在 Colossus（D chunkservers）上，CFS 自己的元数据 Bigtable 当时仍然存在 GFS 上（”Note: GFS still present, storing file system metadata”）。也就是说，Colossus 最初是”骑”在 GFS 上起步的。

4.4.4 一个资料上的分歧

Meta 的 Tectonic 论文 [16] 在相关工作中写道 “Colossus uses Spanner … to store filesystem metadata”，与 Google 官方 [4][5] 所说的 Bigtable 不一致。【推断】可能的解释有三种：(a) Tectonic 作者把 Cloud Storage 层（其对象元数据确实存于 Spanner [5]）与 Colossus 层混淆了；(b) Colossus 元数据后来的确部分迁移到了 Spanner；(c) 表述不严谨。以 Google 官方资料为准，即 Bigtable。

4.5 D File Server

【官方】综合 [5][9][10]：

D 是 Disk 的缩写，是 GFS chunkserver 的对应物，运行在 Borg 上；
D 是存储栈的最底层，被设计为唯一能直接读写物理磁盘的应用；
D 同时管理 HDD 和 Flash（”although D uses both spinning disks and flash storage”）[10]；
D 管理原始数据的访问，Colossus 管理”哪些数据在哪个 D 上”的映射；
客户端先向 Colossus 查询应读写哪些 D，然后直接和 D 通信 [9]；
2021 年博客称其为”我们的网络附加磁盘（network attached disks）”[5]；
社区资料说 D 更像块服务器而不是文件服务器，除校验和外基本不提供其他功能（非官方）。

D server 自身带有 buffer cache，会把最近访问的数据缓存在内存中几秒，并做少量预取；Google 鼓励 Colossus 用户设计负载时利用这层缓存 [8]。

与 Diskless 的关系：2012–2018 年的 Diskless 项目 [9] 把计算节点上的本地盘全部移除，2013 年部署了 Google 第一代”存储专用硬件”（只有磁盘、没有本地计算的磁盘服务器）。这让 D 能运行在专门优化的存储硬件上，显著改善了尾延迟。Diskless 的动机包括：磁盘性能增长慢于 CPU、SSD 和网络；生产任务死亡中 25%–30% 归因于磁盘故障；计算与存储解耦后可以独立采购 [9]。

4.6 Custodian

【官方】[5][6]：Custodian 是后台存储管理器，负责：

维护数据的持久性与可用性（例如在磁盘故障后做 RAID 重建）；
磁盘空间均衡；
维持整体效率。

【推断】结合 [4] 的”Colossus 会重新均衡老的冷数据”和 [13] 的转码描述，Custodian 很可能还负责：冷数据向大容量盘迁移、副本到纠删码的转码（或转码调度）、维护期间的数据可用性保障。Custodian 与 Curator 分离，确保这些高吞吐的后台任务不和交互式元数据操作争抢资源。

4.7 部署单元：一个集群一个 Colossus

【官方】[6]：

传统的 Colossus 文件系统局限在单个数据中心；
Colossus 是 zonal 的：每个集群构建一个 Colossus 文件系统，集群是 Google Cloud zone 的内部组成单元；
大多数数据中心只有一个集群，因此无论跑多少负载，都只有一个 Colossus 文件系统；
跨集群、跨地域的可用性由上层（Spanner、Blobstore 等 “Planet” 层系统）负责 [3]。

Fikes [3] 描述的三层存储栈：

层级	职责	系统	故障尺度
Node	导出并校验磁盘	D	—
Cluster	集群内可用性	GFS/Colossus、Bigtable	磁盘年故障率 2–10%
Planet	跨集群可用性	Blobstore、Spanner	约每季度 1 次集群事件（计划内/外）

一个典型集群的规模 [4]：数万台机器、PB 级分布式 HDD、可选的多 TB 本地 SSD、10 GB/s 的二分带宽（2017 年数据）。

5 数据组织与数据路径

5.1 命名

公开资料中出现过两种路径形式：

/cfs/ex-d/home/denis/myfile（2017 年 [4]）；
/cns/ex/home/leg/partition=ssd/myfile（2025 年 [6]）。

【推断】第二段（ex / ex-d）像是集群（cell）标识，后面是用户或业务的目录。路径中可以嵌入放置参数（如 partition=ssd、partition=ssd.1），说明 Colossus 用路径来表达放置策略，从而对上层保持 API 不变。

5.2 读路径

App ──read(file, off, len)──▶ Client Library
  1. 若 handle 未缓存：向 Curator open，取得 handle（含 stripe→chunk→D 地址映射）
  2. （可选）向 L4 Cache Index Server 查询是否命中 SSD 缓存
       命中 → 从 Flash Server 读取
       未命中 → 从 HDD D server 读取；L4 异步决定是否让 Flash Server 从 D 拉取并缓存
  3. 按编码方式读取所需 chunk；若部分 chunk 不可用 → 读其他数据块与校验块在线重建

依据：[7]（handle）、[6][8]（L4 读缓存流程）。

5.3 追加写路径与有状态协议

【官方】[7] 详细描述了追加写：

   ┌─────────────┐  ① open(append)   ┌──────────┐
   │ Application │──────────────────▶│ Curator  │
   │ ┌─────────┐ │◀──────────────────│          │  构造 handle
   │ │ Colossus│ │                   └──────────┘
   │ │ Client  │ │  返回 handle（含磁盘地址），缓存在进程内
   │ └────┬────┘ │
   └──────┼──────┘
② write(log entry, 任意大小)
          │ ③ 按 handle 中的地址并行写所有副本
   ┌──────┼──────────────┬──────────────┐
   ▼      ▼              ▼              ▼
[Disk A]           [Disk B]        [Disk C]
       quorum 确认即返回，不等慢节点（straggler）

要点：

有状态 handle：handle 是一组状态，包含文件存储方式的全部信息，包括数据在哪些磁盘上；
元数据只在 open 时访问：后续读写不再经过 Curator，直接和磁盘通信；
并行写 + quorum：同时写多块盘，用 quorum 技术避免等待慢节点；
网络协议：使用”优化过的类 RDMA 网络协议”，详见 Snap 论文 [18]；
典型用户：Spanner 和 Bigtable 的事务日志位于数据库变更的关键路径上，需要超低延迟的持久化追加；BigQuery 的流式写入也依赖这一能力。

5.4 所有权转移与 Fencing

单写者模型面临一个经典问题：旧写者”假死”后又恢复，可能与新写者同时写入。[7] 描述了 Colossus 的解决方式：

t0: Client 1 持有所有权，向 3 块盘上的对象追加数据
t1: 应用决定切换到 Client 2；Client 2 以 append 模式 open
    → Curator 以事务方式在每个数据副本上递增版本号（version number）
t2: Client 1 再次追加 → 失败，因为它的所有权绑定在旧版本号上

此外，每次追加操作都携带写入偏移量（offset），保证在网络分区和请求重放时数据仍然正确 [7]。

【推断】这是一种典型的 epoch/generation fencing：版本号存在每个副本（D server）上，而不是只存在元数据服务中，因此即使旧客户端绕过 Curator 直接写盘，也会在存储节点处被拒绝。配合 offset 校验，就实现了幂等的追加，从根本上解决了 GFS RecordAppend “可能重复、可能乱序”的问题。

5.5 Rapid Storage：把有状态协议开放给云用户

2025 年 Google Cloud 推出的 Rapid Storage（zonal bucket）直接建立在 Colossus 有状态协议之上 [7]：

特性	实现
传输层	基于 gRPC 的双向流（streaming）
前置开销	鉴权、元数据访问等耗时操作在建流时一次完成，之后的读写直达 Colossus
延迟	读写均为亚毫秒级
吞吐	单个 bucket 支持 2000 万请求/秒
追加	支持对单个对象无限次追加，直到达到对象大小上限
断流恢复	客户端拿到 handle，流中断后可用它重建流
写者切换	同一时刻只允许一个流写同一对象，新流以事务方式接管所有权
生态	集成 Cloud Storage FUSE；原生支持 Hierarchical Namespace

这说明 Colossus 的数据面协议足以直接承载外部云产品，同时具备块存储级的延迟、并行文件系统级的吞吐和对象存储级的扩展性 [7]。

5.6 一致性语义小结

维度	GFS	Colossus（据公开资料推断）
写者	多写者 RecordAppend	单写者，所有权可转移（fencing）
追加语义	至少一次，可能重复/乱序/副本不一致	带 offset 的幂等追加 + quorum 持久化
元数据一致性	单 Master 内存，靠操作日志持久化	依托 Bigtable 行级原子性
已完成数据	可被覆盖写	finalized 后不可变

6 冗余、可靠性与可用性

6.1 从三副本到 Reed-Solomon

【官方】[3]：Colossus 数据通常使用 Reed-Solomon 编码（约 1.5 倍存储开销） 写入，而 GFS 用 3 副本（3 倍开销）。选择 RS 的原因：

成本，尤其是在跨集群复制时（每个集群各存一份时，1.5 倍与 3 倍的差距会成倍放大）；
现场数据和仿真都显示 MTTF 有所改善；
在成本与可用性之间有更灵活的选择。

不同应用可以选择不同编码 [5]，”Applications built on top of Colossus use a variety of encodings to fine-tune performance and cost trade-offs”。

6.2 故障模型：来自 Storage Analytics 团队的数据

Fikes [3] 引用了 Google Storage Analytics 团队（Ford 等，即 OSDI 2010 论文 [15] 的作者）的研究结论：

发现	数据	设计含义
大多数故障短暂	90% 的事件 < 10 分钟	不要立即启动恢复，”稍等再恢复是值得的”
故障常成簇出现	10% 的故障属于相关性突发	必须按故障域放置数据
小突发与机架相关性弱	大多数小突发与机架无关	—
大突发与机架高度相关	大多数大突发与机架高度相关	跨机架放置至关重要
相关性削弱复制收益	R=2→R=3：不相关故障下 MTTF 提升 3500 倍；相关故障下仅提升 11 倍	单纯增加副本数的收益被相关故障吞噬，需要更聪明的放置与编码

另外：磁盘年故障率为 2–10% [3]。

【推断】”元数据空间使可用性分析成为可能”（”Metadata space has enabled availability analyses”）[3]：元数据集中在 Bigtable 中，可以直接对全量文件、stripe 和 chunk 的分布做离线分析，这是单机内存中的 GFS Master 做不到的。

6.3 宽条带 LRC（Wide Locally Recoverable Codes）

FAST 2023 论文 [12]（Kadekodi 等，Google）提供了 Google 存储集群中纠删码的生产数据：

Google 的存储集群部署了宽度约 50 块和宽度约 80 块的 LRC；
样本来自四个存储集群，磁盘总数超过 170 万块；
宽条带更省空间，但更容易遇到同时多块失效：24 小时追踪显示，n≈80 的 LRC 中至少 4 块失效的 stripe 数远多于 n≈50 的；
论文提出 Uniform Cauchy LRC，在生产中观测到的不可用事件上可靠性提升 33%；
维护鲁棒部署（maintenance-robust deployment）：同一 stripe 的多个块不能落在同一维护域（一组同时进入维护的服务器或机架）中，否则一次计划内维护（例如内核升级）就可能让 stripe 不可用。

6.4 文件生命周期中的冗余转换

SOSP 2024 的 Morph 论文 [13]（CMU 与 Google 合作）分析了 Google 集群中最大的数据服务之一，揭示了典型的冗余生命周期：

1
2
3

写入 ──▶ 3 副本 ──(约 1 天)──▶ 窄 RS，如 RS(8,12)
                    ──(约 1 个月)──▶ 中等 LRC，如 LRC(32,38)
                    ──(数个月)──▶ 宽 LRC，如 LRC(64,74)

冗余方案由应用（数据服务）选择，而不是由文件系统决定；
每次转码（transcode）都要读出数据、重新编码、写入新文件、删除旧文件，I/O 开销巨大；
Morph 的估算：采用混合冗余（1 份副本 + 1 个 EC stripe）和 Convertible Codes 后，转码 I/O 可减少 95% 以上，写入与转码的总 I/O 可减少 50–60%，新数据的容量开销降低 20%。

注意：Morph 本身是在 HDFS 上实现的研究原型，并不等于 Colossus 的现有实现；但它的数据分析来自 Google 存储集群，因此可以反映 Colossus 上的负载特征。

6.5 磁盘自适应冗余（Tiger）

Tiger（OSDI 2022，Kadekodi 等，见 [12] 所附相关工作）研究了按实际观测到的磁盘故障率动态调整冗余度，同时不限制数据放置（以往的方案要求 stripe 只能放在故障率相同的磁盘子集群内）。它说明 Google 在探索把冗余开销进一步压到 RS 1.5 倍以下。

6.6 可用性机制小结

机制	作用
客户端并行写 + quorum	写入不受个别慢盘或故障盘拖累 [7]
客户端在线重建	读取时绕过不可用块
Custodian 后台重建	永久故障后恢复冗余度 [5]
延迟恢复	90% 的故障是短暂的，避免无谓的重建流量 [3]
故障域/维护域感知放置	应对相关性故障与计划内维护 [3][12]
fencing + offset	写者切换时的正确性 [7]
Bigtable 元数据	元数据层自身的高可用由 Bigtable 保证

7 存储效率：放置、均衡与 SSD 分层

这是 Colossus 公开资料中最详细、也最能体现其工程特色的部分。

7.1 TCO 视角：让磁盘”既满又忙”

Serenyi [4] 提出的核心理念：

“Most importantly, we care about storage TCO, not disk TCO. Storage TCO is the cost of data durability and its availability, and the cost of serving it. We minimize total storage TCO if we keep the disk full and busy.”

TCO 不只是磁盘售价：密度更高的磁盘 $/GB 可能更贵，但考虑电力、连接开销（插槽、计算、网络）和维修后，部署起来反而更便宜 [4][17]；
购盘策略：集群在持续增长，所以总是多种容量的磁盘混合；有一个总体的 IOPS 和容量目标，每次采购都让集群和整个机群更接近这个配比 [4]。

7.2 冷热数据的理想分布

   小盘                      大盘
┌─────────┐             ┌─────────────┐
│ 冷数据  │             │             │
│         │             │   冷数据    │
├─────────┤             │             │
│ 热数据  │             ├─────────────┤
└─────────┘             │   热数据    │  ← 每块盘的热数据量相同（磁头都在忙）
                        └─────────────┘  ← 剩余空间用冷数据填满（盘都是满的）

实现方式 [4][5]：

新写入的数据（较热）均匀分布到集群内所有磁盘；
数据变老、变冷后，被重新均衡到大容量磁盘上（分析类负载尤其适用，因为数据通常随时间降温）。

7.3 Flash 的定位：把 IOPS/GB 拉回磁盘能承受的范围

【官方】[4][5]：”只买刚好够用的 flash，把每 GB 的 I/O 密度推到磁盘通常能承受的范围内；只买刚好够用的磁盘，确保容量充足。”

[4] 中的粗略方案：

买 flash 做缓存，把 IOPS/GB 拉回磁盘的能力范围；
买磁盘满足容量，并把它们填满；
“希望磁盘都很忙”：不忙说明 flash 买多了；但又不能太忙；
如果为了 IOPS 而买磁盘，那么容量的提升就毫无帮助；
如果冷数据无限增长，就会有大量 I/O 能力富余。

7.4 填满磁盘为什么困难

[4] 列出了一系列现实约束：

文件系统在 100% 满时工作不正常；
没有空闲空间就无法为升级和维修下线容量；
各团队都不愿意贴着 100% 配额运行；
管理员对统计意义上的超卖（statistical overcommit）心存顾虑；
供应链存在不确定性。

并给出一个前瞻性判断：“与数据中心里几乎所有其他资源不同，磁盘 I/O 的成本在上升”（容量增长远快于 IOPS）。因此应用必须改变：让热数据更热（便于 flash 发挥作用），冷数据更冷。几年前写的应用，可能会迫使 Google 购买更小的磁盘，从而推高存储成本 [4]。白皮书 [17] 从磁盘硬件角度提出了同样的”集合视角（collection view）”。

7.5 SSD 放置的三种方式

【官方】[6]：

方式	用法	优点	缺点
强制全 SSD	`/cns/ex/home/leg/partition=ssd/myfile`	最简单，文件完整存于 SSD	最贵
混合放置	`/cns/ex/home/leg/partition=ssd.1/myfile`（只有 1 个副本在 SSD）	较便宜	存放 SSD 副本的 D server 不可用时，退化为 HDD 延迟
L4（主流）	由 L4 分布式 SSD 缓存动态选择	自动化，适合 Google 绝大部分数据	依赖预测的准确性

7.6 L4 读缓存与 Colossus Flash Cache

7.6.1 架构

L4 读缓存（ATC’22 论文称为 Colossus Flash Cache [8]）的架构如下：

             ① 缓存查询                ┌────────────────────┐
Client ───────────────────────────────▶│ Cache Index Server │  内存索引：key→flash 位置
   │  ◀──── ② 返回缓存位置 / miss ─────│  + ghost cache     │  不直接持有数据
   │                                   │  + CacheSack 模型  │
   │                                   └──────────┬─────────┘
   │                                              │ ④ 准入/淘汰指令
   │ ③ 命中：直接读                               ▼
   ├────────────────────────────────────▶  Flash Server (SSD)
   │                                              ▲
   │                                              │ ⑤ 被准入的数据由 Flash Server 直接从 Disk Server 拉取
   │ ③ 未命中：读磁盘                             │
   └────────────────────────────────────▶  Disk Server (Buffer Cache + HDD)

关键设计 [8]：

设计目标是减少 HDD 读取（降低 TCO），而不是降低延迟（延迟改善只是附带效果）；
服务对象包括 BigQuery、Bigtable、F1、Spanner 等数据库系统和一般 Colossus 用户；
Cache Index Server 各自负责一部分键空间，相互独立，单台故障不影响其他；
淘汰策略：每个 index server 管理一个由固定大小 Colossus 文件（通常 1 GiB）组成的 FIFO 队列；从队尾淘汰一个文件时，把其中最近使用的 28% 的块重新插入队头文件，近似 Second Chance / LRU，写放大系数约为 1.28；
ghost cache：在内存中记录每个 key 的最后访问时间，不管它是否真的在 flash 中，用于估算不同策略的收益。

7.6.2 为什么准入策略至关重要

Flash 的写入寿命有限，非顺序淘汰会造成写放大；
在 Colossus Flash Cache 的流量中，超过 60% 的数据只被访问一次 [8]，如果全部准入会严重磨损 flash；
早期使用 LARC（Lazy Adaptive Replacement Cache，第二次访问才准入），但在被访问多次的数据中，39% 恰好只被访问两次，这些第二次访问在 LARC 下都是 miss [8]；
早期还用写速率限流器兜底，过于粗暴：对所有负载一视同仁。

7.6.3 CacheSack 算法

CacheSack [8] 于 2021 年 5 月在生产环境上线，成为 Colossus Flash Cache 的默认准入算法：

流量分类：对 Bigtable 和 Spanner，类别 = 表名 + locality group + 类型；其他数据库类似；其他用户可以自行标注类别；未标注时使用 Colossus 文件路径中的用户名；
四种准入策略（按激进程度排序）：
NeverAdmit < AdmitOnSecondMiss (LARC) < AdmitOnMiss < AdmitOnWrite
成本模型：对每个类别、每种策略，估算磁盘读次数与写入 flash 的字节数（磨损成本）；
LRU 的 TTL 近似：把 LRU 缓存近似成保留时间为常数 D 的 TTL 缓存，用 ghost cache 中记录的访问间隔快速估算；
背包问题：在给定缓存容量下，为每个类别选一种策略，使总成本最小。原问题是 NP-hard 的组合背包，CacheSack 把它松弛为分数背包问题，并对一组 D 的候选值（127 个）分别求解后取最优；
完全去中心化：每个 index server 只用自己观察到的流量独立运行模型。

生产效果（与 LARC 相比）：

指标	ATC’22 版本	ACM TOS 扩展版
磁盘读减少	6%	9.5%
写入 flash 字节减少	26%	17.8%
TCO 改善	6.5%	7.7%

而且无需人工调参：此前 LARC 的参数需要大量人工调整 [8]。

7.7 L4 Writeback：在”出生时”决定放置

读缓存的根本弱点是新数据仍然先写 HDD。有两类负载不适合 HDD [6]：

写入后很快被读、又很快被删除的数据（例如大批处理作业的中间结果）；
大量小追加的数据（例如数据库事务日志）。

L4 writeback 的流程 [6]：

文件创建时 ──▶ 应用把特征传给 L4（文件类型、所存数据库列的元数据等）
           ──▶ L4 把文件归入"类别"，持续观察每个类别的 I/O 模式
           ──▶ 在线模拟多种放置策略：
                 "在 SSD 上放 1 小时" / "放 2 小时" / "不放 SSD" ...
           ──▶ 为每个类别选出最优策略，告知 Curator
           ──▶ Curator 把新文件直接写到 SSD
           ──▶ 到期后文件若仍存在，Curator 把数据从 SSD 迁到 HDD
                 最好情况：文件在迁移前就被删除，完全不产生 HDD I/O

难点在于：文件创建时，Colossus 只能看到创建它的应用和文件名，无法确定文件将如何被使用 [6]。L4 的做法是用按类别的统计规律代替对单个文件的预测。

副产品：容量规划。在线模拟还能预测”如果 SSD 容量多一些或少一些，L4 会如何放置”，从而估算不同 SSD 容量能从 HDD 卸载多少 I/O。这些信号直接用于SSD 采购决策，以及在应用之间调配 SSD 容量 [6]。

7.8 用反事实分析评估新策略：Thesios

ASPLOS 2024 的 Thesios [14] 从 Google 存储服务器上例行采集的降采样 I/O trace 出发，合成全分辨率的”假设性” I/O trace，用来做 what-if 分析。准确度：请求数 95–99.5%，利用率 90–97%，读延迟 80–99.8%。案例包括：

改变磁盘利用率、填充率和容量的影响；
评估新的数据放置策略；
部署低转速（RPM）磁盘对功耗和性能的影响；
增大存储服务器 buffer cache 的影响。

【推断】这说明 Colossus 的放置与硬件选型已经形成”采样 → 模拟 → 决策“的数据驱动闭环，避免在生产环境做昂贵且有风险的 A/B 实验。

8 规模与性能

8.1 规模数据演进

时间	指标	数值	出处
2003	GFS 最大集群	1000+ 节点、300+ TB	[1]
2010	GFS 扩展上限	约 5000 万文件、10 PB	[3]
2010	典型仓库级计算机	10,000+ 台机器、1 GB/s 网络、每台 6×1 TB 磁盘	[3]
2017	典型集群	数万台机器、PB 级 HDD、10 GB/s 二分带宽	[4]
2021	单集群	可扩展到 EB 级存储、数万台机器；比最大的 GFS 集群大 100 倍以上	[5]
2023	存储集群磁盘数	4 个集群合计超过 170 万块磁盘	[12]
2025	单文件系统容量	许多达到数 EB；两个超过 10 EB	[6]
2025	读/写吞吐	最大的文件系统经常超过 50 TB/s 读 / 25 TB/s 写	[6]
2025	IOPS	最繁忙的单集群超过 6 亿 IOPS（读写合计）	[6]

8.2 负载多样性

【官方】[6] 列出了同一套 Colossus 上的负载谱：

应用	I/O 大小	期望性能
BigQuery 扫描	数百 KB ~ 数十 MB	TB/s
Cloud Storage 标准层	KB ~ 数十 MB	数百毫秒
Gmail 邮件	小于数百 KB	数十毫秒
Gmail 附件	KB ~ MB	秒级
Hyperdisk 读取	KB ~ 数百 KB	< 1 ms
YouTube 视频存储	MB	秒级

产品级数据 [6][7]：

Hyperdisk ML 使用 Colossus SSD，支持 2500 个节点以 1.2 TB/s 的速度读取；
Rapid Storage 单个 bucket 支持 2000 万请求/秒、亚毫秒延迟。

8.3 资源解耦带来的统计复用

【官方】[5]：可以按低延迟负载（例如 YouTube 视频）的峰值来配置资源，再让批处理分析负载在空闲时段”填缝”，以更低的成本运行。[4] 中的集群示意图显示，同一台机器上同时运行着 YouTube Serving、Ads MapReduce、Gmail Bigtable 和 D Server，互补的负载让存储更便宜。

9 上层生态：Colossus 之上的系统

┌────────────── Planet 层（跨集群）───────────────┐
│  Spanner      Blobstore      Cloud Storage(GCS) │   ← 元数据多存于 Spanner
└────────────────────┬────────────────────────────┘
┌──────────── Cluster 层（集群内）────────────────┐
│ Bigtable   BigQuery(Capacitor)   Hyperdisk/PD   │
│ Firestore  Cloud SQL  Filestore  YouTube  Gmail │
│ ─────────────────── Colossus ────────────────── │
│ ─────────────────── D servers ───────────────── │
└─────────────────────────────────────────────────┘
               Borg（调度一切）

系统	与 Colossus 的关系	出处
Bigtable	Colossus 最早就是为它设计的后端存储；日志和 SSTable 存于 Colossus；Bigtable 又反过来托管 Colossus 的元数据	[4][9]
Spanner	tablet 状态存于 Colossus 上的类 B 树文件和 WAL 中；tiered storage（同一文件系统内 HDD 与 SSD 混用）基于 Colossus	[11][6]
BigQuery	存储层基于 Colossus；流式写入依赖低延迟追加	[6][7]
Cloud Storage	底层是 Colossus；使用 Colossus SSD 缓存支撑 AI/ML 负载；Rapid Storage 直接暴露 Colossus 有状态协议	[5][6][7]
Hyperdisk / Persistent Disk	VM 块存储，2020 年 Next 演讲专门讨论”VM 背后的存储基础设施”	[5][6]
Firestore / Cloud SQL / Filestore	都构建在 Colossus + Spanner + Borg 三大构件之上	[5]
YouTube / Gmail / Drive	2008 年起视频直接从 Colossus 流式播放；Gmail 是推动替换 GFS 的关键动因	[5][9]

Bigtable 与 Colossus 的互相托管是一个值得注意的设计：应用 Bigtable 存在 Colossus 上，Colossus 的元数据存在一个更小的 Bigtable（CFS Bigtable）上，后者的数据又存在更小的 Colossus（或迁移期的 GFS）上，最终终止于 Chubby [4]。

10 演进历程与工程实践

10.1 时间线

时间	事件	出处
2001	GFS 设计完成，成为 Google 第一个集群级文件系统	[3][9]
2003	GFS 论文发表于 SOSP	[1]
约 2007	GFS 局限集中显现（约上线 6 年后）	[9]
2006 年初	Colossus 初始实现可用，最初目的是作为超大 Bigtable 的后端存储	[9]
2007 年夏	Colossus 发展成可以替代 GFS 的完整集群文件系统	[9]
2008 年 1 月	第一个生产 Colossus cell 上线	[9]
2008 年 3 月	视频开始直接从 Colossus 流式播放	[9]
2009	Quinlan 在 ACM Queue 透露”分布式 Master”新系统	[2]
2010	存储 SRE 领导层宣布 Moonshot：要求 2011 年底前全部迁移完毕；同年 Fikes 首次公开 Colossus	[9][3]
约 2012	Moonshot 实际历时整两年完成	[9]
2012	Spanner 论文首次在学术论文中提及 Colossus	[11]
2012–2018	Diskless 项目：移除计算节点本地盘	[9]
2013	部署第一代存储专用硬件（磁盘服务器）	[9]
2016	《Disks for Data Centers》白皮书	[17]
2017	Serenyi 在 PDSW 做主题演讲，详细介绍元数据设计	[4]
2020	Next ‘20 演讲 “A peek at the Google Storage infrastructure behind the VM”	[5]
2021 年 4 月	Cloud 博客 “Colossus under the hood”	[5]
2021 年 5 月	CacheSack 上线 Colossus Flash Cache	[8]
2022–2024	CacheSack（ATC’22）、Wide LRC（FAST’23）、Thesios（ASPLOS’24）、Morph（SOSP’24）发表	[8][12][13][14]
2025 年 3–4 月	SSD 放置博客与 Rapid Storage 博客；Rapid Storage 产品发布	[6][7]

10.2 Moonshot：GFS 到 Colossus 的迁移

SRE 报告 [9] 详细记录了这次”Google 历史上最大的数据迁移”。

背景与规模：

宣布时 Colossus 仍处于原型阶段；
内部通讯称”可能出现小的故障，但值得”；VP Ben Treynor 表示”愿意承担更大风险，甚至接受故障，只要不丢客户数据”；
团队从 4 人发展到大量”20% 志愿者”，迁移完成后每个站点配置了 14–18 名专职 SRE 支持 Colossus 存储层；
大多数服务负责人需要手动修改作业配置。

工具：

工具	作用
配额与存储使用仪表盘	识别可从 GFS 回收给 Colossus 的配额，后来演变成全机群通用的资源利用率工具
配额迁移服务	自动、细粒度地把配额从 GFS 挪到 D，两边始终保留合适的余量（”边倒水边改桶的大小”）
迁移规划与调度工具	提供免费配额借用；分析目录结构、切分数据、生成 namespace 映射文件和批量迁移命令
迁移跟踪工具	跟踪所有 GFS→D 迁移，查看各数据中心可用容量
批量数据迁移服务	逐目录把文件从 GFS 拷贝到 Colossus，至今仍在使用

分阶段推进：

早期采用者：Video 和 Bigtable，它们受 GFS 限制最重，也最主动寻求替代方案；
两个季度的试点：Analytics、Google Suggest、Orkut 等较小的服务；
每个阶段都把经验沉淀为标准流程：每个服务的通用迁移任务、迁移后审计路径和权限、在 GFS 仍提供服务时需要多少配额来启动 Colossus cell 等。

Steamroller 子项目：从 GFS chunkserver 迁到 D 时，需要”凭空”变出 CPU、内存和存储资源，因为 GFS 早于 Borg，Borg 看不到 chunkserver 的资源账目。于是启动 Steamroller，在全机群范围内回收 Borg 作业多申请的资源（用 90 天窗口内内存的 P100 和 CPU 的 P99 作为新上限，并把所有 Borg 作业放进容器限制资源）。项目在一年内完成，但因为没有考虑内存的小尖峰，超限任务被 Borg 直接杀死，造成了局部服务中断。

经验教训：

强制统一截止日期让人感到”别无选择”；更好的做法是与复杂服务紧密合作，给小团队更多时间；
核心团队应从一开始就全职化，”按你拥有的团队去开发，而不是按承诺给你的团队”；
自动化与截止日期之间要有意识地取舍；如果当时有一个健壮的工作流引擎，能大幅降低迁移成本；
大规模基础设施变更必须多渠道广泛宣传，并尽量减小受影响范围。

11 对比分析

11.1 GFS / Colossus / HDFS / Tectonic

维度	GFS (2003)	Colossus	HDFS (Hadoop 3)	Tectonic (Meta, 2021)
元数据服务	单 Master，全内存	Curator（无状态化、可水平扩展）	单 Active NameNode（可选 Federation）	分层元数据服务（Name / File / Block）
元数据存储	Master 内存 + 操作日志	Bigtable（内存 locality group）	NameNode 内存 + EditLog	ZippyDB（分片 KV，Paxos）
元数据规模上限	约 5000 万文件 / 10 PB	比 GFS 大 100 倍以上；单 FS 超过 10 EB	数亿文件（单 NameNode）	EB 级 / 集群
数据节点	Chunkserver（存在本地 Linux FS 上）	D server（唯一直接访问磁盘的进程）	DataNode	Storage Node（Chunk Store）
块大小	64 MB chunk	面向约 1 MB 平均文件设计；stripe/chunk	128 MB block	Block（由 chunk 组成）
写模型	随机写 + 多写者 RecordAppend	Append-only，单写者 + fencing	Append-only，单写者（lease）	Append-only，单写者
复制方式	Chunkserver 流水线复制	客户端驱动，并行写 + quorum	DataNode 流水线复制	客户端驱动
纠删码	无（3 副本）	RS（约 1.5 倍）→ 宽 LRC（n≈50–80）	后台条带化 EC（Hadoop 3）	RS，客户端编码
冷热分层	无	L4 SSD 读缓存 + writeback、冷数据迁移到大盘	存储策略（HOT/COLD/ALL_SSD 等，手动）	依赖租户
多租户	多 cell 隔离	一个集群一个 FS，所有业务共享	通常按业务部署集群	一个数据中心一个集群，多租户共享
部署范围	集群	集群/zone；跨地域由上层负责	集群	数据中心；跨地域由租户负责
调度依赖	早于 Borg	运行在 Borg 上	YARN/K8s 可选	Twine

11.2 Colossus 与 Tectonic 的”趋同演化”

Tectonic [16] 在相关工作中明确说：”Like Tectonic, Colossus provides cluster-wide multi-exabyte storage where client libraries directly access storage nodes.” 两者在以下几点上独立地得出了相同结论：

用分布式数据库（KV）承载元数据，而不是自研内存元数据服务器；
客户端库很”厚”，直接访问存储节点，承担编码；
集群级多租户共享，用资源解耦换取 TCO；
语义收窄为 append-only 加单写者。

差别在于：Tectonic 公开了完整设计，包括元数据的分层分片、租户级流量隔离和应用级优化，可以作为理解 Colossus 的”开放参照物”。

12 讨论

12.1 设计启示

“先解决一个更简单的问题”：Colossus 最初只服务 Bigtable，因此可以大胆砍掉 rename、快照、目录、多写者等特性。这和 GFS 当年”为特定负载设计”的思路一脉相承，也说明语义收窄是扩展性的前提。
复用而不是重造：用 Bigtable 托管元数据，直接继承了分片、负载均衡、故障恢复和范围扫描能力。递归托管看起来”奇怪”，但因为元数据只有数据量的约 1/10000，递归层数很快收敛 [4]。
控制面一次、数据面多次：有状态 handle 把元数据开销集中到 open 时；后续 I/O 直连磁盘，再配合 quorum 写和类 RDMA 网络，实现了亚毫秒追加。
TCO 驱动的系统设计：优化目标是”存储 TCO”而不是单盘成本或延迟，所以会出现”新数据均匀打散、旧数据迁往大盘””只买刚好够用的 flash””flash 缓存的首要目标是减少磁盘读”等看似反直觉的决策。
用统计规律替代人工决策：从 LARC 的人工调参，到 CacheSack 的类别级背包优化，再到 L4 writeback 的在线模拟，不预测单个文件，只学习类别的统计行为；同一套模拟还被复用于容量规划。
故障是常态，但大多数故障短暂：90% 的故障在 10 分钟内恢复，因此”等一等再修”；相关故障让副本数的边际收益骤降，因此”放得聪明比放得多更重要”。
迁移本身就是系统的一部分：Moonshot 和 Steamroller 说明，替换基础存储的难点往往不在新系统本身，而在资源账目、配额、工具和组织协同。

12.2 尚未公开的开放问题

以下内容在公开资料中缺失或语焉不详，阅读时不要过度推断：

问题	现状
Curator 如何分片、如何处理跨分片操作（如果有 rename 的话）	只知道运行在 Bigtable tablet server 中 [4]
生产版本的完整 POSIX 语义子集	只知道 append-only、单写者；”home directories” 负载暗示可能存在更丰富的语义 [5][6]
stripe 的大小、chunk 的大小、`r=3.2` 等编码参数的精确含义	未公开
副本 → RS → LRC 的转码由谁触发、在哪里执行（客户端、Custodian 还是应用）	Morph 指出转码由应用决定 [13]，但 Colossus 内部机制未公开
加密的实现层次	SRE Book 提到 Colossus 提供复制与加密 [10]，细节未公开
多租户 I/O 隔离与 QoS	Fikes 在 2010 年把它列为挑战 [3]，现状未公开
quorum 写的具体参数和读一致性协议	只知道”quorum 技术避免等待慢节点” [7]
元数据为何没有迁移到 Spanner	官方仍称 Bigtable；Tectonic 论文称 Spanner，存在分歧 [16]
跨集群（多 zone）Colossus	2025 年博客用了”traditional Colossus filesystem is contained in a single datacenter”的表述 [6]，”traditional”一词暗示可能有新形态

13 结论

Colossus 是 GFS 在超大规模和低延迟需求双重压力下的系统性重构。它把单 Master 内存元数据替换为基于 Bigtable 的可扩展 Curator 服务，突破了 GFS 约 5000 万文件、10 PB 的上限，使单个文件系统扩展到 10 EB 以上。它收窄文件语义为 append-only 加单写者，并以版本号 fencing 和带 offset 的追加保证正确性，消除了 RecordAppend 的语义缺陷。它把复制与纠删码下沉到客户端，配合有状态 handle 和类 RDMA 协议，实现了数据库日志级的亚毫秒追加。它以存储 TCO 为核心目标，通过冷热均衡、L4 SSD 缓存、CacheSack 准入和 writeback 放置，在 HDD 的成本下提供接近 SSD 的性能。

Colossus 的演进也说明了一个工程现实：存储系统的竞争力既来自架构，也来自持续的数据驱动优化和大规模迁移的组织能力。 对需要设计或选型大规模存储系统的工程师来说，Colossus 与 Tectonic 的趋同演化，基本勾勒出了现代 EB 级集群文件系统的”标准答案”：分布式数据库托管元数据、厚客户端、append-only、纠删码优先、集群级多租户共享。

附录 A：术语表

术语	含义
Colossus / CFS	Google 第二代集群级文件系统；CFS 即 Colossus File System
Curator	Colossus 的元数据服务进程，处理 open/create/delete 等控制操作，构造 handle，运行在 Bigtable tablet server 中
Custodian	后台存储管理器，负责磁盘空间均衡、RAID 重建、持久性与可用性维护
D server	“Disk” 服务器，GFS chunkserver 的继任者，唯一直接读写物理磁盘的进程，管理 HDD 与 SSD
Handle	open 文件后由 Curator 返回的状态集合，包含数据所在磁盘的地址，客户端凭它直连磁盘
Stripe	文件的组成单元，也是复制组；状态为 open / closed / finalized
Chunk	stripe 内分布在不同 D server 上的数据块或校验块
L4	Colossus 的分布式 SSD 缓存/放置服务，支持读缓存与 writeback 两种模式
Colossus Flash Cache	L4 读缓存在 CacheSack 论文中的名称，由 Cache Index Server 与 Flash Server 组成
CacheSack	Colossus Flash Cache 的准入算法，按类别求解背包问题
LARC	Lazy Adaptive Replacement Cache，第二次访问才准入，是 CacheSack 之前的策略
Ghost cache	只记录 key 的访问时间、不存数据的影子缓存，用于估算策略收益
RS / LRC	Reed-Solomon 码 / 局部可修复码（Locally Recoverable Code）
Transcode	改变文件冗余方案（例如 3 副本 → RS → 宽 LRC）
Cell	由同一组进程管理的一组数据中心机器，是 GFS/Colossus/Borg 的部署单元
Moonshot	2010–2012 年 GFS → Colossus 全量迁移项目
Steamroller	为 Moonshot 回收 Borg 资源、为 D 腾出配额的配套项目
Diskless	2012–2018 年移除计算节点本地盘、全面转向远程存储的项目
Chubby	基于 Paxos 的分布式锁服务，Colossus 元数据递归托管的终点
Rapid Storage	Google Cloud 基于 Colossus 有状态协议的低延迟 zonal 对象存储

附录 B：推荐阅读路线

阶段	阅读材料	预计用时	目标
① 前置	GFS 论文 [1]、Bigtable 论文	3 h	理解出发点
② 动机	ACM Queue 访谈 [2]、SRE 报告 Moonshot 一章 [9]	1.5 h	理解 GFS 为什么必须被替换
③ 架构	Fikes 幻灯片 [3]、Serenyi PDSW 幻灯片 [4]、2021 年博客 [5]	1.5 h	掌握组件与元数据设计
④ 数据面	2025 年 Rapid Storage 博客 [7]、Snap 论文 [18] 相关章节	1.5 h	掌握 handle、quorum 追加、fencing
⑤ 效率	2025 年 SSD 博客 [6]、CacheSack [8]、Disks for Data Centers [17]	3 h	掌握 TCO 与 SSD 分层
⑥ 可靠性	OSDI’10 可用性论文 [15]、Wide LRC [12]、Morph [13]	4 h	掌握冗余与故障模型
⑦ 对照	Tectonic [16]	2 h	用一个完整公开的同类系统做对照

参考文献

[1] S. Ghemawat, H. Gobioff, S.-T. Leung. The Google File System. SOSP 2003. https://research.google/pubs/pub51/

[2] M. K. McKusick, S. Quinlan. GFS: Evolution on Fast-forward. ACM Queue 7(7), 2009. https://queue.acm.org/detail.cfm?id=1594206

[3] A. Fikes. Storage Architecture and Challenges. Google Faculty Summit, 2010-07-29. https://cloud.google.com/files/storage_architecture_and_challenges.pdf

[4] D. Serenyi. Cluster-Level Storage @ Google: How we use Colossus to improve storage efficiency. Keynote, PDSW-DISCS 2017. http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Keynote.pdf

[5] D. Hildebrand, D. Serenyi. Colossus under the hood: a peek into Google’s scalable storage system. Google Cloud Blog, 2021-04-20. https://cloud.google.com/blog/products/storage-data-transfer/a-peek-behind-colossus-googles-file-system

[6] L. Greenfield, S. Pollen. Colossus under the hood: How we deliver SSD performance at HDD prices. Google Cloud Blog, 2025-03-27. https://cloud.google.com/blog/products/storage-data-transfer/how-colossus-optimizes-data-placement-for-performance

[7] D. Serenyi, V. Saraswat. Colossus: the secret ingredient in Rapid Storage’s high performance. Google Cloud Blog, 2025-04。转载：StorageNewsletter

[8] T.-W. Yang, S. Pollen, M. Uysal, A. Merchant, H. Wolfmeister. CacheSack: Admission Optimization for Google Datacenter Flash Caches. USENIX ATC 2022. https://www.usenix.org/system/files/atc22-yang-tzu-wei.pdf ；扩展版 CacheSack: Theory and Experience of Google’s Admission Optimization for Datacenter Flash Caches. ACM TOS, 2023. https://dl.acm.org/doi/10.1145/3582014

[9] W. Look, M. Dallman. Case Studies in Infrastructure Change Management: How Google Rebuilds the Jet While Flying It. O’Reilly / Google SRE, 2020. https://sre.google/resources/practices-and-processes/infrastructure-change-management

[10] B. Beyer et al. Site Reliability Engineering, Chapter 2: The Production Environment at Google. O’Reilly, 2016. https://sre.google/sre-book/production-environment/

[11] J. C. Corbett et al. Spanner: Google’s Globally-Distributed Database. OSDI 2012.

[12] S. Kadekodi, S. Silas, D. Clausen, A. Merchant. Practical Design Considerations for Wide Locally Recoverable Codes (LRCs). USENIX FAST 2023. https://www.usenix.org/system/files/fast23-kadekodi.pdf ；相关工作：S. Kadekodi et al. Tiger: Disk-Adaptive Redundancy Without Placement Restrictions. OSDI 2022.

[13] T. Kim, S. Athlur, S. Kadekodi, F. Maturana, D. Delvira, A. Merchant, G. R. Ganger, K. V. Rashmi. Morph: Efficient File-Lifetime Redundancy Management for Cluster File Systems. SOSP 2024. http://www.pdl.cmu.edu/PDL-FTP/Storage/Morph_Final.pdf

[14] M. Phothilimthana, S. Kadekodi, S. Ghodrati, S. Moon, M. Maas. Thesios: Synthesizing Accurate Counterfactual I/O Traces from I/O Samples. ASPLOS 2024.

[15] D. Ford, F. Labelle, F. Popovici, M. Stokely, V.-A. Truong, L. Barroso, C. Grimes, S. Quinlan. Availability in Globally Distributed Storage Systems. OSDI 2010.

[16] S. Pan et al. Facebook’s Tectonic Filesystem: Efficiency from Exascale. USENIX FAST 2021. https://www.usenix.org/system/files/fast21-pan.pdf

[17] E. Brewer, L. Ying, L. Greenfield, R. Cypher, T. Ts’o. Disks for Data Centers. Google White Paper for FAST 2016. https://research.google.com/pubs/archive/44830.pdf

[18] M. Marty et al. Snap: a Microkernel Approach to Host Networking. SOSP 2019. https://research.google/pubs/snap-a-microkernel-approach-to-host-networking/

补充（非正式来源，仅供索引）：

P. Zemb. What can be gleaned about GFS successor codenamed Colossus? 2019. http://pierrezemb.fr/posts/colossus-google
Google Cloud Next ‘20. A peek at the Google Storage infrastructure behind the VM. https://www.youtube.com/watch?v=q4WC_6SzBz4

整理日期：2026-11-06。本文是基于公开资料的学习综述，不代表 Google 官方观点；标注【推断】的内容为整理者的分析，请结合原始资料核实。