关键问题：如何设计可扩展的文件协议

Andrew 文件系统（AFS）于 20 世纪 80 年代诞生于卡内基梅隆大学（CMU），由 M. Satyanarayanan（"Satya"）教授领导。它的首要目标很简单：规模（scale）——怎样设计一个分布式文件系统，让一台服务器支持尽可能多的客户端？

影响可扩展性的因素很多，最重要的是客户端与服务器之间的协议。上一章的 NFS 协议迫使客户端定期向服务器确认缓存内容是否改变；每次检查都消耗服务器资源（CPU、网络带宽），频繁检查就限制了一台服务器能服务的客户端数量。AFS 与 NFS 的另一个不同是：它从一开始就把合理的用户可见行为当作一等公民。NFS 的缓存一致性依赖于客户端缓存超时等底层实现细节，很难描述；AFS 的缓存一致性简单易懂：打开文件时，客户端通常会拿到服务器上最新的一致副本。

核心概念速览

AFS 第 1 版：整文件缓存

我们讨论两个版本：第一版（称为 AFSv1，原名 ITC 分布式文件系统）已有基本设计，但扩展性不达预期，于是重新设计出最终协议（AFSv2，简称 AFS）。

所有版本 AFS 的基本信条之一是在访问文件的客户端的本地磁盘上做整文件缓存（whole-file caching）：

应用第一次调用 open() 时，AFS 客户端代码（设计者称之为 Venus）向服务器发 Fetch 协议消息，传递目标文件的完整路径名（如 /home/remzi/notes.txt）。服务器（称为 Vice）遍历路径名，找到文件，把整个文件发回客户端；客户端把它存进本地磁盘上的缓存。之后应用的 read()/write() 被重定向到本地文件系统中的那份副本，完全不需要网络通信，很快。由于这些调用就像访问本地文件系统一样，被访问过的块还可能被缓存在客户端内存里，所以 AFS 也利用客户端内存缓存本地磁盘上的块。最后 close() 时，如果文件被修改过（被以写方式打开），客户端用 Store 消息把整个新版本和路径名发回服务器永久保存。

下次访问该文件时，AFSv1 会更高效：客户端先用 TestAuth 消息问服务器文件是否变了；没变就直接用本地缓存副本，省去网络传输。注意这个早期版本只缓存文件内容，目录只保存在服务器上。

表：原书 Figure 50.1，AFSv1 协议要点。

第 1 版的问题

为了找出问题所在，AFS 的设计者花了大量时间测量他们的原型。这种实验是好事：测量是理解系统如何工作、如何改进的关键。他们发现了两个主要问题：

• 路径遍历开销太高：每次 Fetch 或 Store 都把完整路径名（如 /home/remzi/notes.txt）交给服务器，服务器必须从根目录开始，先找 home，再在 home 中找 remzi……一路走到目标文件。许多客户端同时访问时，服务器的大量 CPU 时间就花在了沿目录路径往下走上。
• 客户端发出太多 TestAuth 消息：就像 NFS 的 GETATTR 过多一样，AFSv1 产生大量检查本地文件（或其 stat 信息）是否有效的流量。服务器把很多时间花在告诉客户端"可以用你缓存的副本"上，而绝大多数时候答案都是"文件没变"。

另外还有两个问题：服务器之间负载不均衡——通过引入卷（volume）解决，管理员可以在服务器之间移动卷来平衡负载；服务器为每个客户端使用一个独立进程，导致上下文切换等开销——AFSv2 改用线程构建服务器来解决。本章聚焦前两个限制可扩展性的协议问题。它们让服务器 CPU 成为系统瓶颈：每台服务器只能服务 20 个客户端，再多就过载。

AFS 第 2 版：回调与 FID

AFSv2 引入了回调（callback）来减少客户端与服务器的交互。回调就是服务器对客户端的一个承诺：当客户端缓存的文件被修改时，服务器会通知它。有了这份（保存在服务器上的）状态，客户端不再需要联系服务器确认缓存文件是否有效，而是假设它有效，直到服务器告诉它不是。这正好对应轮询（polling）与中断（interrupt）的区别（回想第 36 章 I/O 设备）。

AFSv2 还引入了文件标识符（file identifier，FID）（类似 NFS 的文件句柄），取代路径名来指定客户端感兴趣的文件。AFS 的 FID 由卷标识符、文件标识符和一个"uniquifier"组成（uniquifier 让文件删除后卷 ID 和文件 ID 可以被重用）。于是，客户端不再把整条路径交给服务器去走，而是自己逐级遍历路径，缓存每一步的结果，从而减轻服务器负担。

例如客户端访问 /home/remzi/notes.txt，其中 home 是挂载在 / 上的 AFS 目录（/ 是本地根目录，home 及其子项在 AFS 中）。客户端先 Fetch home 的目录内容放进本地磁盘缓存并在 home 上建立回调；再 Fetch 目录 remzi，缓存并建立回调；最后 Fetch 普通文件 notes.txt，缓存到本地磁盘、建立回调，然后把文件描述符返回给应用。下面的模拟器复刻原书 Figure 50.2（从 home 已缓存开始），并可切换到 AFSv1 对比：

与 NFS 的关键区别在于：每次取目录或文件时，AFS 客户端都会与服务器建立回调，确保服务器在其缓存状态改变时通知它。第一次访问 /home/remzi/notes.txt 会产生多条消息，但也为所有目录和 notes.txt 建立了回调，之后的访问完全在本地进行，不需要任何服务器交互。在文件已缓存在客户端这一常见情况下，AFS 的表现几乎和本地磁盘文件系统一样：第二次访问一个文件应该和访问本地文件一样快。

缓存一致性

讨论 NFS 时我们考虑过两方面：更新可见性（服务器何时拿到新版本？）和缓存陈旧（服务器有了新版本后，多久客户端才能看到新版本而不是旧的缓存副本？）。有了回调和整文件缓存，AFS 的一致性很容易描述，分两种情况：

• 不同机器上的进程之间：AFS 在同一时刻让更新在服务器上可见并使其他缓存副本失效——那就是被更新的文件被关闭时。客户端打开文件、（也许反复地）写它；最终关闭时，新文件被刷到服务器（于是可见）。此时服务器"打断"所有缓存了该文件的客户端的回调：逐个联系它们，告知其回调不再有效。这确保这些客户端不会再读陈旧副本：它们之后的 open 需要从服务器重新取新版本（并在新版本上重新建立回调）。
• 同一台机器上的进程之间：AFS 在这里做了例外——对文件的写立即对本地其他进程可见（不必等文件关闭）。这让单台机器的行为和典型 UNIX 语义完全一致，只有换到另一台机器上，才会察觉到更一般的 AFS 一致性机制。

还有一个值得讨论的跨机器情况：在罕见的情况下，不同机器上的进程同时修改一个文件，AFS 自然地采用最后写者胜（last writer wins）的方法（也许应该叫"最后关闭者胜"）：谁最后调用 close()，谁就最后把整个文件更新到服务器上，成为"胜出"的文件。结果是一个完全由某一个客户端生成的文件。对比 NFS 这样基于块的协议：各个客户端更新文件时，单个块的写可能陆续被刷到服务器，最终服务器上的文件可能是两个客户端更新的混合。很多情况下混合的文件毫无意义——想象一张 JPEG 图片被两个客户端分块修改，混合的结果多半不是合法的 JPEG。

下面的模拟器默认载入原书 Figure 50.3 的完整时间线：Client1 上有进程 P1、P2，Client2 上有进程 P3，所有操作都针对文件 F。服务器一列显示该行操作完成后服务器上的文件内容；被删除线划掉的缓存表示回调已被打断（失效）。你可以编辑操作序列，也可以切换到 NFS 语义，用同一串操作做对比。

逐行读 Figure 50.3，理解每次 read 为什么返回那个值：

• 第 5 行 P2 read → A：P1 写 A 并关闭，A 已存到服务器；P2 在同一台机器上打开，直接用本地缓存。
• 第 10 行 P2 read → B：P1 写了 B 但还没关闭，同一台机器上的 P2 立刻看到 B（本地进程遵循 UNIX 语义）。服务器上仍是 A。
• 第 13 行 P3 read → A：Client2 上的 P3 打开时，B 还只在 Client1 上，服务器仍是 A——远端进程看不到还没关闭的写。
• 第 15 行 P1 close：B 被存到服务器，服务器打断 Client2 的回调（缓存中的 A 被划掉）。
• 第 17 行 P3 read → B：P3 重新打开时回调已失效，于是重新 Fetch，得到 B。
• 第 21–26 行：P1 写 D、P3 写 C；P3 先关闭（服务器变为 C，Client1 的回调被打断，但 P1 仍在使用自己修改过的副本），P1 后关闭（服务器变为 D）。"不幸的 P3"：最后写者胜，P3 重新打开读到的是 D。

交错枚举：两个客户端的所有执行顺序

类似 AFS 模拟器 afs.py 作业的第 4–6 题：两个客户端各执行三步，一共有 C(6,3) = 20 种交错顺序。调度串中 0 表示让 Client1（P1）执行下一步、1 表示让 Client2（P3）执行下一步（与 afs.py -S 的记法相同）。先预测，再点"枚举"。点击任意一行，可以把它载入上面的时间线模拟器逐步查看。

崩溃恢复

从上面的描述你可能感觉到，AFS 的崩溃恢复比 NFS 复杂。没错。

设想服务器 S 有一小段时间联系不上客户端 C1（比如 C1 正在重启）。这期间 S 可能向 C1 发过一条或多条回调撤销消息：假设 C1 本地磁盘缓存了文件 F，然后 C2 更新了 F，于是 S 向所有缓存了 F 的客户端发消息，让它们从本地缓存中删掉 F。C1 在重启时可能错过这些关键消息，所以重新加入系统时，C1 应把所有缓存内容视为可疑：下次访问 F 时，先用 TestAuth 问服务器缓存的副本是否仍然有效；有效就用，否则从服务器取新版本。

服务器崩溃后的恢复也更复杂：回调保存在内存里，服务器重启后不知道哪台客户端缓存了哪些文件。因此服务器重启后，每个客户端都必须意识到服务器崩溃过，并把缓存内容视为可疑、在使用前重新确认有效性。服务器崩溃是件大事：必须确保每个客户端及时知道这次崩溃，否则就有客户端访问陈旧文件的风险。实现方式很多，比如服务器恢复后给每个客户端发消息（"别相信你的缓存内容！"），或者客户端定期检查服务器是否活着（心跳消息）。可以看到，构建更可扩展、更合理的缓存模型是有代价的；而用 NFS 时，客户端几乎注意不到服务器崩溃。在上面的时间线模拟器里，点"客户端宕机错过回调"或"服务器崩溃丢失回调"，再取消"恢复后把缓存视为可疑"，就能看到后果。

AFSv2 的规模与性能

新协议到位后，测量发现 AFSv2 的可扩展性大大提高：每台服务器可以支持约 50 个客户端（而不是 20 个）。另一个好处是客户端性能常常接近本地性能：常见情况下所有文件访问都是本地的，读文件通常访问本地磁盘缓存（也可能是本地内存）。只有客户端创建新文件或写已有文件时，才需要向服务器发 Store 消息。

原书 Figure 50.4 用简单的定性分析比较了常见访问场景下 AFS 与 NFS 的性能。小文件有 N_s 个块，中等文件 N_m 个块，大文件 N_L 个块；假设小、中等文件能放进客户端内存，大文件能放进本地磁盘但放不进内存。通过网络访问远程服务器的一个块需要 L_net，访问本地内存需要 L_mem，访问本地磁盘需要 L_disk，一般假设 L_net > L_disk > L_mem。第一次访问文件不命中任何缓存；之后的访问（"重读"）如果相应缓存装得下，就会命中。改改参数，看看比值：

几点观察（原书）：

1. 很多情况下两者性能大致相当。例如第一次读文件（工作负载 1、3、5），从远程服务器取文件的时间占主导，两个系统差不多。你可能觉得 AFS 要把文件写到本地磁盘会更慢，但这些写会被本地文件系统缓存吸收；同样，从本地磁盘缓存副本读看似更慢，但 AFS 同样受益于本地文件系统的内存缓存，读很可能命中客户端内存，性能与 NFS 相近。
2. 大文件顺序重读（工作负载 6）差异明显：AFS 有很大的本地磁盘缓存，再次访问时从那里读；NFS 只能在客户端内存里缓存块，比内存大的文件重读时必须从服务器重新取整个文件。所以 AFS 快 L_net/L_disk 倍（假设远程访问确实比本地磁盘慢）。而且 NFS 在这种情况下增加了服务器负载，也影响扩展性。
3. 新文件的顺序写（工作负载 8、9）两者相近：AFS 写到本地缓存副本，关闭时把数据推给服务器；NFS 把写缓冲在客户端内存中，可能因内存压力提前把一些块写到服务器，但关闭时一定会写，以保持 flush-on-close 一致性。AFS 写本地文件系统，同样先进入页缓存、稍后才在后台写盘，从而受益于客户端操作系统的内存缓存。
4. 顺序覆写（工作负载 10）AFS 更差：前面的写负载都是创建新文件；这里文件已存在并被覆写。AFS 客户端先把旧文件整个取回来，然后又整个覆盖掉；NFS 只是覆写块，省掉了开头那次（无用的）读。（假设 NFS 的写都是块大小且块对齐的，文件也不是用 O_TRUNC 打开的——否则 AFS 的 open 不会去取即将被截断的文件内容。）
5. 只访问大文件中一小部分数据（工作负载 7、11）NFS 好得多：AFS 在打开时取回整个文件，却只做了一次小读或小写；如果文件被修改，还要把整个文件写回服务器，性能影响翻倍。NFS 作为基于块的协议，I/O 量与读写大小成正比。

总的来说，NFS 和 AFS 做了不同的假设，自然得到不同的性能结果。这些差异重不重要，一如既往，取决于工作负载。

AFS 的其他改进

就像 Berkeley FFS 趁机加入了符号链接等新特性，AFS 的设计者也借机加入了许多让系统更好用、更好管理的特性：

先预测再验证

动手实验

cd labs/50-afs && make && ./afs_sim

=== Figure 50.3: AFS cache consistency timeline (~X = callback broken) ===
#   P1            P2            C1     P3            C2     Server
1   open(F)                     -                    -      -     
2   write(A)                    A                    -      -     
3   close()                     A                    -      A     
4                 open(F)       A                    -      A     
5                 read() -> A   A                    -      A     
6                 close()       A                    -      A     
7   open(F)                     A                    -      A     
8   write(B)                    B                    -      A     
9                 open(F)       B                    -      A     
10                read() -> B   B                    -      A     
11                close()       B                    -      A     
12                              B      open(F)       A      A     
13                              B      read() -> A   A      A     
14                              B      close()       A      A     
15  close()                     B                    ~A     B     
16                              B      open(F)       B      B     
17                              B      read() -> B   B      B     
18                              B      close()       B      B     
19                              B      open(F)       B      B     
20  open(F)                     B                    B      B     
21  write(D)                    D                    B      B     
22                              D      write(C)      C      B     
23                              D      close()       C      C     
24  close()                     D                    ~C     D     
25                              D      open(F)       D      D     
26                              D      read() -> D   D      D     
27                              D      close()       D      D     
messages: Fetch=4 Store=4 callback-breaks=3 TestAuth=0

=== Workload 1: client0 = open,write 1,close   client1 = open,read,close  (file starts as 0) ===
schedule  AFS  NFS(T=0)
000111    1    1
001011    0    1
001101    0    0
001110    0    0
010011    0    1
...
summary (20 interleavings):  AFS 0 x19  AFS 1 x1  NFS 0 x16  NFS 1 x4

=== Workload 2: client0 = open,write X,close   client1 = open,write Y,close  (file starts as 0) ===
schedule  AFS  NFS(T=0)
000111    Y    Y
001011    Y    Y
001101    Y    Y
001110    X    X
010011    Y    Y
...
summary (20 interleavings):  AFS X x10  AFS Y x10  NFS X x10  NFS Y x10

自测题

常见误区与小结