nfsv3和nfsv4的区别,NFSv3
红帽系统snmp服务放在哪个目录下
红帽系统snmp服务放在取决于你使用的是哪个Linux发行版，通常在/etc/rc.d。
Linux的系统文件放在/bin、/sbin和/usr目录下。/bin是比较重要的系统二进制文件，都可以在单用户模式下执行，cat和ls命令都在这里。
/usr命令包含所有系统类的命令和函数库，/sbin命令包含的是只能用root用户才能执行的命令。这三个目录都是只有root用户才有写入权限。
红帽系统snmp服务高效率、可扩展性和可靠性：
红帽企业版Linux 6支持更多的插座、内核、线程和内存空间。文件系统任务安排时间表的编排上更注重任务的运行时间、任务的轻重缓急等因素的综合考虑，利用硬件响应和多核拓扑结构优化系统任务的执行和资源分配。
红帽企业版Linux 6的文件系统默认是ext4（第四扩展文件系统），该版本更加健壮、规模可以拓展到16TB,还包含了可升级到100TB的XFS文件系统。其NFSv4 显着改进了NFSv3的不足，并且是向后兼容的。
nfs:server is not responding,still trying的解决办法
系统 ：centos7.9
nfs版本：nfsstat: 1.3.0
rpcbind版本：rpcbind：0.2.0
查看message日志发现nfs 客户连接端报如下错误
问题原因：
Mandag 27 november 2006 20:12 skrev Verner Kj?rsgaard:
NFS协议到现在经历了V1、V2、V3、V4四个版本，但是它有一个缺点就是协议没有用户认证机制，而且数据在网络上传送的时候是明文传送，所以安全性极差，一般只能在局域网中使用。
NFSv3是1995年发布的，相比NFSv3，NFSv4发生了比较大的变化，最大的变化是NFSv4有状态了。NFSv2和NFSv3都是无状态协议，服务端不需要维护客户端的状态信息。无状态协议的一个优点在于灾难恢复，当服务器出现问题后，客户端只需要重复发送失败请求就可以了，直到收到服务端的响应信息。但是某些操作必须需要状态，如文件锁。如果客户端申请了文件锁，但是服务端重启了，由于NFSv3无状态，客户端再执行锁操作可能就会出错了。NFSv3需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调。NFSv4设计成了一种有状态的协议，自身实现了文件锁功能，就不需要NLM协议了。
后来的 NFSv4.1
与NFSv4.0相比，NFSv4.1最大的变化是支持并行存储了。在以前的协议中，客户端直接与服务器连接，客户端直接将数据传输到服务器中。当客户端数量较少时这种方式没有问题，但是如果大量的客户端要访问数据时，NFS服务器很快就会成为一个瓶颈，抑制了系统的性能。NFSv4.1支持并行存储，服务器由一台元数据服务器(MDS)和多台数据服务器(DS)构成，元数据服务器只管理文件在磁盘中的布局，数据传输在客户端和数据服务器之间直接进行。由于系统中包含多台数据服务器，因此数据可以以并行方式访问，系统吞吐量迅速提升。现在新的是nfsv4.2
所以尽可能用nfs4
补充：
nfs4挂载的fsid问题
问题现象：
挂载nfs4时，报错：reason given by server :No such file or directory
背景知识：
NFSv4将所有共享使用一个虚拟文件系统展示给客户端。伪文件系统根目录(/)使用fsid=0标示，只有一个共享可以是fsid=0。客户端需要使用“nfs server ip:/”挂载伪文件系统，伪文件系统一般使用RO方式共享，其他共享可以通过mount –bind选项在伪文件系统目录下挂载。客户端挂载过程需要通过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配置参数选项说明：
ro：共享目录只读；
rw：共享目录可读可写；
all_squash：所有访问用户都映射为匿名用户或用户组；
no_all_squash（默认）：访问用户先与本机用户匹配，匹配失败后再映射为匿名用户或用户组；
root_squash（默认）：将来访的root用户映射为匿名用户或用户组；
no_root_squash：来访的root用户保持root帐号权限；
anonuid=UID：指定匿名访问用户的本地用户UID，默认为nfsnobody（65534）；
anongid=GID：指定匿名访问用户的本地用户组GID，默认为nfsnobody（65534）；
secure（默认）：限制客户端只能从小于1024的tcp/ip端口连接服务器；
insecure：允许客户端从大于1024的tcp/ip端口连接服务器；
sync：将数据同步写入内存缓冲区与磁盘中，效率低，但可以保证数据的一致性；
async：将数据先保存在内存缓冲区中，必要时才写入磁盘；
wdelay（默认）：检查是否有相关的写操作，如果有则将这些写操作一起执行，这样可以提高效率；
no_wdelay：若有写操作则立即执行，应与sync配合使用；
subtree_check（默认） ：若输出目录是一个子目录，则nfs服务器将检查其父目录的权限；
no_subtree_check ：即使输出目录是一个子目录，nfs服务器也不检查其父目录的权限，这样可以提高效率；
Troubleshooting
1、在上面的操作过程中，如果你不幸遇到下面这个问题的话，可以尝试更新 Linux kernel 或通过打开 IPv6 来解决这个问题，这是1个 bug：
mount.nfs4: Cannot allocate memory
2、如果遇到如下问题，可能是因为你的 mount -t nfs 使用的是 nfsv3 协议，需要明确指出使用 nfsv4 协议挂载 mount -t nfs4：
mount: mount to NFS server '172.16.20.1' failed: RPC Error: Program not registered.
如果网络不稳定
NFS默认是用UDP协议，换成TCP协议挂载即可：
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共享文件时出现下面的错误提示
nfs:server is not responding,still trying 原因分析： NFS 的默认传输协议是 UDP，而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。
解决方法：在客户端改用TCP协议，使用下面的命令， **#mount -o tcp 10.10.19.25:/home/export /mnt/local
方法2：** 在目标板上通过NFS复制PC机上较大文件到目标板上的时候遇到的问题：
nfs: server *** not responding, still trying
修改方法：
nfs mount时候出现的NFS崩溃，按照以下的方式mount
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client
附 问题四：在测试时，“./progressbar -qws”后出现如Q3一样的提示 ，按Q3来处理。
以上参考了一些 “ 快乐的天空”的经验，他的网页是：
他的
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /host
应该改成
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client
在不使用nfs情况下,怎么保证2台服务器wen网站一致性
客户端建立新链接时初始xid采用随机值。服务端DRC额外记录请求校验信息，缓存命中时同时校验这些信息。
需要服务端维持相关状态，如文件锁，例如客户端申请了文件锁，服务端就需要维护该文件锁的状态，否则和其他客户端冲突的访问就无法检测。如果是NFSv3就需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调就会容易出错。而NFSv4设计成了一种有状态的协议，自身就可以实现文件锁功能，也就不需要NLM协议了。
客户端使用int32_t类型的xid标识上层使用者发起的每个远程过程调用过程，每个远程过程调用的多次RPC重试使用相同的xid标识，这样就保障了多次RPC重试中任何一个返回都可以告知上层远程过程调用已经成功，保证了服务端执行远程过程调用执行耗时较长时也能拿到结果，这和传统的netty/mina/brpc等都需要每个RPC都要有独立的xid/packetid不同。
网络文件系统（NFS）是否就是文件/打印机共享
NFS server可以看作是一个FILE SERVER,它可以让你的PC通过网络将远端得NFS SERVER共享出来的档案MOUNT到自己的系统中，在CLIENT看来使用NFS的远端文件就象是在使用本地文件一样。
NFS协议从诞生到现在为止，已经有多个版本，如NFS V2（rfc1094）,NFS V3（rfc1813）（最新的版本是V4（rfc3010）。
二、各NFS协议版本的主要区别
V3相对V2的主要区别：
1、文件尺寸
V2最大只支持32BIT的文件大小(4G),而NFS V3新增加了支持64BIT文件大小的技术。
2、文件传输尺寸
V3没有限定传输尺寸，V2最多只能设定为8k，可以使用-rsize and -wsize 来进行设定。
3、完整的信息返回
V3增加和完善了许多错误和成功信息的返回，对于服务器的设置和管理能带来很大好处。
4、增加了对TCP传输协议的支持
V2只提供了对UDP协议的支持，在一些高要求的网络环境中有很大限制，V3增加了对TCP协议的支持
*5、异步写入特性
6、改进了SERVER的mount性能
7、有更好的I/O WRITES 性能。
9、更强网络运行效能，使得网络运作更为有效。
10、更强的灾难恢复功能
nfs链接别名
20世纪80年代初，一家神奇的公司在硅谷诞生了，它就是Sun Microsystems。这个名字与太阳无关，而是源自互联网的伊甸园—Stanford University Network的首字母。在不到30年的时间里，SUN公司创造了无数传世作品。其中，Java、Solaris和基于SPARC的服务器至今还闻名遐迩。后来，人们总结SUN公司衰落的原因时，有一条竟然是技术过剩。
Network File System（NFS）协议也是SUN公司设计的。顾名思义，NFS就是网络上的文件系统。它的应用场景如图1所示，NFS服务器提供了/code和/document两个共享目录，分别被挂载到多台客户端的本地目录上。当用户在这些本地目录读写文件时，实际是不知不觉地在NFS服务器上读写。
?
图1
NFS自1984年面世以来，已经流行30年。理论上它适用于任何操作系统，不过因为种种原因，一般只在Linux/UNIX环境中存在。我在很多数据中心见到过NFS应用，其中不乏通信、银行和电视台等大型机构。无论SUN的命运如何 多舛，NFS始终处乱不惊，这么多年来只出过3个版本，即1984年的NFSv2、1995年的NFSv3和2000年的NFSv4。目前，大多数NFS环境都还是NFSv3，本文介绍的也是这个版本。NFSv2还在极少数环境中运行（我只在日本见到过），可以想象这些环境有多老了。而NFSv4因为深受CIFS影响，实施过程相对复杂，所以普及速度较慢。
如何深入学习NFS协议呢？其实所有权威资料都可以在RFC 1813中找到，不过这些文档读起来就像面对一张冷冰冰的面孔，令人望而却步。《鸟哥的Linux私房菜》中对NFS的介绍虽称得上友好，但美中不足的是不够深入，出了问题也不知道如何排查。我曾经为此颇感苦恼，因为工作中碰到的NFS问题太多了，走投无路时就只能硬啃RFC—既然网络协议都那么复杂，我也不指望有捷径了。直到有一天偶然打开挂载时抓的包，才意识到Wireshark可以改变这一切：它使整个挂载过程一目了然，所有细节都一览无遗。分析完每个网络包，再回顾RFC 1813便完全不觉得陌生。