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

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

推薦閱讀更多精彩內容