NFS: server is not responding, still trying reason and Solution

Note: The following methods are reprinted. I have adopted a combination of methods.

Mount-T nfs-O intr, nolock, rsize = 4096, wsize = 4096-o tcp 192.168.1.3:/root/somedir/Host

 

 

NFS: server is not responding, still trying SolutionMethod 1:
The following error message is displayed when I share files through NFS on the arm.
NFS: server is not responding, still trying

Cause analysis: the default NFS transmission protocol is UDP, and serious Nic packet loss occurs when the PC interacts with the embedded system through UPD.

Solution: switch to the TCP protocol on the client and use the following command,
# Mount-o tcp 10.10.19.25:/home/export/mnt/local

Method 2:
Problems encountered when copying large files on the PC to the target board through NFS on the target board:
NFS: Server *** not responding, still trying

Modification method:
NFS crashes during NFS mount. Mount the NFS as follows:
Mount-T nfs-O intr, nolock, rsize = 1024, wsize = 1024 192.168.1.3/root/somedir/client

cause:
Mandag 27 November 2006 skrev Verner kJ limit rsgaard:
Mandag 27 November 2006 skrev John P. new:
>> Verner,
>>< br> This is a problem with NFS and 2.6 kernels, fast server restart and
comparatively slower client restart. this will show up when the server has
A 1000 MB card and the client a 100 MB, or when the server has a 100 MB
card and the client a 10 MB.
essential, 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.
// Note: The reason is that the transmission rate of the NIC of the server and the target machine conflicts, so that the target machine needs to copy a large number of data packets in a large amount of time. In fact, if the NIC speed of the target machine is large enough, no need If there are so many packets, there will be no conflict.

Appendix 4: During the test, "./progressbar-qws" prompts the same as Q3, which should be handled by Q3.
the above references some "happy sky" experience, his webpage is:
http://blog.chinaunix.net/u2/67519/showart_677885.html
His
Mount-T nfs-O intr, nolock, rsize = 1024, wsize = 1024 192.168.1.3/root/somedir/host
should be changed to
Mount-T nfs-O intr, nolock, rsize = 1024, wsize = 1024 192.168.1.3/root/somedir/client