我们有一堆 Linux 机器，它们从 NetApp 文件管理器上安装 NFS 共享。有时，我会弄错导出配置的某些部分。允许的主机之一出现拼写错误、IP 地址错误等。不用担心，这通常是在测试系统上完成的，或者在尚未投入生产的全新导出中完成的。
但是，我发现一旦我被拒绝从 Linux 机器上挂载某些东西，故障就会被缓存长达一天。我将纠正阻止挂载的问题，在 NetApp 上重新导出，但仍然无法挂载共享。我很确定这个缓存是在 NetApp 端完成的。它通常会在一天左右后过期，但必须等到明天才能挂载共享，这真的很糟糕。
我已经exportfs -f在 NetApp 以及 上尝试过了dns flush。（我通过 Google 找到了这两个建议）但是，都没有用。
如果有人能通过命令/异教仪式来帮助解决这个缓存问题，我愿意出卖我的灵魂。
答案1
您可以运行“exportfs”而不使用任何选项来验证您的导出是否已正确加载。如果它在 /etc/exports 文件中但未加载，您可能需要“exportfs -a”或“exportfs -r”来重新导出它。从那里，您可以使用“exportfs -c”检查访问缓存或使用“exportfs -f”刷新它。
接下来要在控制器上检查的是您的客户端是否可以访问和解析。假设您在网络上启用了 ping，您可以从 NetApp 控制器“ping -s 主机名”。我会检查主机名和 IP 地址。
除此之外，你可能需要看看你的客户。
答案2
嗯，这实际上不应该发生，假设您正在正确地重新加载导出（即不仅仅是更新 /etc/exports。首先要做的是打开挂载请求的日志记录选项：
options nfs.mountd.trace on
然后检查 /etc/messages 并查看您看到的内容。如果不太明显，请使用输出进行更新，以便我们进一步查看。这里还有太多其他因素在起作用，因此如果没有更多信息，无法进行诊断。
答案3
通常 flush -f 可以工作，但今天我必须同时包含 -n（OnTap 7.3.7P1）- 使用选项 nfs.response.trace 和 nfs.mountd.trace 观察结果
答案4
当导出混乱并且您需要清除并加载新的导出时，请先从 NetApp Exports 进行修复，然后从客户端在 Linux 节点上运行“Service nfslock restart”。
希望这对将来的某人有所帮助。