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

系統(tǒng) ：centos7.9
nfs版本：nfsstat: 1.3.0
rpcbind版本：rpcbind：0.2.0

查看message日志發(fā)現(xiàn)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機和目標機網(wǎng)卡傳輸速率沖突，使得目標機需要大量時間復(fù)制大量數(shù)據(jù)包，其實如果目標機的網(wǎng)卡速率夠大，則不用分那么多包，也不會沖突。

協(xié)議版本解析：

NFS協(xié)議到現(xiàn)在經(jīng)歷了V1、V2、V3、V4四個版本，但是它有一個缺點就是協(xié)議沒有用戶認證機制，而且數(shù)據(jù)在網(wǎng)絡(luò)上傳送的時候是明文傳送，所以安全性極差，一般只能在局域網(wǎng)中使用。

NFSv3是1995年發(fā)布的，相比NFSv3，NFSv4發(fā)生了比較大的變化，最大的變化是NFSv4有狀態(tài)了。NFSv2和NFSv3都是無狀態(tài)協(xié)議，服務(wù)端不需要維護客戶端的狀態(tài)信息。無狀態(tài)協(xié)議的一個優(yōu)點在于災(zāi)難恢復(fù)，當服務(wù)器出現(xiàn)問題后，客戶端只需要重復(fù)發(fā)送失敗請求就可以了，直到收到服務(wù)端的響應(yīng)信息。但是某些操作必須需要狀態(tài)，如文件鎖。如果客戶端申請了文件鎖，但是服務(wù)端重啟了，由于NFSv3無狀態(tài)，客戶端再執(zhí)行鎖操作可能就會出錯了。NFSv3需要NLM協(xié)助才能實現(xiàn)文件鎖功能，但是有的時候兩者配合不夠協(xié)調(diào)。NFSv4設(shè)計成了一種有狀態(tài)的協(xié)議，自身實現(xiàn)了文件鎖功能，就不需要NLM協(xié)議了。

NFSv4和NFSv3的差別如下：

• (1) NFSv4設(shè)計成了一種有狀態(tài)的協(xié)議，自身實現(xiàn)了文件鎖功能和獲取文件系統(tǒng)根節(jié)點功能，不需要NLM和MOUNT協(xié)議協(xié)助了。
• (2) NFSv4增加了安全性，支持RPCSEC-GSS身份認證。
  (3) NFSv4只提供了兩個請求NULL和COMPOUND，所有的操作都整合進了COMPOUND中，客戶端可以根據(jù)實際請求將多個操作封裝到一個COMPOUND請求中，增加了靈活性。
  (4) NFSv4文件系統(tǒng)的命令空間發(fā)生了變化，服務(wù)端必須設(shè)置一個根文件系統(tǒng)(fsid=0)，其他文件系統(tǒng)掛載在根文件系統(tǒng)上導出。
  (5)NFSv4支持delegation。由于多個客戶端可以掛載同一個文件系統(tǒng)，為了保持文件同步，NFSv3中客戶端需要經(jīng)常向服務(wù)器發(fā)起請求，請求文件屬性信息，判斷其他客戶端是否修改了文件。如果文件系統(tǒng)是只讀的，或者客戶端對文件的修改不頻繁，頻繁向服務(wù)器請求文件屬性信息會降低系統(tǒng)性能。NFSv4可以依靠delegation實現(xiàn)文件同步。當客戶端A打開一個文件時，服務(wù)器會分配給客戶端A一個delegation。只要客戶端A具有delegation，就可以認為與服務(wù)器保持了一致。如果另外一個客戶端B訪問同一個文件，則服務(wù)器會暫緩客戶端B的訪問請求，向客戶端A發(fā)送RECALL請求。當客戶端A接收到RECALL請求時將本地緩存刷新到服務(wù)器中，然后將delegation返回服務(wù)器，這時服務(wù)器開始處理客戶端B的請求。
  (6) NFSv4修改了文件屬性的表示方法。由于NFS是Sun開發(fā)的一套文件系統(tǒng)，設(shè)計之出NFS文件屬性參考了UNIX中的文件屬性，可能Windows中不具備某些屬性，因此NFS對操作系統(tǒng)的兼容性不太好。NFSv4將文件屬性劃分成了三類：
  Mandatory Attributes: 這是文件的基本屬性，所有的操作系統(tǒng)必須支持這些屬性。
  Recommended Attributes: 這是NFS建議的屬性，如果可能操作系統(tǒng)盡量實現(xiàn)這些屬性。
  Named Attributes: 這是操作系統(tǒng)可以自己實現(xiàn)的一些文件屬性。
  （7）服務(wù)器端拷貝：
  如果客戶需要從一個NFS服務(wù)器拷貝數(shù)據(jù)到另外一個NFS服務(wù)器,nfsv4可以讓兩臺NFS服務(wù)器之間直接拷貝數(shù)據(jù)，不需要經(jīng)過客戶端。
  （8）資源預(yù)留和回收：
  NFSv4為虛擬分配提供的新特性。隨著存儲虛擬分配功能的普及使用，nfsv4可以為預(yù)留固定大小的存儲空間;同樣在文件系統(tǒng)上刪除文件后，也能夠在存儲上面釋放相應(yīng)空間。
  （9）國際化支持：
  NFSv4文件名、目錄、鏈接、用戶與組可以使用 UTF-8字符集，UTF-8兼容ASCII碼，使得NFSv4支持更多語言。
  （10）RPC合并調(diào)用：
  NFSv4允許將多個請求合并為一個rpc引用，在NFSv3每個請求對應(yīng)一個rpc調(diào)用。WAN環(huán)境中，NFSv4合并rpc調(diào)用可以顯著降低延遲。
  （11）安全性：
  NFSv4用戶驗證采用“用戶名+域名”的模式，與Windows AD驗證方式類似，NFSv4強制使用Kerberos驗證方式。(Kerberos與Windows AD都遵循相同RFC1510標準)，這樣方便windows和*nix環(huán)境混合部署。
  （12）pNFS
  并行NFS文件系統(tǒng)，元數(shù)據(jù)服務(wù)器負責用戶請求調(diào)度、數(shù)據(jù)服務(wù)器負責客戶請求處理。pNFS需要NFS服務(wù)器和客戶端協(xié)同支持

后來的 NFSv4.1
與NFSv4.0相比，NFSv4.1最大的變化是支持并行存儲了。在以前的協(xié)議中，客戶端直接與服務(wù)器連接，客戶端直接將數(shù)據(jù)傳輸?shù)椒?wù)器中。當客戶端數(shù)量較少時這種方式?jīng)]有問題，但是如果大量的客戶端要訪問數(shù)據(jù)時，NFS服務(wù)器很快就會成為一個瓶頸，抑制了系統(tǒng)的性能。NFSv4.1支持并行存儲，服務(wù)器由一臺元數(shù)據(jù)服務(wù)器(MDS)和多臺數(shù)據(jù)服務(wù)器(DS)構(gòu)成，元數(shù)據(jù)服務(wù)器只管理文件在磁盤中的布局，數(shù)據(jù)傳輸在客戶端和數(shù)據(jù)服務(wù)器之間直接進行。由于系統(tǒng)中包含多臺數(shù)據(jù)服務(wù)器，因此數(shù)據(jù)可以以并行方式訪問，系統(tǒng)吞吐量迅速提升。現(xiàn)在新的是nfsv4.2
所以盡可能用nfs4

補充：
nfs4掛載的fsid問題
問題現(xiàn)象：
掛載nfs4時，報錯：reason given by server :No such file or directory

背景知識：
NFSv4將所有共享使用一個虛擬文件系統(tǒng)展示給客戶端。偽文件系統(tǒng)根目錄(/)使用fsid=0標示，只有一個共享可以是fsid=0。客戶端需要使用“nfs server ip:/”掛載偽文件系統(tǒng)，偽文件系統(tǒng)一般使用RO方式共享，其他共享可以通過mount –bind選項在偽文件系統(tǒng)目錄下掛載?？蛻舳藪燧d過程需要通過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配置參數(shù)選項說明：
ro：共享目錄只讀；
rw：共享目錄可讀可寫；
all_squash：所有訪問用戶都映射為匿名用戶或用戶組；
no_all_squash（默認）：訪問用戶先與本機用戶匹配，匹配失敗后再映射為匿名用戶或用戶組；
root_squash（默認）：將來訪的root用戶映射為匿名用戶或用戶組；
no_root_squash：來訪的root用戶保持root帳號權(quán)限；
anonuid=<UID>：指定匿名訪問用戶的本地用戶UID，默認為nfsnobody（65534）；
anongid=<GID>：指定匿名訪問用戶的本地用戶組GID，默認為nfsnobody（65534）；
secure（默認）：限制客戶端只能從小于1024的tcp/ip端口連接服務(wù)器；
insecure：允許客戶端從大于1024的tcp/ip端口連接服務(wù)器；
sync：將數(shù)據(jù)同步寫入內(nèi)存緩沖區(qū)與磁盤中，效率低，但可以保證數(shù)據(jù)的一致性；
async：將數(shù)據(jù)先保存在內(nèi)存緩沖區(qū)中，必要時才寫入磁盤；
wdelay（默認）：檢查是否有相關(guān)的寫操作，如果有則將這些寫操作一起執(zhí)行，這樣可以提高效率；
no_wdelay：若有寫操作則立即執(zhí)行，應(yīng)與sync配合使用；
subtree_check（默認） ：若輸出目錄是一個子目錄，則nfs服務(wù)器將檢查其父目錄的權(quán)限；
no_subtree_check ：即使輸出目錄是一個子目錄，nfs服務(wù)器也不檢查其父目錄的權(quán)限，這樣可以提高效率；
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 協(xié)議，需要明確指出使用 nfsv4 協(xié)議掛載 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/

如果網(wǎng)絡(luò)不穩(wěn)定

NFS默認是用UDP協(xié)議，換成TCP協(xié)議掛載即可：

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共享文件時出現(xiàn)下面的錯誤提示
nfs:server is not responding,still trying 原因分析：NFS 的默認傳輸協(xié)議是 UDP，而PC機與嵌入式系統(tǒng)通過UPD交互時就會出現(xiàn)嚴重的網(wǎng)卡丟包現(xiàn)象。

解決方法：在客戶端改用TCP協(xié)議，使用下面的命令， **#mount -o tcp 10.10.19.25:/home/export /mnt/local

方法2：** 在目標板上通過NFS復(fù)制PC機上較大文件到目標板上的時候遇到的問題：
nfs: server *** not responding, still trying

修改方法：
nfs mount時候出現(xiàn)的NFS崩潰，按照以下的方式mount
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client

附 問題四：在測試時，“./progressbar -qws”后出現(xiàn)如Q3一樣的提示 ，按Q3來處理。
以上參考了一些 “ 快樂的天空”的經(jīng)驗，他的網(wǎng)頁是：
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
應(yīng)該改成
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client

轉(zhuǎn)載于:https://www.cnblogs.com/cxjchen/archive/2013/04/28/3048435.html