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

Question

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

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检查导出，看起来不错。

好的，测试客户端1：

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 文件处理程序，但是在重新启动后仍然存在似乎很奇怪。

Answer 1

简而言之，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 普遍存在之前，UUID 现在显然受到支持，当然是一个更好的解决方案，当磁盘以不同的顺序扫描。但是，显式指定 fsid 并不是一个坏主意，可以让您保持完全控制。）