主页 / unix / 问题 / 479968
Accepted
number9
Asked: 2018-11-06 10:19:02 +0800 CST

陈旧的 NFS 文件句柄为什么 fsid 可以解决它？

  • 772

问题陈述（注意这个问题已经解决了，但是有一个关于为什么解决方案有效的问题）

NFS 服务器是 Ubuntu 16.04.4 LTS。客户端是 Ubuntu 16.04.4 LTS 和 CentOS 6.10 和 7 的混合。

NFS 服务器几个月来一直运行良好，其中一项特殊的导出服务是为多个客户端提供备份服务。NFS 服务器目录如下所示：

/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4

/etc/exports 包含：

/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)

客户端仅在备份期间挂载 nfs 服务器，然后在完成后卸载备份。

这工作正常，但是，确定客户端不应该能够在 /mnt/backups 目录中看到彼此。每个客户端都使用相同的备份 uid/gid。因此，决定通过使用 /etc/exports 文件来分离目录。

为此，NFS 服务器已停止，并且 /etc/exports 已修改，因此它包含：

/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)

回想一下，客户端仅在进行备份时（凌晨 4 点）才挂载 NFS 服务器。在服务器上重新启动 NFS 服务，并使用 exportfs 检查导出，看起来不错。

好的，测试client1：

mount nfserver:/mnt/backups/client1 /mnt/client1

工作正常，但是，对 /mnt/client1 的任何操作都会导致：

cannot open directory /mnt/client1/: Stale file handle

采取的解决措施（无效）：在服务器上重新启动 NFS。重新启动客户端。lsof |grep /mnt 在客户端和服务器上查看是否有任何程序保持打开文件。服务器/客户端的权限检查。同样，将 NFS /etc/exports 切换回旧文件并从客户端挂载 nfs 服务器可以正常工作。切换回“新”方法不起作用。

经过大量的咬牙切齿、手册页和 STFW 只是为了找到像“重新启动 NFS”这样的答案，我回忆起几年前我遇到了这个问题，出于某种原因 fsid 与解决方案有关。阅读手册页后，在 NFS 服务器 /etc/exports 文件中添加了以下内容：

/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)

同样，在此操作之后，唯一执行的操作是在服务器上执行 exportfs -ra。

现在所有客户端都可以挂载 nfs 服务器导出并且它们都可以工作。

为什么这是一个解决方案？

我们应该在每次导出时使用 fsid吗？

阅读像这样的手册页似乎并不能清楚地解释为什么 fsid 是一种解决方案。我有一个想法，可能是陈旧的挂载是客户端（或者可能是服务器端）上的某种 NFS 文件处理程序，但是在重新启动后仍然存在这种情况似乎很奇怪。

filesystems mount

1 个回答

  1. Best Answer

    简而言之，fsid 是客户端和服务器在挂载后识别导出的方式。

    如手册页所述，如果未指定，fsid 将从底层文件系统派生。

    四个导出具有相同的 fsid，因此当 client1 询问其挂载的文件时，服务器可能认为它正在尝试访问 client4 的导出（假设它只保留最新出现的相同 fsid。）

    我想有几种方法可以验证这个假设，例如通过检查 4 个客户端中的一个（并且只有一个）可以工作。此外，仅保留 client1 导出，不保留其他 3 个，然后确认 client1 将起作用。

    另请参阅此答案，了解使用命令从客户端查询 fsid 的方法mountpoint -d，您可以从 4 个客户端使用该命令来确认 4 个安装具有相同的 fsid。

    为什么这是一个解决方案？

    因为使用不同的 fsid，导出对于 NFS 服务器来说看起来是不同的，所以它会正确地将客户端访问匹配到相应的挂载。

    我们应该在每次导出时使用 fsid 吗？

    是的，我认为这是一个很好的做法，它可以确保您保持对底层存储设备的控制和更改，并且导出不会影响您的客户端。

    （就我而言，我记得采用它是因为我的一些磁盘在 SAN 上的 NFS 服务器有时会以不同的顺序扫描磁盘，所以在重新启动后 /dev/sdh 会突然变成 /dev/sdj。使用标签安装可以确保它将被挂载在正确的位置,但是 fsid 会改变并且客户端会丢失.这是在 UUID 普遍存在之前,显然现在支持并且当然是一个更好的解决方案,当磁盘时不会中断以不同的顺序扫描。但是，明确指定 fsid 仍然不是一个坏主意，让您保持完全控制。）

    • 1

相关问题