Posted on 2009-04-11 12:36
Prayer 閱讀(2332)
評(píng)論(3) 編輯 收藏 引用 所屬分類:
LINUX/UNIX/AIX
檢查一下主機(jī)的NFS服務(wù)是否正常工作，可以重啟一下nfs服務(wù)：sudo /etc/init.d/portmap restart
要是還不行的話，重新安裝一遍nfs服務(wù)試試
在移植cs89x0后，就一直碰到如下這個(gè)問題：
nfs: server 192.168.10.1 not responding
nfs: server 192.168.10.1 not responding
nfs: server 192.168.10.1 OK
……
嵌入式系統(tǒng)要經(jīng)過很多次很長(zhǎng)時(shí)間的嘗試才能掛上。初步懷疑是NFS配置的問題，后來猜測(cè)可能是由于cs8900a丟包嚴(yán)重造成的。
在nfs faq找到：
kernel: nfs: server server.domain.name not responding, still trying
kernel: nfs: task 10754 can't get a request slot
kernel: nfs: server server.domain.name OK
A. The "can't get a request slot" message means that the client-side RPC code has detected a lot of timeouts (perhaps due to network congestion, perhaps due to an overloaded server), and is throttling back the number of concurrent outstanding requests in an attempt to lighten the load. Some possible causes:
* Network congestion
* Overloaded server
* Packets (input or output) dropped by a bad NIC or driver....
根據(jù)上述觀點(diǎn)，造成NFS沒有回應(yīng)的原因有3個(gè)，分別為網(wǎng)絡(luò)擁塞、服務(wù)器過載和網(wǎng)卡丟包。
在我們的實(shí)驗(yàn)系統(tǒng)中，嵌入式系統(tǒng)和宿主機(jī)是直連的，而且服務(wù)器的基本處于空載的情形，所以不應(yīng)該是前面兩種情況，所以很可能是嵌入式系統(tǒng)網(wǎng)卡丟包嚴(yán)重引起的。
在目標(biāo)機(jī)器中，用ifconfig看了一下，確實(shí)丟包比較嚴(yán)重。很可能就是這個(gè)問題了。
另一個(gè)意外的發(fā)現(xiàn)是，在查詢丟包是，用tcpdump觀察到nfs使用的是UDP協(xié)議。于是猜想，用TCP會(huì)不會(huì)有所改善？
接著就是另一個(gè)問題，如何在nfs作為根文件系統(tǒng)時(shí)，指定nfs掛載的參數(shù)？
帶著問題，跟蹤了fs/nfs/nfsroot.c的代碼，發(fā)現(xiàn)在nfs作為根文件系統(tǒng)時(shí)，參數(shù)可以直接寫在“nfsroot=”后面，每個(gè)參數(shù)用逗號(hào)隔開，如：
nfsroot=192.168.10.1:/rootfs,proto=tcp,nfsvers=3,nolock
這樣就可以指定nfs使用tcp協(xié)議。
重啟后發(fā)現(xiàn)，竟然不再出現(xiàn)not responding的錯(cuò)誤，一切感覺較為正常。
不過，cs8900a丟包現(xiàn)象依然存在。所以，使用tcp只是一個(gè)可行的解決辦法，但最終還得解決網(wǎng)卡的丟包問題。
我在arm上通過NFS共享文件時(shí)出現(xiàn)下面的錯(cuò)誤提示
nfs:server is not responding,still trying
原因分析：NFS 的默認(rèn)傳輸協(xié)議是 UDP，而PC機(jī)與嵌入式系統(tǒng)通過UPD交互時(shí)就會(huì)出現(xiàn)嚴(yán)重的網(wǎng)卡丟包現(xiàn)象。
解決方法：在客戶端改用TCP協(xié)議，使用下面的命令，
#mount -t nfs -o nolock -o tcp 192.168.1.161:/opt /opt
問題三 NFS:server not responing ,still trying
文章出處：http://www.diybl.com/course/6_system/linux/Linuxjs/2008716/133207.html
在目標(biāo)板上通過NFS復(fù)制PC機(jī)上較大文件到目標(biāo)板上的時(shí)候遇到的問題：
nfs: server *** not responding, still trying
修改方法：
nfs mount時(shí)候出現(xiàn)的NFS崩潰，按照以下的方式mount
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client
問題原因：
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機(jī)和目標(biāo)機(jī)網(wǎng)卡傳輸速率沖突，使得目標(biāo)機(jī)需要大量時(shí)間復(fù)制大量數(shù)據(jù)包，其實(shí)如果目標(biāo)機(jī)的網(wǎng)卡速率夠大，則不用分那么多包，也不會(huì)沖突。
附 問題四：在測(cè)試時(shí)，“./progressbar -qws”后出現(xiàn)如Q3一樣的提示 ，按Q3來處理。
以上參考了一些 “ 快樂的天空”的經(jīng)驗(yàn)，他的網(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
文章出處：http://www.diybl.com/course/6_system/linux/Linuxjs/2008716/133207.html