重新导出 NFS 文件系统

概述

可以将 NFS 文件系统通过 NFS 重新导出。然而，此功能有一些限制。在尝试使用它之前，我们建议您仔细研究，以确定它是否适用于您的目的。

下面讨论当前已知的限制。

必须使用“fsid=”，crossmnt 被破坏

我们要求对任何 NFS 文件系统的重新导出使用 “fsid=” 导出选项。您可以使用“uuidgen -r”生成唯一参数。

“crossmnt”导出不会传播 “fsid=”，因此不允许遍历到更深层的 nfs 文件系统；如果您希望导出在导出的文件系统下挂载的 nfs 文件系统，您需要显式导出它们，并为每个文件系统分配其唯一的 “fsid=” 选项。

重启恢复

当重新导出服务器重启时，NFS 协议的正常重启恢复机制不起作用。客户端将丢失重启前持有的任何锁，并且进一步的 IO 操作将导致错误。关闭并重新打开文件应该可以清除错误。

文件句柄限制

如果原始服务器对给定的对象使用 X 字节的文件句柄，则重新导出服务器的重新导出对象的文件句柄将为 X+22 字节，向上舍入到最接近的 4 字节倍数。

结果必须符合 RFC 规定的文件句柄大小限制

NFSv2	32 字节
NFSv3	64 字节
NFSv4	128 字节

因此，例如，如果原始服务器给您的文件句柄小于 10 字节，您将只能通过 NFSv2 重新导出文件系统——但这不太可能。

一般来说，在不询问服务器供应商的情况下，没有办法知道 NFS 服务器给出的最大文件句柄大小。

但是下表给出了一些示例。第一列是 Linux 服务器导出给定文件系统时文件句柄的典型长度，第二列是该 nfs 导出被另一个 Linux 主机重新导出后的长度

	文件句柄长度	重新导出后
ext4	28 字节	52 字节
xfs	32 字节	56 字节
btrfs	40 字节	64 字节

因此，所有文件系统在重新导出后都将适合 NFSv3 或 NFSv4 的文件句柄，但没有一个可以通过 NFSv2 重新导出。

但是，Linux 服务器的文件句柄比这要复杂一些；例如

• （非默认）“subtreecheck”导出选项通常需要在文件句柄中额外增加 4 到 8 个字节。

• 如果您导出文件系统的子目录（而不是导出文件系统根目录），通常也会增加 4 到 8 个字节。

• 如果您通过 NFSv2 导出，knfsd 通常会使用较短的文件系统标识符，从而节省 8 个字节。

• 导出的根目录使用较短的文件句柄。

如您所见，128 字节的 NFSv4 文件句柄足够大，您不太可能在使用 NFSv4 重新导出从 Linux 服务器导出的任何文件系统时遇到问题。通常，如果原始服务器也支持 NFSv3，那么您可能没问题。通过 NFSv3 重新导出可能比较棘手，而通过 NFSv2 重新导出可能永远无法工作。

有关 Linux 文件句柄结构的更多详细信息，最佳参考是源代码和注释；特别参见

• include/linux/exportfs.h:enum fid_type

• include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new

• fs/nfsd/nfsfh.c:set_version_and_fsid_type

• fs/nfs/export.c:nfs_encode_fh

忽略打开 DENY 位

自 NFSv4 以来，NFS 支持从 Windows 获取的 ALLOW 和 DENY 位，例如，允许您以禁止其他读取或写入打开的模式打开文件。 Linux 客户端不使用它们，并且服务器的支持一直不完整：它们仅针对其他 NFS 用户强制执行，而不是针对本地访问导出文件系统的进程。重新导出服务器也不会将它们传递给原始服务器，因此它们不会在不同重新导出服务器的客户端之间强制执行。