30、深入解析文件系统备份与分布式文件系统

深入解析文件系统备份与分布式文件系统

1. 文件系统备份概述

在数据管理中，备份是至关重要的环节。备份的方式多种多样，对于小型环境而言，使用标准 UNIX 实用工具进行简单的快照备份或许就足够了。但在拥有多台服务器和大型磁盘阵列的大型环境中，这种简单的方法就难以满足需求，此时就需要企业级备份系统。

VxFS 存储检查点等特性不仅具有持久性，还具备可写性，这为众多新型应用提供了支持。备份和分层存储管理（HSM）应用可以协同工作，以最大程度地减少数据传输。

2. 集群和分布式文件系统的发展

随着计算机网络在 20 世纪 70 年代出现并在 80 年代广泛普及，在机器之间共享文件变得至关重要。最初，像 uucp 和 ftp 这样的 UNIX 工具被用于在机器之间传输文件。然而，当时磁盘相对昂贵，因此产生了在不进行本地存储的情况下通过网络访问文件的需求。

20 世纪 80 年代，UNIX 社区中出现了多种分布式文件系统，包括 Sun 的网络文件系统（NFS）、AT&T 的远程文件共享（RFS）以及卡内基梅隆大学的 Andrew 文件系统（AFS，后来发展成为 DCE 分布式文件服务（DFS））。其中一些分布式文件系统昙花一现，而 NFS 至今仍是最成功的，被广泛应用于全球数万个 UNIX 和非 UNIX 操作系统中。

分布式文件系统基于客户端/服务器模型运行，其中一台机器拥有基于磁盘的文件系统，并通过明确定义的协议向客户端提供文件。该协议和文件传输方式对用户来说是透明的，同时提供 UNIX 文件语义是其关键目标。

与之不同的是，集群文件系统将一组机器和磁盘视为一个整体，并从任何节点提供文件系统的完全一致视图。对于用户而言，集群文件系统呈现出单一一致的文件系统视图，并且可能提供也可能不提供完整的 UNIX 文件语义。集群文件系统以及本地文件系统都可以导出供 NFS 使用。

3. 分布式文件系统详解

分布式文件系统允许通过定义良好的协议访问远程机器上的文件，与本地文件系统不同，本地文件系统的存储是物理连接的，并且只能由同一主机上的进程访问。分布式文件系统采用客户端/服务器模型，单个文件系统服务器可以为多个客户端提供文件服务。

无论哪种类型的分布式文件系统，在客户端访问远程文件时提供 UNIX 文件语义都是至关重要的目标。过去 20 年中，为 UNIX 开发了许多分布式文件系统，但很多都已逐渐消失。到目前为止，最成功的分布式文件系统是 20 世纪 80 年代中期出现的 Sun 网络文件系统（NFS）。尽管 NFS 不像 DCE 分布式文件服务（DFS）那样功能丰富，但 NFS 协议的简单性以及其处于公共领域的特点，使其能够被移植到许多不同的操作系统中，包括 UNIX 和非 UNIX 系统。

4. 网络文件系统（NFS）

4.1 NFS 背景和历史

NFS 最初由 Sun Microsystems 在 20 世纪 80 年代初至中期开发，并取得了巨大成功，几乎可以移植到所有操作系统中。NFS 的目标包括：
- 提供机器和操作系统的独立性，确保 NFS 可以在 UNIX 和非 UNIX 操作系统上运行。
- 具备对服务器崩溃的恢复能力，当服务器崩溃时，当前访问服务器的客户端必须能够恢复，并且客户端无法区分服务器是崩溃重启还是响应缓慢。
- 实现透明的文件访问，使应用程序能够通过 NFS 以与访问本地磁盘文件相同的方式访问文件。
- 在客户端保持 UNIX 语义，为客户端上的应用程序提供 UNIX 文件语义。
- 具备可接受的性能，性能目标设定为本地磁盘访问速度的 80%。

NFS 由协议、客户端和服务器三部分组成。最初的 NFS 实现包含了协议的第 1 版和第 2 版，并于 1985 年在 SunOS 2.0 中公开提供。第 1 版协议仅在 Sun 内部使用。截至目前，遵循第 3 版协议的 NFS 实现已经使用多年，第 4 版实现也开始出现。NFS 在全球范围内被数万人熟知，这充分证明了它的成功，并且预示着它在未来多年仍将是最主要的分布式文件系统之一。

4.2 第 1 版和第 2 版 NFS 协议

SunOS 文件系统架构经过重新设计和实现，以支持多种文件系统类型并为 NFS 提供支持。NFS 还依赖于 Sun 远程过程调用（RPC）基础设施，该基础设施提供了一种跨网络的同步机制，允许一个进程（或内核）调用不同机器上的另一个进程。这使得 NFS 协议可以分解为一组指定参数、结果和效果的过程。

为了通过网络进行通信，NFS 在 Internet 协议（IP）之上使用用户数据报协议（UDP）。由于协议的设计要独立于机器架构和操作系统，因此协议消息及其响应的编码对字节序等问题很敏感，这导致使用了外部数据表示（XDR）规范。

第 2 版协议的过程调用如下表所示：
| PROCEDURE | ARGUMENTS | RETURN VALUE |
| — | — | — |
| null | null | null |
| lookup | directory_file_handle, name | file_handle, attributes |
| create | directory_file_handle, name, attributes | new_file_handle, attributes |
| remove | directory_file_handle, name | status |
| getattr | file_handle | attributes |
| setattr | file_handle, attributes | attributes |
| read | file_handle, offset, count | attributes, data |
| write | file_handle, offset, count, data | attributes |
| rename | directory_file_handle, name, to_file_handle, to_name | status |
| link | directory_file_handle, name, to_file_handle, to_name | status |
| symlink | directory_file_handle, name, string | status |
| readlink | file_handle | string |
| mkdir | directory_file_handle, name, attributes | file_handle, new_attributes |
| rmdir | directory_file_handle, name | status |
| readdir | directory_file_handle, cookie, count | entries |
| statfs | file_handle | filesystem_stats |

这些过程中引用的文件称为文件句柄，它是服务器响应查找请求时提供的不透明数据结构。客户端不应尝试解释文件句柄的内容。文件句柄通常由特定于操作系统的信息和文件系统提供的信息组合而成，其中文件系统提供的信息必须能够定位文件，因此文件句柄通常是文件系统特定信息、文件的索引节点号及其生成计数的组合。

许多过程涉及文件属性，这些属性与文件基本属性中的 stat 结构的各个字段相对应。NFS 服务器是无状态的，即服务器不会保留有关过去请求的信息，这避免了复杂的崩溃恢复机制。如果客户端在特定时间内没有收到服务器的响应，请求将被重试，直到成功为止。这使得服务器能够容忍崩溃和重启，确保客户端无法检测到服务器崩溃和响应缓慢之间的区别。

第 2 版协议还要求所有文件写入都是同步的，以实现 UNIX 文件语义。在文件句柄中通常会编码索引节点的生成计数，当文件被删除并重新使用索引节点时，可以通过生成计数来区分旧文件和新文件。

NFS 的一个主要目标是使其能够在不同的操作系统上移植，早期已经有将其移植到基于 SVR2.2 的 UNIX 版本和 Sequent Dynix 操作系统（一种 System V/BSD 混合系统）的示例。同时，也有许多基于 PC（DOS 系统）的 NFS 实现。

4.3 NFS 客户端/服务器通信

NFS 依赖于远程过程调用（RPC）和外部数据表示（XDR）规范来实现客户端和服务器之间的通信。XDR 允许描述和编码不同的数据类型，其目标是允许具有不同底层架构的机器之间进行通信。RPC 提供了创建客户端/服务器应用程序的基础设施，使应用程序能够像调用本地函数一样调用服务器提供的函数。

XDR 格式假设字节（8 位）是可移植的，即字节的编码在不同的架构或硬件设备之间不会改变。基于字节，XDR 规范要求数据类型由 4 字节的倍数构成。如果数据类型所需的字节数不能被 4 整除，则未使用的字节将被填充为零。字节的顺序是从字节流中读取时，高位字节总是先被读取，这称为大端序。XDR 还使用标准的浮点数表示（遵循 IEEE 标准）。

例如，一个 32 位整数的 XDR 编码如下：

byte 0
byte 1
byte 2
byte 3
most significant digit
least significant digit
32 bits

XDR 规范定义了许多基本数据类型，包括有符号和无符号整数、布尔值、64 位整数、固定和可变长度的不透明数据类型以及字符串。它还定义了广泛的结构化数据类型，包括数组、联合、链表和结构。基本上，任何在最流行的高级语言中可以定义的数据类型都可以在 XDR 中进行编码。

NFS 使用的 RPC 机制源自 Sun RPC，它为不同机器上的两个进程提供了一种简单的远程过程调用机制。对于调用者来说，调用 RPC 函数和调用本地函数没有区别。RPC 协议可以在多种不同的传输协议上实现，早期的 NFS 实现基于 UDP/IP，在过去十年中，许多环境已经转向使用 TCP/IP（通常是为了避免通过路由器时的数据包丢失）。

NFS 在 VFS/vnode 架构中的整体架构如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[用户]:::process --> B[系统调用]:::process
    B --> C[VFS/vnode 接口]:::process
    C --> D[NFS 文件系统]:::process
    D --> E[RPC/XDR]:::process
    E --> F[UDP/IP]:::process
    F --> G(网络):::process
    H(网络):::process --> I[UDP/IP]:::process
    I --> J[RPC/XDR]:::process
    J --> K[NFS 文件系统]:::process
    K --> L[VFS/vnode 接口]:::process
    L --> M[本地文件系统]:::process
    N[用户]:::process --> O[系统调用]:::process
    O --> P[VFS/vnode 接口]:::process
    P --> Q[其他文件系统]:::process

从图中可以看出，对于内核的其他部分来说，NFS 就像其他任何文件系统类型一样。

4.4 导出、挂载和访问 NFS 文件系统

前面提到的 NFS 协议过程中缺少获取第一个文件句柄（即根目录的句柄）的方法，后续的查找操作和其他过程都基于此句柄进行。这通过一个单独的挂载协议来实现，该协议返回根目录的文件句柄。

将挂载协议与 NFS 协议分开有两个原因：一是服务器上的访问检查通常在用户空间实现，这样可以使用多种不同的安全机制；二是设计者认为将路径名转换为文件句柄的过程如果与 NFS 协议绑定过紧，会使 NFS 的实现过于依赖 UNIX。

初始的挂载协议包含六个不同的过程：
- MOUNTPROC_NULL：此过程不执行特定功能，用于 ping 服务器以测量往返时间，可用于确定 NFS 过程调用服务器的超时时间。
- MOUNTPROC_MNT：该过程接受一个路径名并返回对应的文件句柄。
- MOUNTPROC_DUMP：返回客户端列表以及它们已挂载的导出文件系统，供 UNIX 命令 showmount 和 dfmounts 使用。
- MOUNTPROC_UMNT：用于通知服务器客户端上的 NFS 文件系统已卸载。
- MOUNTPROC_UMNTALL：客户端在重启（或崩溃）后发送此过程，以防止服务器在客户端崩溃前未发送相应卸载消息时保留过时的挂载条目。
- MOUNTPROC_EXPORT：返回导出文件系统的列表。

挂载协议多年来一直保持不变，后来只增加了一个过程 MOUNTPROC_PATHCONF，用于从服务器检索额外信息，使 NFS 文件系统能够符合 POSIX pathconf() 系统调用。

4.5 使用 NFS

尽管不同平台上的 NFS 实现方式在文件系统导出方面有所不同，但在运行适当的客户端和服务器软件时，使用 NFS 非常简单。NFS 守护进程/线程通常在系统启动并进入多用户模式时启动。

例如，在 Solaris 系统中，假设服务器 srv 希望将挂载在 /fs1 上的文件系统导出给任何客户端，最简单的方法是在 /etc/dfs/dfstab 中添加一个条目来指定要共享和/或导出的文件系统。如果该文件系统不需要任何选项，以下命令就足够了：

share -F nfs /fs1

在客户端，可以使用以下命令挂载该文件系统：

# mount -F nfs srv:/fs1 /mnt
# mount | grep mnt
/mnt on srv:/fs1 remote/read/write/setuid/dev=2fc004 
on Wed Jun 19 07:25:18 2002

挂载后，该文件系统就可以像任何本地文件系统一样使用。

4.6 第 3 版 NFS 协议

尽管 NFS 第 2 版协议取得了巨大成功，但也存在一些问题，因此引入了第 3 版协议。第 2 版协议的两个主要问题如下：
- 只能访问最大 4GB 的文件，这一限制在大型机器上运行 NFS 时很早就暴露出来，并且在大多数环境中迅速成为问题。
- 由于所有写入都必须同步进行，写入密集型应用程序会遇到性能瓶颈，并且有许多绕过此问题的方法，其中一些方法违反了 NFS 协议，采用了异步写入。

设计 NFS 第 3 版协议的目标是解决上述两个问题，整理现有的第 2 版协议，并添加一些次要功能，同时限制第 3 版协议的范围，以免过于臃肿而无法及时实现。第 3 版协议在以下十二个主要方面进行了增强：
- 协议中的所有参数（如文件大小和文件偏移量）从 32 位扩展到 64 位，解决了 4GB 文件限制。
- 更改写入模型，引入写入/提交阶段，允许异步写入。
- 引入新的 ACCESS 过程，以解决在映射超级用户 ID 时的权限检查问题，该过程在访问控制列表（ACL）存在的情况下工作。
- 原协议中，一些过程需要后续调用才能检索文件属性，新协议中所有过程都会返回文件属性。
- 原协议中，每次过程调用的写入限制为 8KB，新协议放宽了这一限制。
- 引入 READDIRPLUS 过程，该过程返回文件句柄和属性，减少了扫描目录时的查找调用。
- 第 2 版协议中的文件句柄大小是固定的 32 字节不透明数据类型，第 3 版改为可变大小，最大为 64 字节。
- 修改 CREATE 过程，允许独占式文件创建，解决了第 2 版协议中先 LOOKUP 再 CREATE 可能导致其他客户端创建文件的问题。
- 第 2 版协议将文件名和路径名的大小分别限制为 255 和 1024 个字符，第 3 版改为可变长度字符串，可由客户端和服务器协商确定。
- 第 3 版协议收紧了服务器可以返回的错误，所有错误值都进行了迭代，不允许列表之外的错误。
- 对于文件属性集，删除了 blocksize 字段，blocks 字段改为 used，记录文件使用的总字节数。
- 引入新的错误类型 NFS3ERR_JUKEBOX，在分层存储管理（HSM）环境中，当请求读取已迁移到磁带的文件时，该错误会通知客户端操作正在进行，应重试调用，并允许客户端在用户控制台显示消息。

在 UNIX 中，写入默认是异步的，除非在 open() 函数中传递 O_SYNC 或 O_DSYNC 标志。强制异步写入同步会不可避免地影响性能。使用 NFS 第 3 版时，客户端可以发送多个异步 WRITE 请求，然后在稍后通过发出 COMMIT 请求将数据提交到服务器磁盘。服务器收到 COMMIT 请求后，必须在所有数据刷新到磁盘后才能返回。在某些方面，COMMIT 请求类似于调用 fsync()，但不同的是，COMMIT 请求不一定涵盖整个文件的数据。它允许客户端在关闭文件时刷新所有数据，或者将大型同步写入请求分解为多个小写入，所有这些写入都是异步执行，但随后会发出 COMMIT 请求。这是一个重要的改进，因为它允许服务器上的文件系统或磁盘驱动程序将多个写入合并为一个大写入，从而提高效率。使用异步写入不会影响 NFS 的崩溃/恢复特性，因为客户端在发出 COMMIT 请求之前必须保留要写入文件的所有数据副本。

READDIRPLUS 过程虽然非常有效，但也存在一些问题。该过程的引入是为了在调用 READDIR 过程后尽量减少网络上的 LOOKUP 请求，例如在对目录执行 ls -F 请求时。由于 READDIRPLUS 的实现成本明显高于 READDIR，因此应谨慎使用。通常，只有在首次访问目录时才应执行该操作，以填充 DNLC（或其他名称缓存，具体取决于底层操作系统）。只有在目录修改导致缓存无效时，才应再次执行该操作。

由于 NFS 第 3 版的许多目标是提高性能，因此其成功与否取决于实际性能表现。相关测试表明，第 3 版协议实际上达到了其目标。

4.7 NFS 锁管理器协议

NFS 团队在设计 NFS 协议时决定省略文件锁定功能，主要原因是支持记录锁定需要在服务器上维护状态，这将大大增加 NFS 实现的复杂性。

然而，文件锁定是一个不容忽视的问题，因此在 SunOS 中实现了网络锁管理器（NLM）。NLM 协议经历了多个版本，NLM 版本 3 是与 NFS 版本 2 最广泛使用的版本。不幸的是，由于实现锁定支持的复杂性，NLM 协议并未得到广泛实现。随着 NFS 版本 3 的引入，NLM（版本 4）的定义被包含在 NFS 规范中，但仍然是一个单独的协议。NLM 协议还依赖于网络状态监视器协议，该协议用于通知客户端和服务器崩溃情况，以便恢复锁状态。

服务器崩溃和客户端崩溃时的处理机制如下：
- 服务器崩溃：当服务器将锁授予客户端时，会维护一个客户端列表和它们拥有的锁。如果服务器崩溃，这些信息将丢失。服务器重启后，状态监视器会运行并向所有已知客户端发送消息，每个客户端上的锁管理器会收到通知，并有权重新获取其在服务器上文件的所有锁。客户端有固定的时间（宽限期）来响应。但这并非理想情况，因为客户端的通知可能会延迟，因为状态监视器通常按顺序通知所有客户端。可以通过多线程状态监视器来减少这种延迟。
- 客户端崩溃：如果客户端崩溃，其在服务器上持有的所有锁必须清理。客户端恢复后，会向服务器发送消息以清理其锁。通过使用客户端状态编号（在重启时递增），服务器可以检测到客户端已重启，并删除客户端在崩溃/重启前持有的任何锁。

由于 NLM 未得到广泛采用，NFS 版本 4 协议已扩展为包括文件锁定功能，这将在下一部分详细介绍。

深入解析文件系统备份与分布式文件系统

5. 第 4 版 NFS 协议和 NFS 的未来

NFS 最初是为局域网设计的，在万维网广泛应用之前就已存在。随着时间推移，在广域网中使用 NFS 的需求日益增加，这引发了对安全性的担忧，并凸显了 NFS 解决跨平台问题的必要性。尽管最初的 NFS 实现目标之一是支持非 UNIX 平台，但该协议仍严重偏向 UNIX 环境。

第 4 版协议的目标是解决上述问题，并提供第 3 版协议中省略的额外功能（第 3 版的更改被控制在最小范围内，以确保能够及时设计和实现）。虽然第 4 版协议涉及一些重大更改，但其目标是允许进行小的增量更改，而无需对协议进行全面彻底的修改。第 2 版到第 3 版协议的间隔约为 8 年，第 3 版到第 4 版协议的间隔也大致相同。对第 4 版协议进行小的修订可以在更短的时间内（例如 1 - 2 年）为协议添加新功能。

第 4 版协议的主要变化如下：
- 复合过程 ：许多与文件相关的 NFS 操作需要大量的过程调用。在局域网中，这不是一个大问题，但在广域网中，对性能的影响更为明显。通过将多个过程调用组合成一个复合过程，可以大大减少网络通信量，从而显著提高性能。
- 国际化 ：在以前的协议版本中，文件名被视为不透明的字节流，通常限于 7 位 US ASCII 表示，但常用 8 位 ISO - Latin - 1 编码。由于 XDR 中无法指定编码类型，这限制了 NFS 在混合字符集环境中的使用。为了更好地支持国际化，文件和目录名将使用 UTF - 8 编码。
- 易失性文件句柄 ：NFS 第 2 版和第 3 版协议提供了一种具有固定语义的单一文件句柄类型。该文件句柄的值在其引用的文件系统的生命周期内是固定的。例如，UNIX 上的文件句柄包含索引节点号和生成计数等信息。由于索引节点可以被释放和重新分配，当索引节点被重新使用时，其生成计数会增加，以确保客户端的文件句柄不会错误地指向新文件。然而，一些实现无法正确实现传统的文件句柄，这阻碍了 NFS 在某些平台上的采用。

NFS 第 4 版协议将文件句柄分为持久文件句柄（即传统文件句柄）和易失性文件句柄。对于易失性文件句柄，服务器可能并不总是能够确定其是否仍然有效。如果检测到文件句柄无效，服务器将返回 NFS4ERR_STALE 错误消息；如果无法确定文件句柄是否有效，服务器可以返回 NFS4ERR_FHEXPIRED 错误消息。客户端能够检测服务器是否可以处理持久和易失性文件句柄，并相应地采取行动。
- 属性类 ：早期版本协议中通过网络传递的属性集非常以 UNIX 为中心，服务器返回的信息足以响应客户端的 stat() 调用。在某些环境中，这些属性毫无意义，在某些情况下，服务器无法提供有效值。

在 NFS 第 4 版中，文件属性集分为三个不同的类，即强制性属性、推荐性属性和命名属性：
- 强制性属性 ：包含文件类型和大小、文件句柄过期时间信息、是否支持硬链接和符号链接以及文件是否具有命名数据流/属性等信息。
- 推荐性属性 ：包含文件系统支持的访问控制列表（ACL）类型、ACL 本身、所有者和组信息、访问时间戳和配额属性等信息。还包含文件系统的信息，如可用空间、文件总数、可用文件数以及文件系统限制（如最大文件名长度和最大链接数）。
- 命名属性 ：也称为命名数据流，允许单个文件具有多个不透明字节流，这与传统的 UNIX 模型不同，传统模型每个文件只支持一个字节流。要通过 NFS 第 4 版访问命名数据流，可以使用 OPENATTR 过程检索虚拟属性目录，然后使用 READDIR 和 LOOKUP 过程查看和访问命名属性。
- 更好的命名空间处理 ：NFS 第 2 版和第 3 版服务器导出其整体命名空间的一组独立部分，不允许 NFS 客户端跨服务器上的挂载点，因为 NFS 要求所有查找操作都在单个文件系统内进行。在 NFS v4 中，服务器提供一个根文件句柄，客户端可以通过该句柄获取任何可访问导出的文件句柄。

NFS v4 服务器可以通过将导出的命名空间子树与伪文件系统桥接，并允许客户端跨服务器挂载点，从而实现可浏览性。服务器构建的树是所有不同导出的逻辑视图。
- 文件锁定 ：如前所述，锁定不是 NFS 第 2 版或第 3 版协议的一部分，这两个版本依赖于网络锁管理器（NLM）协议。然而，NLM 协议并未得到广泛采用。

NFS 第 4 版同时提供 UNIX 文件级锁定功能和基于 Windows 的共享锁定功能，支持记录和字节范围锁定功能。
- 客户端缓存 ：大多数 NFS 客户端尽可能缓存文件数据和属性。在向广域网发展的过程中，缓存未命中的成本可能很高。第 2 版和第 3 版协议的问题在于，NFS 没有提供一种机制来支持多个客户端之间的缓存一致性，这有时会导致读取到无效的文件数据。

NFS 第 4 版虽然不提供客户端之间的缓存一致性，但定义了一组有限的缓存保证，以允许在不与客户端缓存产生破坏性干扰的情况下使用锁和共享保留。NFS v4 还提供了一种委托机制，允许客户端做出传统上由服务器做出的决策。

委托机制在性能方面是一个重要特性，因为它减少了访问文件时客户端和服务器之间通常会进行的过程调用数量。当另一个客户端尝试访问已授予委托的文件时，服务器会向持有委托的客户端调用 RPC。客户端负责在响应召回通知之前刷新任何已更改的文件信息（包括数据）。只有在第一个客户端响应撤销请求后，第二个客户端才被允许访问该文件。NFS 第 4 版规范详细说明了可以授予的不同类型的委托，以及因此可以在客户端执行的缓存类型。
- 内置安全性 ：NFS 一直依赖以 UNIX 为中心的用户 ID 机制来提供安全性。由于 NFS 主要在专用网络中使用，这通常不是问题。然而，第 4 版协议的目标之一是将 NFS 的使用扩展到广域网，因此这种安全级别是不够的。基本的 NFS 安全机制正在通过使用 RPCSEG_GSS 框架进行扩展。RPCSEG_GSS 机制在 RPC 层实现，能够提供私有密钥方案（如 Kerberos 版本 5）和公共密钥方案。

NFS 第 4 版协议是对第 3 版协议的重大改进。它提供了广泛的功能，旨在随着其在广域网中的更广泛采用而继续取得成功，并为构建异构操作系统的分布式文件系统提供更好的支持。在第 4 版之前，对 NFS 进行了大量投资。由于 NFS 第 4 版试图解决早期版本的许多限制，包括更加关注非 UNIX 操作系统，NFS 可能会越来越受欢迎。

6. NFS 自动挂载器

一些分布式文件系统的一个特性是能够在多个不同客户端上提供统一的命名空间。例如，要在多个不同客户端上看到 /home/spate，需要从文件系统所在的服务器导出该文件系统，并在所有需要的客户端上进行 NFS 挂载。如果挂载点是永久性的，则必须在 vfstab/fstab 表中放置相应的条目。显然，当处理数百个文件系统以及大量的客户端和服务器时，这种模型的扩展性不佳。

自动挂载器的引入解决了这个问题。它有助于创建统一的命名空间，同时将挂载的文件系统数量限制为实际使用的文件系统。自动挂载器的原理很简单。当用户尝试访问跨越自动挂载器边界内的挂载点的文件时，NFS 文件系统会先被挂载，然后再允许访问。其工作流程如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[用户尝试访问文件]:::process --> B[访问被检测到]:::process
    B --> C[自动挂载器挂载 NFS 文件系统]:::process
    C --> D[访问继续]:::process

最初的自动挂载器实现为用户空间守护进程，它们通常挂载到需要自动挂载服务的目录上，并伪装成 NFS 服务器。当尝试访问这些文件系统中的文件时，内核会向服务器（即自动挂载器）发送 NFS LOOKUP 调用。然后，自动挂载器将实际的文件系统 NFS 挂载到其自身挂载空间内的某个目录中，实际的文件系统通过符号链接进行引用。例如，要挂载到 fs2 的文件系统可能会被挂载到 /auto/f2，而 /mnt/fs1 将是指向该目录的符号链接。

在许多环境中，通常会同时看到标准 NFS 挂载的文件系统和自动挂载的文件系统。自动挂载器适用于不经常访问的文件系统，如手册页、源代码仓库等。用户目录和 bin 目录通常通过标准 NFS 方式进行挂载。

自动挂载器的另一个常见用途是与网络信息服务（NIS）结合使用，在用户主目录分布在整个网络的环境中。通过这种方式，NIS 从其中一台服务器集中管理所有 NFS 挂载。虽然每个用户的主目录实际上只位于一台服务器上，但该服务器被配置为将主目录导出到网络上的所有主机。网络上的每台主机都作为 NFS 客户端运行自动挂载器，因此可以挂载用户的主目录。这允许用户登录到任何主机并访问其主目录。在这种环境中，文件访问可以透明地得到增强，同时使用自动挂载器可以避免大量活跃但未使用的 NFS 挂载文件系统带来的开销。