nfs:server is not responding,still trying的解決辦法

# 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

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內容