nfs:server is not responding,still trying的解决办法

Posted 2023-04-12

参考技术A

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

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

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

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

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

后来的 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.nfs4: Cannot allocate memory

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

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

如果网络不稳定

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

Salt之Cpu 100%无响应故障 Salt request timed out. The master is not responding

报错信息如下：

Salt request timed out. The master is not responding. You may need to run your command with `--async` in order to bypass the congested event bus. With `--async`, the CLI tool will print the job id (jid) and exit immediately without listening for responses. You can then use `salt-run jobs.lookup_jid` to look up the results of the job in the job cache later.

 

 

 

CPU一直是非常的高，解决方法是通过 strace -p 7161 跟踪这个pid查出salt再做什么，我这里查出是在lstat一个目录，目录异常，经确认后无用，

删除目录后解决。