# rpm -qa nfs-utils rpcbind
nfs-utils-1.3.0-0.33.el7.x86_64
rpcbind-0.2.0-38.el7.x86_64

系统 ：centos7.9
nfs版本：nfsstat: 1.3.0
rpcbind版本：rpcbind：0.2.0

查看message日志发现nfs 客户连接端报如下错误

 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 kernel: nginx           D ffff94a9ffd1acc0     0 31787   1066 0x00000080
 kernel: Call Trace:
 kernel: [<ffffffff97585290>] ? bit_wait+0x50/0x50
 kernel: [<ffffffff97587169>] schedule+0x29/0x70
 kernel: [<ffffffff97584c51>] schedule_timeout+0x221/0x2d0
 kernel: [<ffffffff96f06362>] ? ktime_get_ts64+0x52/0xf0
 kernel: [<ffffffff97585290>] ? bit_wait+0x50/0x50
 kernel: [<ffffffff9758683d>] io_schedule_timeout+0xad/0x130
 kernel: [<ffffffff975868d8>] io_schedule+0x18/0x20
 kernel: [<ffffffff975852a1>] bit_wait_io+0x11/0x50
 kernel: [<ffffffff97584e51>] __wait_on_bit_lock+0x61/0xc0
 kernel: [<ffffffff96fbd2e4>] __lock_page+0x74/0x90
 kernel: [<ffffffff96ec6dd0>] ? wake_bit_function+0x40/0x40
 kernel: [<ffffffff97082072>] __generic_file_splice_read+0x5c2/0x5e0
 kernel: [<ffffffff97080930>] ? page_cache_pipe_buf_release+0x20/0x20
 kernel: [<ffffffff96ec6cd5>] ? wake_up_bit+0x25/0x30
 kernel: [<ffffffff97082474>] generic_file_splice_read+0x44/0x90
 kernel: [<ffffffffc07f700a>] nfs_file_splice_read+0x8a/0xd0 [nfs]
 kernel: [<ffffffff97081295>] do_splice_to+0x75/0x90
 kernel: [<ffffffff97081367>] splice_direct_to_actor+0xb7/0x200
 kernel: [<ffffffff97081630>] ? do_splice_from+0xf0/0xf0
 kernel: [<ffffffff97081512>] do_splice_direct+0x62/0x90
 kernel: [<ffffffff9704e1f8>] do_sendfile+0x1d8/0x3c0
 kernel: [<ffffffff9704f84e>] SyS_sendfile64+0x6e/0xc0
 kernel: [<ffffffff97593f92>] system_call_fastpath+0x25/0x2a
 kernel: INFO: task nginx:31790 blocked for more than 120 seconds.
 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 kernel: nginx           D ffff94a939266300     0 31790   1066 0x00000080
 kernel: Call Trace:
 kernel: [<ffffffffc0853a6e>] ? nfs4_file_open+0x14e/0x2b0 [nfsv4]
 kernel: [<ffffffff97588089>] schedule_preempt_disabled+0x29/0x70
 kernel: [<ffffffff97585ff7>] __mutex_lock_slowpath+0xc7/0x1d0
 kernel: [<ffffffff975853cf>] mutex_lock+0x1f/0x2f
 kernel: [<ffffffff9712d206>] ima_file_check+0xa6/0x1b0
 kernel: [<ffffffff9705ddda>] do_last+0x59a/0x1340
 kernel: [<ffffffff9705ec4d>] path_openat+0xcd/0x5a0
 kernel: [<ffffffff97060e9d>] do_filp_open+0x4d/0xb0
 kernel: [<ffffffff9706ef97>] ? __alloc_fd+0x47/0x170
 kernel: [<ffffffff9704c9e4>] do_sys_open+0x124/0x220
 kernel: [<ffffffff9704cafe>] SyS_open+0x1e/0x20
 kernel: [<ffffffff97593f92>] system_call_fastpath+0x25/0x2a
 kernel: nfs: server 192.168.10.121 not responding, still trying
 kernel: INFO: task nginx:31784 blocked for more than 120 seconds.
 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 kernel: nginx           D ffff94a9ffc5acc0     0 31784   1066 0x00000080
 kernel: Call Trace:
 kernel: [<ffffffffc0853a6e>] ? nfs4_file_open+0x14e/0x2b0 [nfsv4]
 kernel: [<ffffffff97588089>] schedule_preempt_disabled+0x29/0x70
 kernel: [<ffffffff97585ff7>] __mutex_lock_slowpath+0xc7/0x1d0
 kernel: [<ffffffff975853cf>] mutex_lock+0x1f/0x2f
 kernel: [<ffffffff9712d206>] ima_file_check+0xa6/0x1b0
 kernel: [<ffffffff9705ddda>] do_last+0x59a/0x1340
 kernel: [<ffffffff9705ec4d>] path_openat+0xcd/0x5a0
 kernel: [<ffffffff97060e9d>] do_filp_open+0x4d/0xb0
 kernel: [<ffffffff9706ef97>] ? __alloc_fd+0x47/0x170
 kernel: [<ffffffff9704c9e4>] do_sys_open+0x124/0x220
 kernel: [<ffffffff9704cafe>] SyS_open+0x1e/0x20
 kernel: [<ffffffff97593f92>] system_call_fastpath+0x25/0x2a
 kernel: INFO: task nginx:31787 blocked for more than 120 seconds.

问题原因：
Mandag 27 november 2006 20:12 skrev Verner Kjærsgaard:

Mandag 27 november 2006 19:33 skrev John P. New:
Verner,

This is a problem with NFS and 2.6 kernels, fast server NICs and
comparatively slower client NICs. This will show up when the server has
a 1000Mb card and the client a 100Mb, or when the server has a 100Mb
card and the client a 10Mb.

Essentially, you have to pass some options to the kernel on terminal
boot, and this varies depending on whether you are using etherboot or
PXE.

See
http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding
for a deeper explanation of the problem and the cure.
//注：原因是server机和目标机网卡传输速率冲突，使得目标机需要大量时间复制大量数据包，其实如果目标机的网卡速率够大，则不用分那么多包，也不会冲突。

协议版本解析：

NFS协议到现在经历了V1、V2、V3、V4四个版本，但是它有一个缺点就是协议没有用户认证机制，而且数据在网络上传送的时候是明文传送，所以安全性极差，一般只能在局域网中使用。

NFSv3是1995年发布的，相比NFSv3，NFSv4发生了比较大的变化，最大的变化是NFSv4有状态了。NFSv2和NFSv3都是无状态协议，服务端不需要维护客户端的状态信息。无状态协议的一个优点在于灾难恢复，当服务器出现问题后，客户端只需要重复发送失败请求就可以了，直到收到服务端的响应信息。但是某些操作必须需要状态，如文件锁。如果客户端申请了文件锁，但是服务端重启了，由于NFSv3无状态，客户端再执行锁操作可能就会出错了。NFSv3需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调。NFSv4设计成了一种有状态的协议，自身实现了文件锁功能，就不需要NLM协议了。

NFSv4和NFSv3的差别如下：

• (1) NFSv4设计成了一种有状态的协议，自身实现了文件锁功能和获取文件系统根节点功能，不需要NLM和MOUNT协议协助了。
• (2) NFSv4增加了安全性，支持RPCSEC-GSS身份认证。
  (3) NFSv4只提供了两个请求NULL和COMPOUND，所有的操作都整合进了COMPOUND中，客户端可以根据实际请求将多个操作封装到一个COMPOUND请求中，增加了灵活性。
  (4) NFSv4文件系统的命令空间发生了变化，服务端必须设置一个根文件系统(fsid=0)，其他文件系统挂载在根文件系统上导出。
  (5)NFSv4支持delegation。由于多个客户端可以挂载同一个文件系统，为了保持文件同步，NFSv3中客户端需要经常向服务器发起请求，请求文件属性信息，判断其他客户端是否修改了文件。如果文件系统是只读的，或者客户端对文件的修改不频繁，频繁向服务器请求文件属性信息会降低系统性能。NFSv4可以依靠delegation实现文件同步。当客户端A打开一个文件时，服务器会分配给客户端A一个delegation。只要客户端A具有delegation，就可以认为与服务器保持了一致。如果另外一个客户端B访问同一个文件，则服务器会暂缓客户端B的访问请求，向客户端A发送RECALL请求。当客户端A接收到RECALL请求时将本地缓存刷新到服务器中，然后将delegation返回服务器，这时服务器开始处理客户端B的请求。
  (6) NFSv4修改了文件属性的表示方法。由于NFS是Sun开发的一套文件系统，设计之出NFS文件属性参考了UNIX中的文件属性，可能Windows中不具备某些属性，因此NFS对操作系统的兼容性不太好。NFSv4将文件属性划分成了三类：
  Mandatory Attributes: 这是文件的基本属性，所有的操作系统必须支持这些属性。
  Recommended Attributes: 这是NFS建议的属性，如果可能操作系统尽量实现这些属性。
  Named Attributes: 这是操作系统可以自己实现的一些文件属性。
  （7）服务器端拷贝：
  如果客户需要从一个NFS服务器拷贝数据到另外一个NFS服务器,nfsv4可以让两台NFS服务器之间直接拷贝数据，不需要经过客户端。
  （8）资源预留和回收：
  NFSv4为虚拟分配提供的新特性。随着存储虚拟分配功能的普及使用，nfsv4可以为预留固定大小的存储空间;同样在文件系统上删除文件后，也能够在存储上面释放相应空间。
  （9）国际化支持：
  NFSv4文件名、目录、链接、用户与组可以使用 UTF-8字符集，UTF-8兼容ASCII码，使得NFSv4支持更多语言。
  （10）RPC合并调用：
  NFSv4允许将多个请求合并为一个rpc引用，在NFSv3每个请求对应一个rpc调用。WAN环境中，NFSv4合并rpc调用可以显著降低延迟。
  （11）安全性：
  NFSv4用户验证采用“用户名+域名”的模式，与Windows AD验证方式类似，NFSv4强制使用Kerberos验证方式。(Kerberos与Windows AD都遵循相同RFC1510标准)，这样方便windows和*nix环境混合部署。
  （12）pNFS
  并行NFS文件系统，元数据服务器负责用户请求调度、数据服务器负责客户请求处理。pNFS需要NFS服务器和客户端协同支持

后来的 NFSv4.1
与NFSv4.0相比，NFSv4.1最大的变化是支持并行存储了。在以前的协议中，客户端直接与服务器连接，客户端直接将数据传输到服务器中。当客户端数量较少时这种方式没有问题，但是如果大量的客户端要访问数据时，NFS服务器很快就会成为一个瓶颈，抑制了系统的性能。NFSv4.1支持并行存储，服务器由一台元数据服务器(MDS)和多台数据服务器(DS)构成，元数据服务器只管理文件在磁盘中的布局，数据传输在客户端和数据服务器之间直接进行。由于系统中包含多台数据服务器，因此数据可以以并行方式访问，系统吞吐量迅速提升。现在新的是nfsv4.2
所以尽可能用nfs4

补充：
nfs4挂载的fsid问题
问题现象：
挂载nfs4时，报错：reason given by server :No such file or directory

背景知识：
NFSv4将所有共享使用一个虚拟文件系统展示给客户端。伪文件系统根目录(/)使用fsid=0标示，只有一个共享可以是fsid=0。客户端需要使用“nfs server ip:/”挂载伪文件系统，伪文件系统一般使用RO方式共享，其他共享可以通过mount –bind选项在伪文件系统目录下挂载。客户端挂载过程需要通过mount –t nfs4指定NFS版本为4，默认采用nfsv3。

解决：
以下是我的配置文件，我想挂在/datapool/nfs目录
/ *(rw,fsid=0,insecure,no_root_squash)
/datapool/nfs *(rw,fsid=1000,insecure,no_root_squash

然后mount -t nfs4 ip:/datapool/nfs /mnt/nfs/

nfs配置参数选项说明：
ro：共享目录只读；
rw：共享目录可读可写；
all_squash：所有访问用户都映射为匿名用户或用户组；
no_all_squash（默认）：访问用户先与本机用户匹配，匹配失败后再映射为匿名用户或用户组；
root_squash（默认）：将来访的root用户映射为匿名用户或用户组；
no_root_squash：来访的root用户保持root帐号权限；
anonuid=<UID>：指定匿名访问用户的本地用户UID，默认为nfsnobody（65534）；
anongid=<GID>：指定匿名访问用户的本地用户组GID，默认为nfsnobody（65534）；
secure（默认）：限制客户端只能从小于1024的tcp/ip端口连接服务器；
insecure：允许客户端从大于1024的tcp/ip端口连接服务器；
sync：将数据同步写入内存缓冲区与磁盘中，效率低，但可以保证数据的一致性；
async：将数据先保存在内存缓冲区中，必要时才写入磁盘；
wdelay（默认）：检查是否有相关的写操作，如果有则将这些写操作一起执行，这样可以提高效率；
no_wdelay：若有写操作则立即执行，应与sync配合使用；
subtree_check（默认） ：若输出目录是一个子目录，则nfs服务器将检查其父目录的权限；
no_subtree_check ：即使输出目录是一个子目录，nfs服务器也不检查其父目录的权限，这样可以提高效率；
Troubleshooting

1、在上面的操作过程中，如果你不幸遇到下面这个问题的话，可以尝试更新 Linux kernel 或通过打开 IPv6 来解决这个问题，这是1个 bug：

mount -t nfs4 172.16.20.1:/ /home/vpsee/bak/

mount.nfs4: Cannot allocate memory

2、如果遇到如下问题，可能是因为你的 mount -t nfs 使用的是 nfsv3 协议，需要明确指出使用 nfsv4 协议挂载 mount -t nfs4：

mount -t nfs 172.16.20.1:/ /home/vpsee/bak/

mount: mount to NFS server '172.16.20.1' failed: RPC Error: Program not registered.

mount -t nfs4 172.16.20.1:/ /home/vpsee/bak/

如果网络不稳定

NFS默认是用UDP协议，换成TCP协议挂载即可：

mount -t nfs 11.11.165.115:/tmp/test0920 /data -o proto=tcp -o nolock

nfs:server xxx.xxx.xxx.xxx is not responding,still trying的解决方法
方法1 ：
我在arm上通过NFS共享文件时出现下面的错误提示
nfs:server is not responding,still trying 原因分析：NFS 的默认传输协议是 UDP，而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。

解决方法：在客户端改用TCP协议，使用下面的命令， **#mount -o tcp 10.10.19.25:/home/export /mnt/local

方法2：** 在目标板上通过NFS复制PC机上较大文件到目标板上的时候遇到的问题：
nfs: server *** not responding, still trying

修改方法：
nfs mount时候出现的NFS崩溃，按照以下的方式mount
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client

附 问题四：在测试时，“./progressbar -qws”后出现如Q3一样的提示 ，按Q3来处理。
以上参考了一些 “ 快乐的天空”的经验，他的网页是：
http://blog.chinaunix.net/u2/67519/showart_677885.html
他的
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /host
应该改成
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client

转载于:https://www.cnblogs.com/cxjchen/archive/2013/04/28/3048435.html