坑边闲话：在 Linux 集群中，NFS 文件共享协议非常重要。NFS 集访问控制和高性能 RPC 于一身，具有非常强大的实用性。本文详细介绍 NFS 的配置。

1. NFS 的诞生与发展简史·

1.1 NFS 简史·

NFS 由 Sun Microsystems 于 1984 年创建，它是一种允许不同计算机通过网络共享和访问文件的分布式文件系统协议。最初 NFS 旨在解决跨异构系统的文件共享问题，允许用户像访问本地文件一样访问远程文件。如今 NFS 是 Unix 和 Linux 领域最常用的共享文件系统，几乎没有之一。

1.2 NFS 与 SMB 的区别·

NFS 与 Samba/SMB/CIFS 最大的区别在于设计目标与应用场景。NFS 起源于类 Unix 系统，强调轻量、高效、无状态，适合 Linux/Unix 服务器之间的文件共享。比如，修改了服务器的导出表之后无需重启 NFS 服务器进程即可生效。而 SMB/CIFS 则源自 Windows 生态，功能更丰富（如权限继承、打印共享、用户认证），但协议更复杂、开销也更大，一般用在企业内部员工管理中。

在纯 Linux 环境中，NFS 通常性能更优，因此 NFS 在数据中心领域用得较多；
而混合或 Windows 办公环境中，SMB 兼容性更好。

1.3 NFS 的不同版本·

NFS 的各版本演进体现了从“简单高效”向“功能完善、安全增强”的方向发展。

NFSv2：发布于 1980 年代末，协议简单、无状态（stateless），适合小文件传输和早期局域网环境，但功能有限，不支持大文件（最大 2GB）。
NFSv3：增强了性能与灵活性，引入了异步写（async write）、64 位文件大小支持、改进错误返回和属性缓存，成为企业和 NAS 的主力版本。
NFSv4.x：融合了状态管理、文件锁和 ACL，使用单 TCP 端口 2049，支持 Kerberos 认证系统、更易穿防火墙，并大幅提升 WAN 环境下的稳定性。v4.1 及 v4.2 还加入并行会话与高性能扩展。目前最常用的高性能版本就是 v4.2.

2. NFS 的基础技术架构·

2.1 NFS 的 Client-Server 模型·

在 NFS 的设计中，Client–Server 模型是其核心思想。

NFS 服务器端负责管理真实的底层文件系统，对外暴露一组导出 exports；
客户端通过网络协议将这些导出路径挂载到本地目录树，就像访问本地磁盘一样透明。

客户端所有的文件操作——无论是 open()、read()、write()，本质上都会被转换为 NFS 协议请求，通过 TCP/UDP 发送给服务器，由服务器完成实际的 I/O 操作后返回结果。这种设计让计算节点与存储节点彻底解耦，为大规模集群和 NAS 系统打下了基础。

2.2 RPC 与端口映射机制·

NFS 这种跨主机的文件访问依赖 ONC RPC（Open Network Computing Remote Procedure Call）。

RPC 的作用是让客户端像调用本地函数一样，透明地调用远程服务器的过程。

NFS 的所有文件操作，如 LOOKUP、READ、WRITE、CREATE 等，都是在 RPC 层上实现的。由于早期 NFS 使用的是动态端口分配，客户端必须首先向 portmapper (rpcbind) 查询各服务端口，然后再进行通信，这也是为什么 NFSv4 之后统一使用 2049 端口的一个重要改进，极大简化了跨防火墙部署的复杂性。

当客户端请求一个文件时，NFS 并不会像本地文件系统那样直接返回路径，而是返回一个文件句柄。文件句柄是一段由服务器生成的二进制结构，其中包含

inode 编号
文件系统标识符

等信息。客户端此后不再依赖路径，而是通过这个句柄直接访问目标对象。这种机制提高了效率，也降低了路径解析带来的开销。不过，一旦底层文件被删除或 inode 变化，就可能出现著名的 stale file handle 错误，让很多运维小白痛苦不已。

同一台服务器可能导出多个文件系统，不同文件系统各自有自己的 inode 编号空间，单纯依靠 inode 并不能唯一标识文件。因此，NFS 文件句柄并不仅仅包含 inode 编号，而是一个由文件系统标识符 fsid + inode number + 世代号 generation number 组合而成的结构。在不同的 NFS 版本中，具体的编码方式有所差异，但核心思想是一致的：

fsid 用来区分是哪个底层文件系统，例如 /data 和 /home 可能位于不同的挂载点。
inode number 表征该文件在所属文件系统中的唯一标识。
generation number 主要是为了防止 inode 复用导致混淆。例如一个文件被删除后，inode 可能分配给另一个新文件，世代号用来检测这种变化。

后面后有一个章节描述这个设计的现实意义。

2.3 NFS 的缓存与一致性语义·

NFS 的缓存机制也颇具特色。为了减轻网络延迟对性能的影响，客户端会对属性、目录项、文件数据等进行本地缓存。

但与本地文件系统不同，NFS 采用的是 close-to-open consistency 一致性语义，即

在文件关闭时将变更同步到服务器；
文件打开时刷新缓存。

这意味着多个客户端对同一文件的修改不会实时可见，但在再次 open 时保证一致性。对于媒体流播放或科学计算等只读场景，这种一致性模型相当高效；但在并发写场景下就要格外小心。

文件锁在分布式系统中至关重要。NFSv2/v3 原生是无状态的，不具备锁语义，因此引入了 NLM, Network Lock Manager、lockd 和 statd 辅助进程来管理文件锁信息。这一机制依赖额外的 RPC 服务，稍显脆弱；NFSv4 则原生内建了锁机制，并支持租约 lease，大幅提升了可靠性与一致性控制。

2.4 NFS 安全机制·

安全方面，早期 NFS 使用 AUTH_SYS，本质上是客户端自己声明 UID/GID，服务端被动接受，这在受信任局域网里简单高效，但缺乏防护。而在大规模或跨域场景下，NFSv4 支持 Kerberos（AUTH_KRB5/krb5i/krb5p），通过加密认证和数据完整性校验，显著增强安全性。

总的来说，NFS 的这一套机制代表了典型的 Unix 哲学：用最小的协议抽象实现分布式资源共享，灵活、高效、易扩展。而正是这一设计，使得它至今仍是 HPC 集群、企业 NAS、自托管存储的核心基石之一。

3. 部署与配置实战·

NFS 的一个重要优势在于部署极其简单，但这也意味着很多人初次接触时容易忽略一些细节，比如

权限
挂载方式
防火墙
多客户端竞争问题

本章我们将完整地搭建一个 NFS 服务端与客户端环境，并深入讲解每个配置背后的含义。

3.1 服务器端环境准备·

3.1.1 安装 NFS 服务端·

在主流 Linux 发行版中，NFS 服务端通常由 nfs-kernel-server 提供。以 Debian/Ubuntu 为例：

1 2	sudo apt update sudo apt install nfs-kernel-server

安装完成后，服务端会自动启动 nfsd、rpcbind 等核心进程，负责响应客户端请求。可以通过以下命令确认服务状态：

1 2	sudo systemctl status nfs-server sudo systemctl status rpcbind

3.1.2 配置 `/etc/exports`·

NFS 的导出规则全部定义在 /etc/exports 文件中，每一行代表一个导出的目录及其访问规则。例如：

1	/data/share 192.168.1.0/24(rw,sync,no_subtree_check)

这表示允许 192.168.1.0/24 网段的客户端对 /data/share 目录进行读写访问。修改配置后执行：

1 2	sudo exportfs -ra # 重新加载配置 sudo exportfs -v # 查看当前生效的导出规则

exportfs -v 会显示详细的权限、挂载方式以及 NFS 版本支持情况。

3.2 客户端挂载·

3.2.1 `mount` 命令·

在客户端安装 NFS 工具：

1	sudo apt install nfs-common

然后使用 mount 进行挂载：

1	sudo mount -t nfs 192.168.1.10:/data/share /mnt/nfs

其中：

192.168.1.10 是 NFS 服务器地址；
/data/share 是服务端导出的目录；
/mnt/nfs 是本地挂载点。

3.2.2 `fstab` 自动挂载·

为了在开机时自动挂载，可以在 /etc/fstab 中添加：

1	192.168.1.10:/data/share /mnt/nfs nfs defaults,_netdev 0 0

_netdev 选项确保网络就绪后再进行挂载。

3.2.3 `systemd.mount` 自动挂载·

在现代系统中，你也可以使用 systemd 配置：

1	/etc/systemd/system/mnt-nfs.mount

内容示例：

[Unit]
Description=NFS Share

[Mount]
What=192.168.1.10:/data/share
Where=/mnt/nfs
Type=nfs
Options=_netdev,defaults

[Install]
WantedBy=multi-user.target

启用：

1 2	sudo systemctl daemon-reload sudo systemctl enable --now mnt-nfs.mount

systemd.mount 相对于传统的 /etc/fstab 有几个很实在的好处：

启动顺序更可控

你可以精确指定依赖关系，比如依赖网络服务就绪 After=network-online.target，或等待某个服务启动后再挂载。
这在 NFS 场景尤其重要，因为如果 NFS 服务器尚未就绪，fstab 会直接挂载失败。

状态可管理

systemctl status mnt-nfs.mount 直接查看挂载点状态，可以启停、重启、自动恢复，比 mount 命令灵活。

事件驱动挂载

systemd.automount 可以做到按需挂载 on-demand，只有访问时才真正发起 mount，这对挂载大量 NFS 目录非常有用。

更适合容器和集群

在集群/自动化部署场景中，写声明式的 unit 文件更容易与 Ansible、SaltStack 等工具集成。

但它也确实有不便之处：

每个挂载点都要写一个 Unit 文件
- 对于只有一两个挂载点的情况没问题，但一旦有几十个 NFS 共享目录，例如媒体库、科研集群、容器节点，写那么多 .mount 文件就变得笨重。
命名规则容易出错：
- systemd 要求 .mount 文件名与挂载点路径一一对应（比如 /mnt/nfs/data -> mnt-nfs-data.mount），稍不注意就报错。
灵活性降低
- 如果只是简单挂载一下，其实一行 fstab 就能搞定，用 systemd 反而有点杀鸡用牛刀。

3.3 `export` 与 m`ount 的权限与参数详解·

ro / rw：只读 / 读写权限。默认是 ro，常用于媒体分发场景；rw 适用于开发或共享工作区。
sync / async: sync 表示写操作必须写入磁盘后才返回客户端，保证一致性但略慢；async 允许缓存写操作，性能更高但在断电或故障时有丢数据风险。生产环境推荐 sync.
no_root_squash：默认情况下，客户端的 root 用户会被映射为服务端的 nobody，防止越权访问；如果使用 no_root_squash，客户端 root 将保留 root 权限，通常仅在受信任环境使用。
no_subtree_check：关闭子树检查，提升性能，减少重命名时 stale file handle 的风险。
insecure：允许客户端使用高于 1024 的非特权端口连接，适用于部分容器化环境。

Mount 时客户端也有一些参数可以配合优化：

1	mount -t nfs -o rsize=1048576,wsize=1048576,noatime 192.168.1.10:/data/share /mnt/nfs

其中 rsize/wsize 控制读写块大小，最大就是 1MiB (1048576)，noatime 可减少元数据写入压力。

3.4 防火墙与端口配置·

NFS 涉及多个服务进程：

nfsd
mountd
rpcbind

默认端口如下：

2049/tcp：NFS 核心端口（v4）
111/tcp 和 111/udp：rpcbind

其他端口：mountd, nlockmgr 可能在 NFSv3 中使用动态端口。

为了方便管理，建议在 /etc/default/nfs-kernel-server 或 /etc/nfs.conf 中固定端口，例如：

# /etc/nfs.conf
[nfsd]
port = 2049

[mountd]
port = 20048

然后在防火墙中开放这些端口，例如使用 UFW：

1
2
3

sudo ufw allow 2049/tcp
sudo ufw allow 111/tcp
sudo ufw allow 20048/tcp

3.5 多客户端环境的注意事项·

在多客户端同时访问同一 NFS 导出的情况下，需要特别注意以下几点：

权限控制：使用精确的 IP 网段控制访问，必要时使用 Kerberos 进行身份认证，避免越权访问。
- 锁机制与一致性：共享文件写入会触发 NFS 锁竞争。确保客户端支持 NLM (NFSv3) 或 NFSv4 内建锁机制。
- 尽量避免多个客户端同时写同一文件，或通过应用层加锁。
文件系统属性
- 底层文件系统应支持合适的 ZFS recordsize / blocksize，以匹配 NFS 的 I/O 行为，提高吞吐，避免写放大。
挂载参数统一
- 不同客户端若使用不同挂载参数，可能导致缓存一致性行为不一致，建议统一配置。
监控与诊断
- 多客户端情况下，问题可能发生在任意一端。
- 合理使用 nfsstat, rpcinfo, showmount 监控状态。

3.6 小结·

这一章节完成了 NFS 的基础部署全流程。无论是小型 NAS、媒体分发，还是科研集群的共享目录，这套配置都是最常见的起点。接下来，你可以进一步探索性能调优、高可用与安全机制，让 NFS 在生产环境中发挥最大价值。

4. 性能优化与调优·

NFS 的性能瓶颈通常不在协议本身，而在其背后的网络延迟、底层存储、I/O 模式匹配等多个环节。调优 NFS 的过程，本质上是调优网络 + 文件系统 + I/O 行为的一致性。调优的本质就是让 NFS 流水线的各个环节尽可能匹配、高效。

4.1 NFS 性能瓶颈的来源·

4.1.1 网络延迟·

NFS 所有文件操作都依赖 RPC，因此 RTT 往返延迟直接决定了性能上限。即使是小文件元数据访问，延迟也会显著影响整体吞吐量。高延迟网络尤其会拖慢 Jellyfin 媒体库扫描或科研集群的海量小文件访问。

4.1.2 服务器 I/O 吞吐能力·

NFS 的性能上限永远受制于服务端文件系统和存储硬件。

如果底层是机械盘，随机 I/O 延迟会成为主要瓶颈；
如果是 SSD/NVMe，那么瓶颈可能转移到网络层。

4.1.3 锁争用与一致性开销·

NFSv4 引入了状态和锁机制，在并发写入场景下容易出现锁竞争。例如多个计算节点对同一个共享目录频繁写入时，会造成显著的延迟抖动。

4.2 挂载参数调优·

客户端的挂载参数往往是最直接的调优手段，尤其在高吞吐或低延迟场景中。

参数	作用	建议
`rsize` / `wsize`	读写块大小（最大传输单元）	通常设为 1 MiB `1048576` 能提高吞吐；需服务端支持。
`noatime`	禁止访问时间更新	减少元数据写入，适合大多数只读场景。
`actimeo`	属性缓存时间	提高缓存命中率，降低元数据交互，但可能牺牲一致性。
`tcp`	使用 TCP 代替 UDP	在现代网络中更稳定，避免丢包重传导致的性能问题。
`vers=4`	指定协议版本	NFSv4 更适合穿防火墙和高延迟场景。

示例挂载命令：

1	sudo mount -t nfs -o vers=4,rsize=1048576,wsize=1048576,noatime,tcp 192.168.1.10:/data/share /mnt/nfs

对于 Jellyfin 这样的流媒体读取场景，noatime 加大块传输往往能带来非常明显的性能提升；
对于科研集群，合理设置 actimeo 能减少元数据 RPC 压力。

4.3 服务端参数调优·

服务端的配置决定了 NFS 处理请求的能力上限，主要关注以下几个方面：

4.3.1 nfsd 线程数·

/proc/fs/nfsd/threads 控制 NFS 守护进程线程数量。线程数过少会导致高并发下排队；过多则浪费资源。经验值：

轻负载：8~16 线程
中高并发（媒体/科研）：32~128 线程，TrueNAS 默认 32.

调整方式：

1	echo 64 \| sudo tee /proc/fs/nfsd/threads

4.3.2 TCP backlog 和 socket 缓冲区·

高并发场景可调大 net.core.somaxconn、tcp_rmem / tcp_wmem 以提升连接处理能力。

4.3.3 exportfs 参数·

no_subtree_check、async 等参数会直接影响元数据访问性能，但需权衡一致性和可靠性。

4.4 ZFS/EXT4 等底层文件系统的交互优化·

NFS 只是协议层，其 I/O 最终落在底层文件系统上。

EXT4：对随机小文件的访问比较友好，性能稳定，但调优空间有限。
ZFS：需要调整相当多的参数。
- 大文件流式访问，如 Jellyfin 视频、剪辑，可以通过调整 recordsize、启用 primarycache=metadata、合理设置 ZFS sync 策略来显著提升性能。注意，这里的 sync 和 NFS 挂载的 sync 是两个不同的概念，前者影响 ZFS 落盘策略，后者影响 NFS 客户端同步策略。
- 对影音媒体库推荐 recordsize=1MiB，匹配 NFS rsize/wsize.
- 对数据库/小文件推荐 recordsize=16K 甚至 recordsize=8K, 比如
  - MySQL 默认页大小是 16KB,
  - PostgreSQL 默认页大小是 8KB,
  - sqlite 默认页大小是 4KB

需要注意的是，NFS 的异步写入 async 与 ZFS 的 sync=always 是互相冲突的，这并不是说它们不能组合使用，而是无法达成 ZFS sync 所承诺的安全性。

4.5 典型性能测试方法·

调优前后的性能差异一定要通过可量化的工具来验证。常用工具如下：

4.5.1 fio·

fio 可以模拟大文件或小文件的 I/O 模式，最接近真实应用。

1	sudo fio --name=read --rw=read --size=10G --directory=/mnt/nfs --bs=1M --numjobs=4

4.5.2 dd·

与 fio 相比， dd 简单粗暴，但适合快速估算顺序吞吐：

1	dd if=/dev/zero of=/mnt/nfs/testfile bs=1M count=10000 oflag=direct

其他命令·

iostat: 观察服务端磁盘 I/O 饱和度。
nfsstat: 查看 NFS RPC 请求统计，判断是否出现 retrans 或延迟。
iperf3: 测试网络带宽，可以快速定位瓶颈是在 NFS 还是网络层。

4.6 总结：·

NFS 的性能优化是一个系统性工程，不是单靠一个参数就能解决的。网络延迟、I/O 大小、协议版本、文件系统 recordsize 都需要配合；

rsize/wsize 与 ZFS 的 recordsize 匹配非常关键；
高并发场景应重视锁机制和 nfsd 线程数。

通过这些手段，NFS 在媒体流、科研、甚至部分 HPC 场景中，都能跑出接近本地磁盘的性能。

5. 高可用与进阶场景·

NFS 之所以在现代存储和计算场景中仍然占据重要地位，并不仅仅因为它简单，而是因为它可以与现代系统栈深度结合，构建出可靠、高性能、可扩展的分布式存储基础设施。

本章将讨论一些更高阶的 NFS 使用方式，包括 systemd 依赖编排、RDMA 协议栈、ZFS 协同调优以及容器化场景下的动态存储集成。

5.1 NFS 与 systemd 的配合·

传统上，NFS 的挂载往往依赖 /etc/fstab 静态配置，但在分布式系统中，这种方式太过脆弱。一旦 NFS 服务器稍晚启动或网络存在抖动，客户端的挂载可能在启动早期就失败，导致整个服务链断裂。

systemd 提供了更为精细的控制手段，包括 .mount、.automount 与 .target 单元，能将 NFS 挂载点视作一等公民资源进行编排。

典型用法是将关键 NFS 挂载点定义为 *.mount，并使用：

1 2	After=network-online.target Requires=network-online.target

以确保网络完全就绪后再进行挂载。

使用 x-systemd.automount 结合 _netdev，可以在访问时再触发挂载，大幅减少启动时的时序依赖。

对于多挂载点场景，可以自定义 nfs-mounts.target，实现批量启动、批量恢复以及有序依赖（例如某个服务必须在挂载完成后启动）。

这种方式在大型集群和自托管 NAS 环境中尤其稳定，可避免 fstab 提前挂载失败导致关键服务起不来的经典坑。

5.2 NFS over RDMA·

传统 NFS 使用 TCP 传输，这在 2.5G 或万兆网络上已能满足大多数场景。但对于低延迟、高吞吐的 HPC、AI 训练集群或 NVMe-over-Fabric 存储后端来说，TCP stack overhead 成为瓶颈。

NFSoRDMA 通过 RDMA协议栈将 NFS 的数据传输部分直接映射到 RDMA 通道上，实现绕过内核协议栈的零拷贝传输。

优势：

低延迟：数据在 NIC 与内存之间直接搬运，绕过 CPU 上下文切换。
高吞吐：RDMA 能持续饱和 100 GbE 链路，而无需额外 CPU 负载。
协议兼容：NFS over RDMA 并未改变 NFS 语义，客户端和服务端仍使用相同的 RPC 层逻辑。

典型部署方式：

# 查看 RDMA 支持
cat /proc/fs/nfsfs/servers

# 挂载时指定传输协议
sudo mount -t nfs -o rdma,port=20049 server:/data /mnt/nfs

5.3 NFS 与容器结合·

在容器环境中使用 NFS 时，最关键的挑战是挂载的生命周期与容器编排系统保持一致。

5.3.1 Docker 场景·

Docker 支持直接在 docker run 或 docker-compose.yml 中挂载 NFS 卷：

volumes:
  data:
    driver_opts:
      type: "nfs"
      o: "addr=192.168.1.10,rw,nfsvers=4,tcp"
      device: ":/data/share"

这种方式简单直接，但对挂载失败的恢复能力较弱，一旦 NFS 中断，容器可能卡死。解决方法一般是配合 systemd.automount 确保在容器启动前自动重连。此外也可以通过 restart: always 配合 depends_on 机制保证容器在挂载恢复后自动重启。

5.3.2 Kubernetes 场景·

Kubernetes 中更推荐使用 PersistentVolume (PV) + PersistentVolumeClaim (PVC)：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 1Ti
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.10
    path: /data/share
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Ti

ReadWriteMany 是 NFS 最适合的场景，可以让多个 Pod 共享同一数据目录。但这也带来两个关键问题：

并发写入与锁：K8s 本身不会替你处理 NFS 锁冲突，需要应用层自我约束。
性能瓶颈：大量 Pod 同时访问时，NFS 服务端必须有足够 nfsd 线程与 IOPS。

对于大规模集群，NFSoRDMA + ZFS + PV 是一套非常高效的组合方案：RDMA 提供传输效率，ZFS 提供底层一致性与快照，Kubernetes 提供动态扩展与编排。

6. NFS 常见踩坑·

6.1 NFS export 的本质是导出一个挂载点·

当你在 /etc/exports 里写：

1	/data/share *(rw,sync,no_subtree_check)

实际上你并不是在导出路径这个抽象概念，而是在导出 /data/share 所在的那个底层文件系统。这在 Linux 内核中是通过 vfs 识别挂载点并绑定 fsid 实现的。如果 /data/share 下的某个子目录其实是另一个挂载点，比如：

1
2
3

/data/share
├── dir1   同一文件系统
└── dir2   另一个文件系统，比如挂载了 /dev/sdb1

那么 dir2 其实已经不属于 /data/share 的文件系统，而是另一个文件系统的根。此时客户端挂载 /data/share 之后不能访问 /data/share/dir2.

这是为什么呢？原因在于 NFS 文件句柄的唯一性依赖单一 fsid, NFS 的文件句柄结构大致为：

1	[ fsid \| inode \| generation ]

客户端通过这个句柄访问文件，并不通过路径解析。也就是说，fsid 决定了它属于哪个文件系统。

如果一个 export 跨越了两个不同的文件系统，那么：

1 2	/data/sharedir1/fileA fsid=0x1234 /data/sharedir2/fileB fsid=0x5678

但客户端 mount 的时候只会得到一个 export 对应的单一 fsid, 一旦它通过这个 export 访问 dir2, NFS 服务端就发现：

“哎？这个路径属于另一个文件系统了，我没法在原来的 export 里生成合法的文件句柄。”

结果就是 v3/v4 客户端访问 dir2 时直接返回 Stale file handle；或者服务端根本拒绝导出这种混合路径。

6.2 一致性语义无法跨文件系统维护·

NFS 通过 close-to-open consistency 来保证客户端与服务端的缓存同步。而这种一致性依赖于：

唯一的文件系统标识（fsid）
inode 改变触发的属性变化

跨文件系统后，不同的 inode 空间、不同的缓存失效机制、不同的 fsid，根本无法保证一致性。这也是 NFS 协议规范中明确要求 export 对应单一文件系统的原因之一。

6.3 如果必须导出多个文件系统·

如果你确实希望用户看到“一个目录树”下的多个文件系统，常见的正确做法是：

分别对每个文件系统单独 export，例如：

1 2	/data/share (rw,sync) /data/share/dir2 (rw,sync)

客户端 mount 时可以通过多个挂载点实现拼接或在服务端用 bind mount 把不同的文件系统挂到 export 根目录下的不同路径，并分别 export。现在的 NFSv4 基本可以自动处理嵌套挂载，只需挂载 /data/share 即可一并挂载 /data/share/dir2。

总结·

本文除了没有讲述 NFS 高可用部署，基本上把 NFS 所有的知识点都涵盖了。希望对读者有所帮助。