设置NFS中的问题汇总

某些ISA的以太网卡可能会引起一些问题,特别是在NFS上.这些困难在FreeBSD上并不特别明显,但系统可能会受影响.

这些问题几乎总是发生在以及联网的高性能工作站上,例如Sun公司的机器.NFS挂起将会工作非常好,一些操作也是成功的,但是突然server对client没有了响应,即使另外的系统请求继续被响应.这些问题通常在client系统上,无论client是FreeBSD或者是其它的工作站.许多系统上,一旦这个问题出现,系统将无法正常关闭.唯一的解决方法就是经常重置client,因为NFS的情况不能解决.

尽管这个"正确"的解决方法是对付运行FreeBSD的高性能工作站,但这也是一个简单的安全的方法.如果FreeBSD系统是server,client运行时要有参数-w=1024.如果FreeBSD是client,那么挂起NFS文件系统时,要有参数-r=1024.如果需要在client上自动挂起NFS,这些选择需要在fstab的第四个域中输入,或使用mount命令的-o参数手动挂起.

需要注意的是,在NFS server和client在不同的网络上时,这个问题也会出现.如果是这个原因,请确定你的路由器有必须支持UDP信息.下例中,fastws是高性能工作站的host名,freebox是一台有低效率网卡的FreeBSD系统.当然,/sharedfs将作为NFS文件系统,而在client上就是/project.在所用情况下,注意附加选项.

将freebox作为client:在/etc/fstab中输入

  1. fastws:/sharedfs /project nfs rw,-r=1024 0 0 

如果是手工挂起:

  1. # mount -t nfs -o -r=1024 fastws:/sharedfs /project 


将freebox作为server,在fastws的/etc/fstab中输入:

  1. freebox:/sharedfs /project nfs rw,-w=1024 0 0 

如果需要手工挂起:

  1. # mount -t nfs -o -w=1024 freebox:/sharedfs /project 

几乎任何16-bit以太网卡不需要以上的关于读写的限制.

对于细心的人,可能已经看出,何处出了这种错误,也就说明了此处为什么不可恢复正常的原因了.NFS是典型的每块8K的文件系统.(当然也可以优化成更小的).当最大的数据包在1500字节时,NFS的块被分成几个数据包,尽管它对于上层协议来说,还是一个独立的需要接收,确认并且组合的单元.高性能工作站能够从组成NFS单元的一个个紧接着的小包中还原这个包.在低效率的网卡中,后面的小包由于超时在与其在相同NFS单元中前面的小包到达目的地之前就会溢出,使用得整个单元不能被还原,并且不会发出确认信号.结果,工作站会超时,并且会重新再试一次,但是以8K一个单元,还是出现以上的错误,就这样永远休止.

使单元的大小小于数据包的尺寸限制,这样就可以确保信号会被接收,并且收到确认信号,从而避免以上局面.

当高性能服务器对一台配有高效的网卡的机器输入数据时,超时溢出仍会发生,但是这种超时溢出与以上所述的NFS的单元错误并不相同.当超时溢出发生时,受到影响的单元会被重传,而这次是它们被接收,确认,还原可能会成功.


相关内容

    暂无相关文章