最近在学习飞凌嵌入式的OK6410 开发板，搭建环境的时候考虑到开发板和主机(Ubuntu)之间的文件共享，除了U盘拷贝或者FTP之外，还有一种网络文件夹的方式。所以着手开始在主机上搭建主机NFS服务器。大致了解下NFS服务的原理，当然不是很深入，因为基础太差，所以能够了解配置文件即可，后期有时间再来深入。
1 sudo apt-get install nfs-kernel-server portmap
修改/etc/exports 配置文件，设定访问用户和权限，以及NFS的文件路径。
1 /home/cat/nfs_root *(rw,sync,no_root_squash)
然后重启NFS 服务即可
sudo /etc/init.d/nfs-kernel-server restart
之后即可在OK6410 上挂载该文件系统
1 mount -t nfs -o nolock 10.11.52.249:/home/cat/nfs_root /tmp
过程中需要注意的是文件的权限和所有组之间的关系.需要一定Linux基础的人才能搞得清楚，详见鸟哥的Linux私房菜<服务器架设篇> <基础学习篇>
另外，在使用的过程中发现，以上述方式挂后，OK6410 操作在宿主机上删除文件和写文件都没有问题，但是从宿主机copy 文件就会有问题，会一直提示：
server is not responding, still trying
百度了一下，这是由于宿主机与OK6110的网卡速率不匹配造成的，需要以如下方式挂载：
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.0.121:/主机nfs目录 /挂载路径
参考内容：
http://blog.csdn.net/do2jiang/article/details/4950613
1 ---nfs:server is not responding,still trying 原因与解决方案 2 ---本来还以为是nfs出了故障，但是google了一下发现原来不是nfs的原因，而是由于传送的数据太大，出现数据包丢失现象。 3 NFS 的默认传输协议是 UDP，而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。可用的解决方案是：在客户端改用TCP协议，使用下面的命令， 4 mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.0.121:/主机nfs目录 /挂载路径 5 注意：中间使用的是逗号，而非英文中的句号。 6 7 明显该命令没有指定 tcp协议 8 9 正确解决方法： 10 11 在移植cs89x0后，就一直碰到如下这个问题： 12 13 nfs: server 192.168.10.1 not responding 14 15 nfs: server 192.168.10.1 not responding 16 17 nfs: server 192.168.10.1 OK 18 19 20 21 嵌入式系统要经过很多次很长时间的尝试才能挂上。初步怀疑是NFS配置的问题，后来猜测可能是由于cs8900a丢包严重造成的。 22 23 在nfs faq找到： 24 25 kernel: nfs: server server.domain.name not responding, still trying 26 kernel: nfs: task 10754 can't get a request slot 27 kernel: nfs: server server.domain.name OK 28 29 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: 30 31 * Network congestion 32 * Overloaded server 33 * Packets (input or output) dropped by a bad NIC or driver.... 34 35 根据上述观点，造成NFS没有回应的原因有3个，分别为网络拥塞、服务器过载和网卡丢包。 36 37 在我们的实验系统中，嵌入式系统和宿主机是直连的，而且服务器的基本处于空载的情形，所以不应该是前面两种情况，所以很可能是嵌入式系统网卡丢包严重引起的。 38 39 在目标机器中，用ifconfig看了一下，确实丢包比较严重。很可能就是这个问题了。 40 41 另一个意外的发现是，在查询丢包是，用tcpdump观察到nfs使用的是UDP协议。于是猜想，用TCP会不会有所改善？ 42 43 接着就是另一个问题，如何在nfs作为根文件系统时，指定nfs挂载的参数？ 44 45 带着问题，跟踪了fs/nfs/nfsroot.c的代码，发现在nfs作为根文件系统时，参数可以直接写在“nfsroot=”后面，每个参数用逗号隔开，如： 46 47 mount -t nfs 192.168.10.1:/work/nfs /mnt/nfs -o nolock,proto=tcp,nfsvers=3 48 49 这样就可以指定nfs使用tcp协议。 50 51 重启后发现，竟然不再出现not responding的错误，一切感觉较为正常。 52 53 不过，cs8900a丢包现象依然存在。所以，使用tcp只是一个可行的解决办法，但最终还得解决网卡的丢包问题。