NFS 为什么表现得不像本地磁盘

一句话总结

NFS看起来像文件系统，但是网络上的RPC调用。所以会产生本地磁盘上没有的失败模式（停止、部分失败、缓存不一致）。

为什么需要这个？

无论是家庭实验室还是公司，都会有多个服务器需要查看相同数据的瞬间。在Kubernetes中，如果多个节点的PAD要使用相同的PVC，就需要ReadWriteMany，最简单的实现是NFS。但是，加上NFS后就会发生奇怪的事情。ls停止30秒，过程D不会死于状态，在某些节点可以看到文件，但在其他节点则看不到。

怎么行动

服务器方面—exports

# /etc/exports
/export/share  10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
/export/ro     10.0.0.0/24(ro,sync,no_subtree_check)

选项	含义
rw/ro	允许写入/仅限阅读
sync	将写入反映在磁盘上后进行响应。虽然慢但安全
async	只在内存中使用，立即响应。服务器死掉的话会丢失数据。
root_squash	将客户端的root映射为nobody（默认值）
no_root_squash	原封不动地承认root。实际上是把服务器给别人
no_subtree_check	省略子树检查。目前推荐基本

root_squash因为无法理解而产生的混乱很多。 在客户端用root创建了文件，但所有者nobody看起来是这样。这不是错误，而是安全功能。因为NFS直接信任UID，所以如果没有squash，在客户端sudo一次可以触动服务器上的任何文件。

而且UID/GID不是通过名称而是通过数字传递的。服务器的appuser是1001，但是客户端的1001是webuser拉面的文件所有权看起来很奇怪。所以使用NFS的环境是将UID从中央统一（LDAP），NFSv4的idmapd设定。

客户端方面——安装选项

nfs01:/export/share  /mnt/share  nfs4  _netdev,rw,soft,timeo=600,retrans=2,noatime  0  0

最重要的选择是**hard呀soft呀**。

选项	服务器不响应时
hard（基本）	永远重新尝试。 进程停止为D状态，而且无法kill
soft	timeo×retrans返回后I/O错误
intr	（旧版本）可以通过即使使用 hard，也可通过信号中断。在最新内核中吸收到基本行为中

hard在数据一致性方面是安全的——写入被处理为失败，不会导致应用程序进入错误状态。相反，如果服务器崩溃，客户端会全部停止。soft是相反的。如果没有回应，系统会返回EIO，所以系统是活着的，但如果应用程序不能正确处理该错误，数据就会崩溃。

实际判断一般是这样的。数据库或写入重要的工作量hard，以读取为主或不需要的快取性数据是soft.

快照和一致性

NFS客户端为了性能会缓存属性(attribute)。默认acregmin/acregmax是3~60秒。所以**服务器更改的文件可能无法立即在客户端上显示。**多个节点同时使用同一文件的设计在NFS中很危险。noac关闭缓存的话，一致性会变好，但性能会大大下降。

文件锁定(flock，fcntl)在NFSv4中支持，但在服务器重启或网络中断时，锁定恢复并不完美。最好避免在NFS上依赖锁定的设计。

在现场相遇的样子

**df停止了。**有一个NFS服务器死了hard如果安装好了的话df甚至不回应。这时df -l（仅限本地）李娜timeout 5 df绕行。监控脚本df在使用时，在这种情况下一起停下的事故也很常见。

**引导停止。**在fstab上_netdev如果遗漏了，网络在准备好之前会尝试进行安装。hard如果重叠的话，启动实际上会进入无限等待状态。

**在Kubernetes中，Padd不会从Terminating中出来。**如果NFS卷没有响应，kubelet无法解载，Padd将永远无法终止。这时，请恢复NFS服务器或强制在节点上解载（umount -f -l)应该做。

接下来要做的事情

这个模块只处理概念。但是，现在应该能够说明前面fstab实训中编写的NFS项目为什么是这样的选项组合。