NFS协议解析

有助于了解NFS的文档，摘自http://nfs.sourceforge.net/，用浏览器的翻译插件翻译，可能某些翻译不准确。
A.关于NFS协议
A1。NFS版本2和3之间的主要区别是什么？
答：从系统的角度来看，主要区别在于：

版本2客户端只能访问文件的最低2GB（带符号的32位偏移）。版本3客户端支持更大的文件（最多64位偏移）。最大文件大小取决于NFS服务器的本地文件系统。


NFS版本2将线上NFS读取或写入操作的最大大小限制为8KB（8192字节）。基于UDP的NFS版本3理论上支持高达56KB（UDP数据报的最大大小为64KB，因此具有NFS，RPC和UDP标头的空间，是NFS上UDP的最大线上NFS读取或写入大小约为60KB）。对于基于TCP的NFS版本3，限制取决于实现。大多数实现不支持超过32KB。


NFS版本3引入了弱缓存一致性的概念。弱缓存一致性可帮助NFS版本3客户端更快地检测由其他客户端修改的文件的更改。这是通过在服务器对读或写操作的回复中返回额外的属性信息来完成的。客户端可以使用此信息来确定其数据和属性缓存是否过时。


版本2客户端自己解释文件的模式位以确定用户是否可以访问文件。版本3客户端可以使用新操作（称为ACCESS）来请求服务器决定访问权限。这允许不支持访问控制列表的客户端与服务器正确交互。


NFS版本2要求服务器必须将写入操作中的所有数据保存到磁盘，然后才能回复写入操作已完成的客户端。这可能很昂贵，因为它会将写入请求分成小块（8KB或更少），每个块必须在写入下一个块之前写入磁盘。当磁盘可以同时写入大量数据时，磁盘效果最佳。


NFS版本3引入了“安全异步写入”的概念。版本3客户端可以指定允许服务器在将请求的数据保存到磁盘之前进行回复，从而允许服务器将小型NFS写入操作收集到单个高效的磁盘写入操作中。版本3客户端还可以指定在服务器回复之前必须将数据 写入磁盘，就像版本2写入一样。客户端通过将每个写入操作的参数中的stable_how字段设置为 UNSTABLE以请求安全的异步写入来指定写入类型，并将FILE_SYNC设置为NFS版本2样式写入。

服务器通过在对每个NFS写操作的响应中设置相应的字段来指示是否永久存储所请求的数据。服务器可以使用UNSTABLE应答或FILE_SYNC应答响应不稳定写入请求，具体取决于所请求的数据是否仍驻留在永久存储器上。符合NFS协议的服务器必须仅使用FILE_SYNC回复来响应FILE_SYNC请求。

客户端使用称为COMMIT的版本3中提供的新操作确保使用安全异步写入写入的数据已写入永久存储器。在将请求中指定的所有数据写入永久存储器之前，服务器不会向COMMIT操作发送响应。NFS版本3客户端必须保护使用安全异步写入但尚未提交的缓冲数据。如果服务器在客户端发送适当的COMMIT之前重新启动，则服务器可以以强制客户端重新发送原始写入操作的方式回复最终的COMMIT请求。在关闭（2） 或fsync（2）期间刷新对服务器的安全异步写入时，版本3客户端使用COMMIT操作 系统调用，或遇到内存压力时。

有关NFS版本3协议的更多信息，请阅读 RFC 1813。
A2。我可以跨TCP / IP传输协议运行NFS吗？
答：客户端对NFS over TCP的支持已集成到所有2.4及更高版本的内核中。
TCP的服务器支持出现在2.4.19及更高版本的2.4内核中，以及2.6及更高版本的内核中。并非所有基于2.4的发行版都支持Linux NFS服务器中的NFS over TCP。
A3。是否还有其他版本的NFS正在开发中？
答：是的。NFS版本4正在互联网工程任务组（IETF）的监督下开发 。IETF主持 了几个 描述NFS Version 4工作组迄今所做工作的文档。一些商业供应商已经发布了支持新版NFS的NFS客户端和服务器。
在Andy Adamson的指导下，密歇根大学信息技术集成中心正在开发Linux版本的NFS 。此版本现在可在Linux 2.6内核中使用。虽然这是NFS版本4客户端和服务器的参考实现，但是作为IETF标准过程的一部分需要两个这样的实现之一，它仍然缺少一些功能。这些功能目前正在开发中，很快就会出现。有关更多信息，请访问CITI UM的 NFSv4项目网站。
A4。如何防止使用NFS版本2或其他NFS版本？
答：协议版本是在安装时确定的，可以通过指定服务器支持的NFS协议版本或传输协议版本来修改。例如，客户端挂载命令
mount -o vers = 3 foo：// bar将在授予挂载请求时请求服务器使用NFS版本3（请注意，“vers”和“nfsvers”在mount命令中具有相同的含义;字符串“vers”与Solaris和其他供应商的NFS实现兼容）。如果您希望在所有情况下都禁止使用NFS版本2，则必须在服务器上重新启动rpc.mountd，并使用选项 “-N 1 -N 2”。执行此操作的最佳方法是通过修改NFS启动脚本选项，然后关闭并重新启动NFS作为整体来修改服务器上的nfs rpc.mountd配置：
cd /etc/rc.d/init.d
修改nfs脚本中的RPCMOUNTDOPTS以包含 “-N 1 -N 2”
使用“./nfs restart”重新启动nfs（您必须具有root访问权限）
现在，在重新启动rpc.mountd后尝试使用NFS版本2（现在无法识别）nfs挂载文件系统时，您将收到以下错误：
mount：RPC：无法接收; errno =拒绝连接
当您卸载任何nfs挂载的文件系统时，无论何时挂载，您都会收到以下（非致命）警告：
错误的UMNT RPC：RPC：程序/版本不匹配; 低版本= 3，高版本= 3
A5。我可以在Linux上使用NFS的Kerberos身份验证吗？
A. Sun定义了一个名为RPCSEC GSSAPI的新接口，该接口创建了对基于RPC的NFS等协议使用身份验证插件的能力。这是为NFS提供Kerberos身份验证支持的标准方法。
使用RPCSEC支持NFS安全机制GSSAPI目前正在Linux中开发，基于2.6内核中已有的工作。完成后，RPCSEC GSSAPI将与所有版本的NFS协议一起使用。除了三种Kerberos安全性（身份验证，完整性检查和完全隐私）之外，RPCSEC GSSAPI最终还将支持其他安全风格，如SPKM3，并将与其他实现完全兼容，例如Solaris中的实现。
除了对RPCSEC GSSAPI的内核支持之外，还需要以各种用户级更改的形式提供额外支持（例如，mount命令和一对rpcgss守护程序）。目前，只有Fedora Core 2在其内核中启用了RPCSEC GSSAPI，并将用户级支持集成到其标准发行版中。我们希望，随着这项工作的成熟，它将被所有基于2.6的发行版所采用。
目前Fedora Core 2仅支持在NFS版本4中使用Kerberos 5身份验证。由于存在漏洞和缺少功能，目前支持使用Kerberos的Linux NFS仅适用于早期采用者，而不适用于生产用途。
有关RPCSEC GSS的更多信息，请阅读 RFC 2203。有关RPCSEC GSSAPI的Linux实现的信息，请访问 此处。
A6。NFS协议版本4中的主要新功能是什么？
答：以下是新功能的简短摘要。有关这些功能的完整讨论，请参阅 NFSv4工作组提供的 文档。

NFS版本2和3是无状态协议，但NFS版本4引入了状态。NFS Version 4客户端使用state来通知NFS Version 4服务器其在文件上的意图：锁定，读取，写入等。NFS版本4服务器可以向客户端返回有关其他客户端对文件有何意图的信息，以允许客户端通过委派更积极地缓存文件数据。为了保持状态一致，NFS版本4协议内置了更复杂的客户端和服务器重启恢复机制。


NFS版本4引入了对字节范围锁定和共享保留的支持。NFS版本4中的锁定是基于租约的，因此NFS版本4客户端必须与NFS版本4服务器保持联系以继续扩展其打开和锁定租约。


NFS版本4引入了文件委派。NFS版本4服务器可以允许NFS版本4客户端访问和修改其自己的缓存中的文件，而不向服务器发送任何网络请求，直到服务器通过回调指示另一个客户端希望访问文件。在没有其他客户端希望同时访问一组文件的情况下，这会显着减少NFS版本4客户端和服务器之间的通信量。


NFS版本4使用复合RPC。NFS版本4客户端可以将多个传统NFS操作（例如，LOOKUP，OPEN和READ）组合到单个RPC请求中，以在一次网络往返中执行复杂操作。


NFS版本4指定了许多复杂的安全机制，并要求所有符合要求的客户端实现它们。除了传统的AUTH_SYS安全性之外，这些机制还包括Kerberos 5和SPKM3。提供了一个新的API，以便将来轻松添加新的安全机制。


NFS版本4标准化了Posix和Windows环境中ACL的使用和解释。它还支持命名属性。用户和组信息以字符串的形式存储，而不是数值。ACL，用户名，组名和命名属性以UTF-8编码存储。


NFS版本4将不同的NFS协议（stat，NLM，mount，ACL和NFS）组合到单个协议规范中，以便更好地与网络防火墙兼容。


NFS版本4引入了对文件迁移和复制的协议支持。


NFS版本4需要支持RPC over streaming网络传输协议，例如TCP。虽然许多NFS版本4客户端继续通过数据报支持RPC，但是这种支持可能会逐步淘汰，以支持更可靠的流传输协议。

有关NFS版本4协议的更多信息，请阅读 RFC 3530。
A7。我听说NFS版本4不能与早期版本的NFS互操作。什么是真正的交易？
答： 与仅NFS版本3客户端无法与仅NFS版本2服务器通信的方式相同，仅NFS版本4客户端或服务器无法与仅支持早期版本NFS的客户端和服务器通信。NFS版本4在RPC标头中使用不同的版本号来区分新协议版本。因此，仅支持NFS版本4的客户端无法与仅支持版本2和3的服务器通信。通过实现可以使用所有三种协议版本进行通信的客户端和服务器实现真正的互操作性：NFS版本2,3和4。
早期版本的Linux NFS Version 4原型使用两个独立的客户端：支持NFS版本2和3的原始客户端，以及仅支持NFS版本4的新的单独客户端。由于各种原因，这阻止了安装NFS版本4服务器的能力在安装NFS版本2和3服务器的同时。这是一个实现选择，而不是协议限制。现在不再是这样了：Linux 2.5 NFS客户端和Linux NFS客户端的所有未来版本都可以无缝地支持所有三个版本，并且可以同时挂载导出版本2，版本3和版本4的服务器。
目标是NFS版本4将与版本2和3共存，其方式与NFS版本3与NFS版本2共存的方式大致相同。升级应该几乎是透明的。
当客户端上运行的应用程序使用NFS版本4的某些新功能（如强制锁定，共享预留和委派）时，会出现一些小的互操作性问题。这些功能有助于使NFS版本4与CIFS等传统Windows文件系统更兼容。制作可以同时通过CIFS和NFS导出文件系统的文件服务器的Network Appliance发布了描述其中一些问题的论文。看到：
Multiprotcol数据访问：NFS，CIFS和HTTP [TR 3014]
SecureShare：保证多协议文件锁定[TR 3024]
A8。什么是接近开放的缓存一致性？
A. 完全不同的NFS客户端之间的高速缓存一致性实现起来非常昂贵，因此NFS可以满足大多数日常类型的文件共享要求。日常文件共享通常是完全顺序的：第一个客户端A打开文件，向其写入内容，然后关闭它; 然后客户端B打开相同的文件，并读取更改。
因此，当应用程序打开存储在NFS中的文件时，NFS客户端会检查它是否仍然存在于服务器上，并通过发送GETATTR或ACCESS操作被允许进入开启者。当应用程序关闭文件时，NFS客户端会将所有挂起的更改写回文件，以便下一个开启者可以查看更改。这也使NFS客户端有机会通过close（）的返回代码向应用程序报告任何服务器写入错误。此行为称为接近打开的高速缓存一致性。
Linux通过比较文件关闭后完成的GETATTR操作的结果与下次打开文件时完成的GETATTR操作的结果，实现了接近开放的缓存一致性。如果结果相同，客户端将假定其数据缓存仍然有效; 否则，清除缓存。
在2.4.20中，Linux NFS客户端引入了接近开放的缓存一致性。如果由于某种原因您拥有依赖于旧行为的应用程序，则可以使用“nocto”挂载选项禁用“近距离打开”支持。
客户端的数据缓存仍有机会包含陈旧数据。NFS版本3协议引入了“弱缓存一致性”（也称为WCC），它提供了一种在操作之前和之后检查文件属性的方法，以允许客户端识别其他客户端可能已经进行的更改。不幸的是，当客户端使用许多同时更新同一文件的并发操作时，无法判断是客户端的更新还是其他客户端的更新更改了文件。
因此，某些版本的Linux 2.6 NFS客户端完全放弃WCC检查，只需信任自己的数据缓存。在这些版本上，如果打开文件进行写入，客户端可以维护一个充满陈旧文件数据的缓存。在这种情况下，使用文件锁定是确保所有客户端都能看到文件数据的最新版本的最佳方法。
系统管理员可以尝试使用“noac”挂载选项来实现多个客户端之间的属性缓存一致性。几乎每个客户端操作都会检查文件属性信息。通常，客户端会将此信息缓存一段时间，以减少网络和服务器负载。当“noac”生效时，客户端的文件属性缓存被禁用，因此每个需要检查文件属性的操作都会被强制返回服务器。这允许客户端以非常快的速度查看文件的更改，但代价是许多额外的网络操作。
注意不要将“noac”与“无数据缓存”混淆。“noac”挂载选项将使文件属性与服务器保持同步，但仍存在可能导致客户端和服务器之间数据不一致的争用。如果您需要客户端之间的绝对缓存一致性，应用程序可以使用文件锁定，其中客户端在文件被锁定时清除文件数据，并在解锁文件之前将更改刷新回服务器; 或应用程序可以使用O_DIRECT标志打开其文件以完全禁用数据缓存。
为了更好地理解NFS缓存设计中所面临的妥协，请参阅Callaghan的“ NFS Illustrated”。
A9。为什么在多个客户端上使用O_APPEND打开文件会导致文件损坏？
答 ：NFS协议不支持原子追加写入，因此对于任何平台，追加写入在NFS 上永远不是原子的。
大多数NFS客户端（包括比2.4.20更新的内核中的Linux NFS客户端）支持“接近开放”的高速缓存一致性，这提供了良好的性能并满足大多数应用程序的共享需求。这种高速缓存一致性不会在多个客户端之间提供文件大小属性的严格一致性，这对于确保追加写入始终放在文件末尾是必要的。
阅读所有关于NFS高速缓存一致性模型这里。
或者，NFS协议可以包括特定的原子追加写入操作，但是今天的协议版本没有。NFS协议的设计者认为原子附加写入很少使用，因此他们从未添加该功能。即使有这样的功能，保持文件大小属性是最新的将是具有挑战性的。
A10。当我的申请因ESTALE错误而失败时，这意味着什么？
A. NFS协议不按名称或路径引用文件和目录; 它使用一个称为文件句柄的不透明二进制值。在NFSv3中，此文件句柄最长可达64个字节; NFSv4允许它们更大。文件的文件句柄由NFS服务器分配，并且在该服务器的生命周期内应该是唯一的。客户端通过执行LOOKUP操作或使用READDIRPLUS操作的部分结果来发现文件的文件句柄的值。在安装NFS文件系统时，通常会执行一个特殊的过程来确定文件系统根目录的文件句柄。
ESTALE是文件句柄无效时服务器报告的错误。以下是文件句柄无效的一些常见原因：
1.该文件驻留在无法访问的导出中。 它可能是未导出的，导出的访问列表可能已更改，或者服务器可能已启动但只是不导出其共享。
2.文件句柄指的是已删除的文件。 在服务器上删除文件后，客户端在尝试使用从先前的LOOKUP缓存的文件句柄访问该文件之前不会发现。在另一个客户端上使用时，使用rsync或mv替换文件是导致ESTALE错误的常见方案。
3.该文件已重命名为另一个目录，并且在Linux NFS服务器导出的共享上启用了子树检查。 有关Linux NFS服务器上子树检查的更多详细信息，请参阅问题C7。
4.保存导出文件的分区的设备ID已更改。 文件句柄通常包含全部或部分物理设备ID，并且该ID可能会在重新启动，与RAID相关的更改或服务器上的硬件热交换事件后发生更改。在Linux上使用“fsid”导出选项将强制导出的分区的fsid保持不变。有关更多详细信息，请参见“exports”手册页。
5.导出的文件系统不支持永久的inode编号。 出于这个原因，通过NFS导出FAT文件系统是有问题的。通过仅导出具有良好NFS支持的本地文件系统可以避免此问题。有关更多信息，请参阅问题C6。
客户端可以在路径名解析期间遇到ESTALE错误时恢复，但在READ或WRITE操作期间不会恢复。NFS客户端通过在读取或写入请求期间替换文件时立即通知应用程序来防止数据损坏。毕竟，如果应用程序写入错误文件或从错误文件读取，通常会造成灾难性后果。
因此，通常，要从ESTALE错误中恢复，应用程序必须关闭发生错误的文件或目录，然后重新打开它，以便NFS客户端可以再次解析路径名并检索新文件句柄。
即使在路径名解析期间，较旧的Linux NFS客户端也无法从ESTALE错误中恢复。在2.6.12内核及更高版本中，当遇到ESTALE以正确恢复时，Linux VFS层可以重新获得路径名解析。

B.表现
B1。一般来说，我该怎么做才能提高NFS性能？
A.查看 NFS Howto doc 的 性能部分，然后查看几个方面：
服务器上的磁盘IO速度有多快？这将对版本2和版本3的整体NFS性能产生重大影响。
您的应用程序是否使用O_SYNC选项打开其文件？这将迫使NFS版本3的行为与（同步）NFS版本2完全相同。
UDP需要IP片段重组。如果您在netstat -s的输出中看到碎片错误，则可能需要增加套接字缓冲区的大小。
你有足够的NFS守护进程吗？查看/ proc / net / rpc / nfsd的内容，尤其是以“th”开头的行。该行的第一个数字是启动并等待NFS请求的NFS服务器线程的总数。第二个数字表示在任何时候所有线程是否一次运行。剩余的数字是线程计数时间直方图。有关根据此直方图中的数据调整服务器的详细信息，请参阅NFS操作方法。
您的NIC和交换机/集线器/路由器是否可以自动协商到10baseT或半双工？半双工将为您提供更多的网络冲突，这是UDP中NFS性能最糟糕的事情。
你在运行ext3还是ReiserFS？您可能会将日志放在单独的磁盘上或NVRAM上。截至2002年1月，ext3允许这样做，而Reiser有一个补丁可用。
B2。一切似乎都很慢，我认为默认的rsize和wsize设置为1024 - 发生了什么？
答：通常，Linux NFS客户端使用预读和延迟写入来隐藏NFS读写操作的延迟。但是，客户端每页只能缓存一个读取或写入请求。因此，如果读取或写入整个页面需要多个线上读取或写入操作（如果rsize或wsize为1024，则肯定会这样做），这些操作中的每一个必须在下一个操作发布之前完成。对于小型NFS版本3写入操作，写入必须是FILE_SYNC，因为客户端必须在发出下一个写入之前完全完成每个写入。
请注意，对于支持较大页面的硬件，此限制尤为重要。例如，许多分销商提供了一个为Itanium处理器构建的Linux内核，它使用16KB页面，而不是通常在32位x86系统上找到的4KB页面。在这样的系统上，如果wsize小于16KB，则客户端始终按顺序发送写操作（如果它们出现在同一页中）。
最后，请注意，在2.4内核中应用与TCP over TCP实现相关的所有修补程序时，Linux服务器允许的最大传输大小（NFSSVC_MAXBLKSIZE）设置为32KB。最新的2.4内核集成了TCP支持，允许传输大小高达32KB。
B3。为什么我不能在我的客户端上安装超过255个NFS文件系统？为什么有时甚至不到255？
A.在Linux上，为每个挂载的文件系统分配一个主编号，指示它是什么文件系统类型（例如，ext3，nfs，isofs）; 和次要编号，使其在相同类型的文件系统中是唯一的。在2.6之前的内核中，Linux主要和次要数字只有8位，因此它们可以在数字范围内从0到255.由于次要数字只有8位，因此系统只能安装255个相同类型的文件系统。因此，系统最多可以安装255个NFS文件系统，另外255个ext3文件系统，255个以上的iosfs文件系统，等等。2.6之后的内核具有20位宽的次要数字，这减轻了这种限制。
但是，对于Linux NFS客户端，问题有点糟糕，因为它是一个匿名文件系统。基于磁盘的本地文件系统具有与之关联的块设备，但匿名文件系统则没有。 例如，/ proc是一个匿名文件系统，其他网络文件系统也是如此。所有匿名文件系统共享相同的主要编号，因此在单个主机上最多只能安装255个匿名文件系统。
通常，在任何给定的客户端上，您不需要超过十或二十个NFS挂载。但是，在某些大型企业中，您的工作和用户可能分布在数百个NFS文件服务器上。要解决可以在单个主机上安装的NFS文件系统数量的限制，我们建议您为Linux设置并运行一个automounter守护程序。自动挂载程序根据需要查找并装入文件系统，并卸载它发现的任何非活动状态。您可以在此处找到有关Linux自动安装程序的更多信息 。
您还可能会对系统上的特权网络端口数量设置限制。NFS客户端使用唯一的套接字，每个NFS安装点都有自己的端口号。使用自动挂载程序可以通过自动卸载未使用的文件系统来帮助解决有限数量的可用端口，从而释放其网络端口。Linux NFS客户端中的NFS版本4支持每个客户端 - 服务器对使用一个套接字，这也有助于增加客户端上允许的NFS挂载点数。
B4。为什么NFS Version 2看起来比版本3快得多？
答：这里实际上有两个问题，还有一个功能。一，背景; NFS版本2协议规范 要求服务器在将响应发送到客户端之前将每个写入记录到永久存储。这使得服务器和客户端重启恢复非常简单，并且可以很好地保证发送到服务器的数据是永久存储的。Linux服务器（尽管不是Solaris参考实现）允许通过在/ etc / exports中设置per-export选项来放宽此要求 。此导出选项的名称是“[a] sync”（请注意，还有一个同名的客户端安装选项，但它具有不同的功能，并且不会破坏NFS协议合规性）。
设置为“sync”时，Linux服务器行为严格符合NFS协议。这是大多数其他服务器实现中的默认行为。设置为“async”时，Linux服务器会在将数据或元数据修改操作刷新到永久存储之前回复NFS客户端，从而提高性能，但会破坏有关服务器重新启动恢复的所有保证。

第一个问题：
在nfs-utils-1.0.1之前，Linux NFS服务器上此导出选项的默认值为“async”。如果系统管理员未在/ etc / exports中指定“sync”或“async” ，则 exportfs默认使用“async”。这允许服务器在将请求的数据写入服务器磁盘之前回复版本2写入操作和元数据更新操作（例如CREATE或MKDIR），从而大大提高写入操作的性能以及引入无法检测的数据的可能性腐败。从版本1.0.1开始的nfs-utils的发布使用默认值“sync”，这使得Linux服务器能够正确地符合NFS协议规范。


第二个问题：
在Linux 2.2中支持NFS版本3的NFS服务器不支持“异步”导出选项。因此，默认情况下，在运行带有旧版本nfs-utils软件包的Linux 2.2的系统上，NFS版本2写入速度快且不安全，但版本3写入和提交操作是安全的，虽然速度较慢，因为它们始终遵循客户端的请求对于UNSTABLE或FILE_SYNC（参见问题A1）。


功能：
当您使用exportfs命令及其详细选项集时，它会显示对每个导出的文件系统有效的各种导出选项。如果设置了“async”导出选项，它将显示在选项列表中，但如果请求“sync”，它将不会出现在exportfs参数列表中。这反映了“sync”在其他平台中作为默认值的常见用法，但可能有些令人困惑。

B5。为什么默认的NFS Version 2性能似乎与2.4内核中的NFS Version 3性能相当？
答：有关导出选项如何影响Linux NFS服务器写入行为的背景信息，请参阅B4。
从Linux 2.4开始，NFS版本3服务器识别“异步”导出选项。设置此选项后，服务器会在将数据写入永久存储器之前回复客户端。服务器还向客户端发送FILE_SYNC响应，指示客户端不需要保留缓冲数据或发送后续COMMIT操作。如果服务器在实际将数据写入稳定存储之前崩溃，则会将客户端暴露给与NFS版本2（使用“async”）相同的不可检测的损坏。（有关此行为及其后果的进一步讨论，请参阅问题B6。）请注意，即使客户端发送版本3 COMMIT操作，如果已使用“async”选项导出文件系统，服务器也会立即回复。
相反，当在Linux 2.4服务器上使用“sync”导出选项时，版本2和版本3写入都符合NFS协议规范的要求。在这种情况下，NFS版本3具有优于NFS版本2的性能优势，同时在服务器崩溃期间保持数据弹性。
请注意，“[a] sync”也会影响服务器上的某些元数据操作。
B6。为什么“异步”导出选项不安全，这真的是一个严重的问题？
答：最大的问题不仅在于它不安全，而且可能无法检测到腐败。
在NFS版本2的Linux实现中，当“async”导出选项生效时，Linux NFS服务器可能会在将所有NFS写入请求发布到磁盘之前崩溃。但是，版本2客户端始终假定数据永久写入稳定存储，并且丢弃包含写入数据的缓冲区是安全的。
服务器崩溃后，版本2客户端无法知道未写入的数据丢失; 这就是为什么版本2写入在服务器回复之前应该是永久性的。即使客户端仍然在其缓存中具有已修改的数据，服务器上的数据也不再与客户端上缓存的数据匹配（因为在服务器崩溃之前部分或全部写入未完成）。这可能会导致应用程序根据客户端缓存的数据而不是服务器上的数据做出未来的决策，从而进一步破坏文件。
对于NFS版本3的Linux实现，不再需要使用“async”导出选项来允许更快的写入。NFS版本3明确允许服务器在受控情况下将数据写入磁盘之前进行回复。它允许客户端和服务器就写入数据的处置进行通信，以便在服务器重新引导时，第3版客户端可以检测到重新引导并重新发送数据。
总之，请确保Linux NFS服务器上的所有导出都通过显式设置或通过将nfs-utils软件包升级到1.0.1版或更高版本来使用“sync”选项。如果需要快速写入，请确保使用NFS版本3装入客户端。您还可以通过向导出添加“wdelay”选项来提高写入性能。
B7。我在某些客户端基准测试中实现了非常快的速度，但是当我的客户端负载很重时，它会大大减慢速度。为什么会这样？
答：Linux客户端限制每个挂载点的挂起读取或写入操作的总数。这可以防止客户端在网络或服务器运行缓慢时使用缓存的读取或写入请求耗尽其内存。硬限制是每个安装点256个未完成的读取或写入操作。达到该限制时，客户端不会发出新的读取或写入操作，直到至少一个未完成的读取或写入操作完成，从而序列化该挂载点上的所有读取和写入，直到负载减少。
减轻这种影响的两种方法是：
1.
在客户端的挂载点上增加rsize和wsize。这会增加在任何给定时间可能涉及未完成读取或写入的数据量。
2.
3.
在客户端上多次挂载相同的服务器分区，并在挂载点之间分布应用程序。
4.
2.6和更高版本的内核中已删除此限制。
B8。当我挂载Linux NFS服务器时，为什么我的客户端不允许我使用大于8KB的rsize或wsize？
答： NFS版本2支持最多8KB的读写操作。NFS版本3允许更大的读写（参见问题 A1）。对于NFS版本2或3，早于2.4.20的库存2.4内核不支持大于8192字节的读取或写入操作。服务器端TCP支持（在2.4.20中作为实验性编译时选项引入）增加了服务器的最大值通过增加NFSSVC_MAXBLKSIZE的值来将I / O大小增加到32KB （参见问题B2）。
当客户端安装文件服务器时，文件服务器会在单个操作中通告它可以读取或写入的最大字节数。客户端始终使用服务器的最大值和mount命令中客户端指定的rsize和wsize值指定的值中较小的值。
使用UDP时，较大的rsize和wsize值可能会抑制性能。UDP数据报必须分成适合您网络的最大传输单元的片段。丢失任何这些片段需要重传整个数据报。如果您的网络拥挤，这可能会对客户端性能产生特别不利的影响。TCP在恢复一个或两个丢失的段并管理网络拥塞方面要好得多，因此在使用NFS over TCP时，更大的I / O操作通常可以更有效地提高性能。
B9。我使用“sync”或“noac”挂载选项。我增加了我的wsize，但写入吞吐量低于我的预期。为什么是这样？
答： 通常，NFS客户端会延迟发送应用程序写入请求，从而允许应用程序处理与NFS写入操作重叠。NFS客户端仅在应用程序关闭或刷新文件时使应用程序等待写入完成。但是，当客户端同步发送写入操作时，客户端会使应用程序等待每个写入操作在服务器上完成。这导致性能低得多。
Linux NFS客户端在许多情况下使用同步写入，其中一些是显而易见的，其中一些是您可能不期望的。应用程序通过使用O_SYNC或O_DSYNC标志打开文件，为单个文件启用同步写入。系统管理员通过使用“sync”选项挂载该文件系统，为本地文件系统中的所有文件启用同步写入。“noac”挂载选项还可以启用同步写入。如果没有，则在客户端延迟写入时，在其他客户端上运行的应用程序将很难检索文件修改。
目前，Linux NFS客户端有一个限制，阻止它安全地生成大型同步写入。客户端将大写请求分解为不大于单个页面的线上写入操作，以保证写入请求以字节顺序到达服务器的磁盘（某些应用程序依赖于此行为）。即使您将wsize设置为大于页面，客户端也会将任何应用程序写入请求分解为页面大小的NFS写入操作以满足此保证。
此外，如果服务器的页面大小大于客户端的页面大小，则当客户端以小块写入时，服务器将被强制执行其他工作。NFS客户端通常将读取和写入对齐到它们自己的页面大小，如果它使用较大的页面，则可能在服务器上未对齐。根据服务器操作系统和文件系统，这可能会导致许多性能限制问题。
B10。有时我的服务器变慢或变得反应迟钝，然后恢复生机。我正在使用NFS over UDP，我注意到网络上有很多IP碎片。有什么我能做的吗？
A. 必须将大于IP最大传输单元（MTU）的UDP数据报分成足够小以便传输的部分。例如，如果您的网络MTU为1524字节，则Linux IP层必须将大于1524字节的UDP数据报分成不同的数据包，所有数据包都必须小于MTU。这些分离的数据包称为片段。
Linux IP层在分解UDP数据报时传输每个片段，在每个片段中编码足够的信息，以便接收端可以将各个片段重新组合成原始UDP数据报。如果发生阻止客户端继续分段数据包的事情（例如，超出IP层中的输出套接字缓冲区空间），则IP层停止发送片段。在这种情况下，接收端有一组不完整的片段，并且在一定时间窗口之后，如果片段没有收到足够的片段来组装完整的数据报，它将丢弃片段。发生这种情况时，UDP数据报将丢失。客户端在一定时间间隔后没有收到服务器的回复时检测到此丢失，并通过重新传输数据报进行恢复。
在大量写入负载下，Linux NFS客户端可以生成许多大型UDP数据报。这可以快速耗尽客户端上的输出套接字缓冲区空间。如果在短时间内多次发生这种情况，客户端会向服务器发送大量片段，但几乎从不会向服务器获取整个数据报的片段。这将填充服务器的IP重组队列，导致它无法通过UDP访问，直到它从队列中排出无用的片段。
请注意，在读取负载较重的服务器上可能会发生同样的情况。如果服务器的输出套接字缓冲区太小，则大的读取将导致它们在IP碎片期间溢出。然后，客户端的IP重组队列会填充无用的片段，并且很少有UDP流量可以到达客户端。
以下是此问题的一些症状：
您使用带有大型wsize的NFS（相对于网络的MTU），并且您的应用程序工作负载是写入密集型的，或者使用带有读取密集型应用程序的大型rsize。
您可能会在服务器或客户端上看到许多碎片错误（netstat -s将讲述故事）。
您的服务器可能会定期变得非常慢或无法访问。
增加服务器上的线程数对性能没有影响。
一个或少数客户端似乎使服务器无法使用。
客户端和服务器之间的网络路径可能具有带有小端口缓冲区的路由器或交换机，或者路径可能包含以不同速度（100Mb / s和GbE）运行的链路。
解决方法是使Linux的IP分段逻辑继续分段数据报，即使输出套接字缓冲区空间超过其限制。此修复程序出现在比2.4.20更新的内核中。您可以通过以下几种方法之一解决此问题：
1.使用NFS over TCP。TCP不使用碎片，因此它不会遇到此问题。对于仅支持NFS over UDP的旧Linux NFS客户端和服务器，可能无法使用TCP。
2.如果无法使用NFS over TCP，请将客户端升级到2.4.20或更高版本。
3.如果无法升级客户端，请增加客户端套接字缓冲区的默认大小（参见下文）。2.4.20及更高版本的内核会自动为NFS客户端的套接字缓冲区执行此操作。有关 更多信息，请参见 NFS方法的 第5.3节。
4.如果你的rsize或wsize非常大，请减少它。这将减少客户端和服务器的输出套接字缓冲区的负载。
5.通过确保您的GbE链路使用全流控制，交换机和路由器端口使用足够的缓冲区大小以及所有链路正在协商其最快设置来减少网络拥塞。
B11。为什么我的服务器在使用Linux客户端时会看到如此多的ACCESS调用？
A. 默认NFS服务器行为是为了防止客户端计算机上的root用户具有对导出文件的特权访问权限。服务器通过将“root”用户映射到服务器端的某些非特权用户（通常是用户“nobody”）来完成此操作。这被称为root压扁。大多数服务器（包括Linux NFS服务器）都提供导出选项以禁用此行为，并允许所选客户端上的root用户享有导出文件系统的完全root权限。
不幸的是，NFS客户端无法确定服务器是否正在压缩root。因此，当客户端以root用户身份运行应用程序时，Linux客户端将使用NFS版本3 ACCESS操作。如果应用程序作为普通用户运行，则客户端使用它自己的身份验证检查，并且不愿意联系服务器。
Linux NFS客户端应该缓存这些ACCESS操作的结果。事实上，在新的2.6.x内核中，它执行此操作并将ACCESS检查扩展到所有用户，以允许在服务器上进行通用的uid / gid映射。这还可以为服务器的本地文件系统中的访问控制列表提供适当的支持。在2.6之前的内核中，库存NFS客户端不会缓存ACCESS操作的结果。

C.常见的导出配置错误
C1。如何在服务器上跟踪导出的文件系统和客户端挂载点？
A. / etc / exports包含有关如何正常导出文件系统的信息。这只能由exportfs读取。
/ var / lib / nfs / etab包含有关当前应将哪些文件系统导出给谁的信息。
/ var / lib / nfs / rmtab包含目前某些客户端实际安装的文件系统的列表。
/ proc / fs / nfs / exports包含有关当前导出到实际客户端（个人，而不是子网或其他）的文件系统的信息。
/ var / lib / nfs / xtab与/ proc / fs / nfs / exports的信息相同， 但由nfs-utils维护，而不是由内核直接维护。它仅在未安装/ proc时使用。
C2。我是否可以修改导出权限而无需重新安装客户端以使其生效？
答：是的。最安全的做法是编辑/ etc / exports 并运行“ exportfs -r ”。
请注意，当挂载请求到达时，mountd check ... / etab以查看是否允许该主机访问。如果是，则将一个条目放在 ... / rmtab中并导出文件系统，从而在/ proc / fs / nfs / exports中创建一个条目 。
当您运行“ exportfs -io <options> host：/ dir 然后更改../etab中的条目，或者添加一个新条目。如果它是子网/通配符/网络组条目，则../中的每一行 检查rmtab是否匹配。当找到匹配项时，将为内核提供（或更改）特定于主机的条目。当您运行“ exportfs -a”时，它确保/ etc / exports中的所有条目正确地反映在../etab中.etab中的任何额外条目都是单独的。一旦确定了etab的正确内容，就会检查rmtab以创建etab中任何新条目的特定主机条目列表。特定条目被提供给内核。
当您运行“ exportfs -r ”时，它会忽略../etab的先前内容，并将etab初始化为/ etc / exportfs的内容。然后它检查rmtab并对/ proc / fs / nfs / export 进行必要的更改。
C3。我的出口似乎是每个人都可读的 - 或者/ etc / exports没有给出预期的权限
A. / etc / exports对空格非常敏感 - 因此以下语句不一样，因为选项“hostname”和左括号之间的空格：

/ export / dir hostname（rw，no_root_squash） 
/ export / dir主机名（rw，no_root_squash）
第一个将授予对/ export / dir的主机名读写访问权限， 而不会压缩root权限。第二个将使用root squash 授予主机名读写权限，并且它将授予其他所有人读写权限，而不会压缩root权限。
C4。我相信Linux NFS服务器不会导出fat32分区。那是对的吗？
答：FAT文件系统可以从早期的2.4内核开始导出，但如果广泛使用，可能会导致悲伤。首先，只有那些由导出的文件系统支持的操作才会受到尊重。这些文件系统不支持“chown”，“link”和“symlink”等操作，并且会失败。读/写/创建等，应该没问题，只要文件保持相对不变。
最严重的问题是FAT文件系统布局不包含足够的信息来创建NFS创建持久文件句柄所需的持久身份。例如，如果您获取一个文件，将其重命名为另一个目录，将其删除并向其写入新数据，则文件系统中没有任何内容可用于显示生成的文件在任何意义上都是“与原始文件相同，并且在给定有关原始文件的任何详细信息的情况下无法找到新文件。因此，Linux NFS服务器无法保证一旦打开文件，如果以上面给出的方式修改文件，则可以继续访问该文件。然后，NFS可能无法正确定位或识别文件，因此可能会返回ESTALE错误。
C5。有时我的客户端在尝试挂载文件系统时会收到“权限被拒绝”错误，即使它在几小时前管理它而不更改服务器上的配置。
答：您的服务器的/ etc / exports可能配置错误。如果导出文件包含域名和IP地址，则在装入时可能会导致随机客户端行为，尤其是当您的客户端具有向DNS注册的多个IP地址时。
如果导出目录及其祖先之一，并且两者都驻留在服务器上的同一物理文件系统上，则在安装时可能会导致随机客户端行为。
C6。我可以使用Linux NFS服务器导出哪些本地文件系统？
答：我们希望以下本地文件系统能够正常运行，因为它们经常被测试：ext2，ext3，jfs，reiserfs，xfs。
这些本地文件系统可能有用或可能有一些小问题：iso9660，ntfs，reiser4，udf。在NFS邮件列表上询问 详细信息。
任何基于FAT或无法提供永久性inode编号的文件系统都会遇到NFS版本2和3的问题（参见问题C4）。
已知不能与Linux NFS服务器一起使用的本地文件系统是：procfs，sysfs，tmpfs（和friends）。
C7。为什么要禁用NFS服务器导出的子树检查？
A.当NFS服务器导出本地文件系统的子目录但未导出其余部分时，NFS服务器必须检查每个NFS请求是否针对驻留在导出区域中的文件。此检查称为子树检查。
要执行此检查，服务器包含有关分发给NFS客户端的NFS文件句柄中每个文件的父目录的信息。例如，如果将文件重命名为其他目录，则会更改文件句柄，即使文件本身仍是同一文件。这会破坏NFS协议合规性，通常会导致客户端出现错误行为，例如ESTALE错误，对重命名或删除的文件的不当访问，损坏的硬链接等等。
许多人认为，子树检查会比保存更麻烦，在大多数情况下应该避免。该subtree_check只有当你想防止文件处理者获取的是介于服务器的本地文件系统中导出的部分以外的文件猜测***选项是必需的。如果您需要确定没有人可以访问本地文件系统导出部分之外的文件，请在服务器上设置分区，以便只导出整个文件系统。

D.常见错误消息
D1。我一直在NFS服务器上获得权限失败消息。这些是什么？
A.您提到的消息采用以下格式：

1月7日09:15:29服务器内核：fh_verify：邮件/来宾权限失败，acc = 4，错误= 13 
Jan 7 09:23:51服务器内核：fh_verify：ekonomi / test permission failure，acc = 4，error = 13

当您对没有写访问权限的文件尝试进行NFS setattr操作时，会发生这种情况。这些消息是无害的。
D2。什么是“愚蠢的重命名”？为什么这些.nfsXXXXX文件会一直显示？
答： Unix应用程序经常打开一个临时文件然后取消链接。他们这样做是为了使文件在文件系统名称空间中看不到任何其他应用程序，以便系统在应用程序退出时自动清理（删除）文件。这被称为“在最后关闭时删除”，并且是Unix应用程序中的传统。
由于NFS协议的设计，无法从名称空间中删除文件，但仍可由应用程序使用。因此，NFS客户端必须使用协议中已存在的内容来模拟它。如果取消链接打开的文件，NFS客户端会将其重命名为看起来像“.nfsXXXXX”的特殊名称。这在文件保持使用时“隐藏”该文件。这被称为“愚蠢的重命名”。请注意，NFS服务器与此行为无关。
在客户端上的所有应用程序关闭了傻瓜重命名的文件后，客户端会通过删除服务器上的文件自动完成取消链接。通常这是有效的，但如果客户端在删除文件之前崩溃，它将保留.nfsXXXXX文件。如果您确定使用这些文件的应用程序不再运行，则可以安全地手动删除这些文件。
NFS版本4协议是有状态的，实际上可以支持delete-on-last-close。不幸的是，没有一种简单的方法可以做到这一点，并保持与版本2和3访问器向后兼容。
D3。这是什么意思：svc：unknown program 100227（me 100003）
答：它指的是NFS客户端的安装请求，它支持Solaris NFS_ACL边带协议。主线内核中的Linux NFS服务器不支持此协议，但许多发行版包括在其NFS实现中提供NFS_ACL支持的修补程序。可以安全地忽略该消息。
D4。我经常在日志中看到这个：
kernel：nfs：server server.domain.name没有响应，仍在尝试
kernel：nfs：task 10754无法获取请求槽
kernel：nfs：server server.domain.name好的
答 ：“无法获取请求槽”消息意味着客户端RPC代码已检测到大量超时（可能是由于网络拥塞，可能是由于服务器过载），并且限制了并发数量未尽的请求，试图减轻负担。一些可能的原因：
网络拥塞
服务器重载
由坏NIC或驱动程序丢弃的数据包（输入或输出）....
D5。我刚刚升级到最新的nfs-utils，现在NLM锁定不再适用于驻留在我的NFS服务器上的文件。这是怎么回事？
A.上有permisions 的/ var / lib中/ NFS /平方米和 /var/lib/nfs/sm.bak 必须解决的文件。rpc.statd运行的任何人必须拥有所有权并且rw访问这些目录。两者的权限应设置为700。此外，etab，rmtab和xtab都必须存在并且可以由root写入。
D6。我已经安装了“intr”选项，但是当我的服务器不可用时，进程仍然无法启动。如何杀死进程以便我可以卸载它们？
答 ：确实，即使使用“intr”挂载选项，也不会总是成功杀死挂在NFS上的任务。在这些实例中，任务通常在内核中等待另一个进程持有的某个信号量。由于信号不能中断信号量，因此信号对挂起任务没有影响。
已经有一些建议的解决方案，但都没有实施。一种是设置一个特殊的信号量类，它们可以用'SIGKILL'填充，但是最早在2.7内核之前无法替换VFS和VM层中的相关信号量。正在考虑的另一个解决方案是当用户请求卸载时使rpciod唤醒所有等待请求，允许它们以错误退出。
在实现这些之前，您可以通过终止在给定文件系统中等待I / O完成的所有进程来解决此问题：
使用'lsof'或其他方法来识别等待目标文件系统中文件的进程，
然后杀死-9所有进程
杀死-9 rpciod。
另一种不太理想的解决方法是使用“软”安装座。这将导致进程在一段时间后停止重试I / O. 最终，进程将变为unstuck，您的文件系统可以卸载。但是，软质安装并不是完全安全的。有关使用“软”安装的风险的描述，请参阅问题E4。
D7。锁定恢复怎么对我不起作用？
A. 当客户端重新启动时，它应该通知它先前安装的任何服务器以释放所有已锁定的锁。它通过在系统启动期间调用rpc.statd来完成此操作。
有几个常见问题可能阻止rpc.statd 工作。首先，确保您的客户端启用了相应的启动脚本（Red Hat发行版上的/etc/rc.d/init.d/nfslock）。接下来，确保当rpc.statd启动时，网络已经可用于它（例如，某些DHCP配置的主机可能存在此问题）。
确保客户端的节点名（uname -n）与客户端上gethostbyname（3）返回的名称相同。这些可能因您的nsswitch配置，/ etc / hosts的内容而有所不同，因为您的客户端是通过DHCP配置的，或者是因为DNS配置错误。内核中的锁定进程使用客户端的节点名来在发送锁定请求时识别其锁定。Rpc.statd在发送恢复通知时必须发送相同的字符串，否则服务器无法将通知与其可能仍为客户端保留的任何锁定相匹配。
还建议NFS客户端的节点名称是完全限定的域名，而不仅仅是主机名。如果具有相同主机名的其他域中的另一个客户端与您的服务器联系，则两个客户端上的完全限定的节点名将允许服务器区分在每个客户端上设置的锁。
在客户端和服务器之间遍历防火墙时，如果需要锁定恢复工作，则必须允许双向RPC流量，因为NLM是基于回调的。可能阻止服务器调用客户端的两个重要问题是：
阻塞锁（F_SETLKW）将受到阻碍，因为客户端希望服务器的lockd守护进程在释放任何冲突锁并授予锁后立即将其调回。
服务器重启恢复将被破坏，因为服务器的rpc.statd 守护程序将无法通知客户端其锁已丢失且需要恢复。
D8。当我的应用程序使用内存映射的NFS文件时，它会中断。为什么？
答： 通常这是因为应用程序开发人员依赖某些本地文件系统行为来保证数据的一致性，而不是仔细阅读mmap手册页以了解所有文件系统实现所需的行为。一些例子：
尽管munmap（2）的某些实现恰好将脏页写入本地文件系统，但munmap（2）的NFS版本却没有。一则msync（2）呼叫总是需要保证脏映射的数据被写入到永久存储。Linux NFS客户端对munmap（2）的处理的细微分支 是不考虑将munmap（2）作为近距离打开高速缓存一致性的近距离操作 。
MS_SYNC和MS_ASYNC标志 之间的区别也很重要。 MS_ASYNC将迫使脏页映射到永久存储最终。只有MS_SYNC保证在 msync（2）返回应用程序之前写入页面。因此，应用程序应使用msync（MS_SYNC）序列化对映射文件的数据写入。
最后，当通过close（2）关闭文件描述符时，Linux NFS客户端可能无法刷新脏映射页面。通常在关闭处理期间 ，客户端可以刷新映射的页面以及由write（2）调用弄脏的页面，但是不保证这种行为。许多应用程序将打开文件，映射它，然后关闭它并继续使用地图。上述行为是尝试优化此用例的性能。
D9。当我更新NFS导出上的共享可执行文件时，在我的客户端上运行的程序都是段错误的。怎么会？
答： 如果只是通过旧版本复制新的可执行文件或库，则通过更改客户端上保持打开的文件，违反了NFS缓存一致性规则（此处所述）。
复制可执行文件会创建一个窗口，在此窗口期间，NFS客户端的缓存可能包含旧版本的部分内容和新版本的部分内容，所有这些内容都组合在同一文件中。更新NFS共享上的可执行文件和共享库的正确方法是使用带有'-b'选项的安装程序。这将重命名正在使用的可执行文件的版本，然后创建一个全新的文件以包含新版本的可执行文件。
D10。我正在尝试使用flock（） / BSD锁来锁定多个客户端上使用的文件，但文件已损坏。怎么会？
A. flock（） / BSD锁仅在2.6.12之前的Linux NFS客户端上本地执行。使用fcntl（） / POSIX锁定以确保其他客户端可以看到文件锁定。
以下是一些序列化对NFS文件的访问的方法。
使用fcntl（） / POSIX锁定API。 这种类型的锁定通过NLM协议或通过NFSv4在多个客户端之间提供字节范围锁定。
使用单独的锁文件，并创建它的硬链接。 请参阅creat（2） 手册页的O_EXCL部分中的说明。
值得注意的是，直到早期的2.6内核，O_EXCL创建在Linux NFS客户端上并不是原子的。除非运行的是比2.6.5更新的内核，否则不要在多个NFS客户端之间使用O_EXCL创建并期望原子行为。
这是一个已知的问题，Perl 默认使用flock（） / BSD锁定。这可能会破坏从其他操作系统（例如Solaris）移植的程序，这些操作系统希望flock/ BSD锁像POSIX锁一样工作。
在Linux上，使用文件锁定而不是硬链接具有使用服务器检查客户端缓存的额外好处。获取文件锁定后，客户端将刷新该文件的页面缓存，以便任何后续读取从服务器获取新数据。释放文件锁定后，在释放锁定之前，将对该客户端上的文件的任何更改刷新回服务器，以便等待锁定该文件的其他客户端可以看到更改。
2.6.12中的NFS客户端通过根据POSIX字节范围锁模拟BSD样式的锁，为NFS文件上的flock（） / BSD锁提供支持。使用相同仿真机制或使用fcntl（） / POSIX锁定的其他NFS客户端 将看到Linux NFS客户端看到的相同锁。
在本地Linux文件系统上，POSIX锁和BSD锁彼此不可见。因此，由于这种模拟，在Linux NFS服务器上运行的应用程序仍然会看到NFS客户端锁定的文件被锁定为 fcntl（） / POSIX锁，无论客户端上的应用程序是使用BSD样式还是POSIX-风格锁。如果服务器应用程序使用 flock（）BSD锁，则不会看到NFS客户端使用的锁。
D11。为什么不“ mount -oremount，tcp ”将安装了UDP的NFS安装文件系统转换为使用TCP挂载的文件系统？
A. 在mount命令上的“重新安装”选项只对一般的安装选项，如RO / RW，同步，等等（见的人安装了通用的完整列表mount命令选项）。无法使用“mount -oremount”样式的mount命令更改nfs手册页中列出的NFS特定的挂载选项。您必须卸载文件系统并使用新选项再次安装它才能修改特定于NFS的设置。
请注意， 无论内核中的实际安装设置是否已更改，mount命令都可以更新/ etc / mtab的内容。因此，当您尝试使用特定于NFS的挂载选项安装-oremount时，后续挂载命令可能会报告该设置有效。这只是因为mount命令正在读取/ etc / mtab。在的/ proc /坐骑文件反映了内核使用真实安装选项。
D12。我没有使用“intr”挂载（默认为“nointr”），当我的服务器不可用时，某些进程无法启动。我能做什么？
A. 使用umount命令的“-f”标志强制卸载。当umount命令尝试联系服务器时会有短暂的暂停，然后所有对服务器的未完成请求都将失败，从而使进程可以运行。
收到I / O错误后的某些程序只会尝试更多的I / O，使它们再次无法振荡。出于这个原因，首先尝试先杀死卡住的挂载上的所有进程，然后运行“umount -f”。当I / O请求失败时，进程将变为可充电状态，将看到信号，并将死亡。有时它可以在“杀死进程”的几个阶段然后“umount -f”循环，直到文件系统被卸载，但它通常有效。
如果所有其他方法都失败，您仍然可以使用“umount -l”命令卸载进程挂起的分区。这会导致卡住的挂载与客户端上的文件系统名称空间层次结构分离，因此其他进程将不再可见。您可以将该挂载点替换为另一个挂载到同一服务器再次可用时，或者如果远程数据已移动则替换到其他服务器。但请注意，旧的挂载点将继续消耗客户端内存，直到卡住的进程全部死亡。

E.将Linux NFS与备用平台配合使用
E1。我使用的是Tru64 Unix 4.x或SunOS 4.1.x客户端。NFS文件锁定似乎不起作用，除非我授予所有用户对该文件的权限。
答 ：NFS版本2和3的默认规范允许任何用户锁定文件，无论该用户是否有权访问该文件。Linux NFS服务器的编写者将此行为视为不安全，并选择仅允许有权访问文件的用户锁定它。但是，较旧的SunOS和Tru64客户端以及某些HP / UX客户端通过使用守护程序的凭据发出所有NFS文件锁定请求来利用NFS规范。这意味着如果守护程序无法访问文件，服务器将拒绝锁定它们。
导出选项no_auth_nlm旨在缓解此问题。将其设置在您要导出到这些客户端的任何共享上。这将禁用对文件锁定请求的授权检查。
E2。我没有使用Redhat或VALinux发行版，因此rpm中的nfs-utils启动脚本被破坏了。我该怎么办？
答：您应该注释掉/etc/rc.d/init.d/nfs中的以下行 ：
。/etc/rc.d/init.d/functions
E3。我正在使用Irix客户端，我在Linux服务器上看到了文件列表和cwd的一系列问题。服务器正在运行NFS版本3.这是一个Linux错误吗？
A. IRIX不正确地处理Linux 2.4.x中的NFS服务器使用的小于32字节的文件句柄。SGI在2001年发布的IRIX 6.5.13中解决了这个问题。
解决此问题的方法是使用NFS版本2.在IRIX客户端上，在挂载选项中使用vers = 2。
E4。从Solaris NFS客户端安装Linux NFS服务器时，为什么会出现NFS超时？
A.你得到NFS超时，因为使用的是软坐骑。通常，挂载很难，这需要客户端继续尝试永久地到达服务器。一个软mount允许客户端在一段时间后停止尝试操作。如果在数据或元数据传输期间发生静态数据损坏，则软超时可能会导致静默数据损坏，因此在客户端响应性比数据完整性更重要的情况下，您应该只使用软安装。如果您需要在不可靠的链路（如DSL）上使用软安装，请尝试使用TCP，这是Solaris默认使用的。这将有助于管理短暂网络中断的影响。如果无法使用TCP，则应通过在mount命令选项中指定长重传超时值和相对大量的重试（即timeo = 30，retrans = 10）来降低使用UDP软安装的风险。
请注意，NFS over UDP现在在最新的2.4和2.6内核中使用重新传输超时估计算法，这意味着timeo = mount选项在防止软超时导致数据损坏方面效果较差。

转载于:https://blog.51cto.com/13835328/2382772