蓝盟IT小贴士，来喽！
在存储系统中，网络文件系统(nfs )是一个重要概念，它是遵守POSIX语义的分布式文件系统的基础。 这样可以在多台主机之间共享共同的文件系统，提供数据共享的好处，并最大限度地减少存储需求。 本论文通过分析NFS文件锁定状态视图的一致性原理，有助于理解NFS的一致性设定修正构想。
文房锁
文件锁是文件系统的最基本功能之一，应用程序可以使用文件锁来控制其他应用程序对文件的并发访问。 NFS作为UNIX系统的标准网络文件系统，在发展过程中支持分阶段文件锁定(从NFSv4开始)。 从上个世界80年代诞生到现在，NFS发表了NFSv2、NFSv3、NFSv4三个版本。
NFSv4的最大变化是“状态”。 有些操作要求服务方保持相关状态。 例如，如果客户端申请了文件锁定，则服务端需要维持该文件锁定的状态NFSv3需要NLM的协作才能实现文件锁定功能，但如果两者的协作不够，则可能容易发生错误。 NFSv4被修改为状态协议，可以自己实现文件锁定功能，也不需要NLM协议。
EOS原理
文件锁定不是典型的幂等操作，文件锁定操作的重试和Failover会导致文件锁定状态视图在客户端和服务端之间发生冲突。 NFSv4使用SeqId机制，对最多执行1次的机制进行了设定、修订。 具体方法如下
对于每个open/lock状态，客户端和服务器同时独立地维持seqid，客户端在开始引起状态变化的操作时(open/close/lock/unlock/release _ lockownnt
如果R==L 1，则表示合法的请求，正常处理。
如果R==L，则表示重试请求，服务器可以返回缓存reply。
其他情况都是不正当的请求，绝对拒绝访问。
根据以上规则，服务器确定操作是否正常、重试或无效请求。
该方法确保每个文件锁定操作在服务端最多执行一次，解决RPC重试的重复执行问题，但仅这些是不够的。 例如，在发送了LOCK操作之后，调用线程中断，然后服务侧接受该LOCK操作并执行，由此，服务侧由客户端保持锁定，而在客户端由于中断而没有保持锁定，所以客户端和服务器客户端还必须协助处理异常场景，以确保最终文件锁定视图的一致性。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
