作者| QingStor 黄蒙

<center><font color=#00a971 size=5> 咱们为什么须要“网络文件协定”</font></center>

存储文件是大家日常工作生存中最常见的需要，随着文件数量和占用存储空间的回升，以及在肯定范畴内共享拜访文件的需要产生，咱们天然须要把存储文件的工作从单个计算机设备中剥离进去，作为一个独自的服务资源 (或物理硬件) 来对外提供存储性能，提供更大的容量的同时，为多个终端通过网络共享拜访。

这里提到的存储设备就是咱们常说的 NAS（Network Attached Storage：网络从属存储）。

<center> 常见 NAS 架构 </center>

而终端通过网络来共享拜访 NAS，须要规范的协定标准。NFS 就是其中最重要也是利用最宽泛的协定规范之一（其它风行的网络文件协定还有 SMB[1] 协定，后续会有专门的文章进行介绍，尽请期待）。明天咱们就来聊聊 NFS 协定。

<center><font color=#00a971 size=5> 一直倒退的 NFS</font></center>

<font color=#262626 size=3>1. 简略好用的无状态协定诞生 </font>

NFS 第一次呈现在咱们的视线中，是在 1985 年。NFS version2 作为 SunOS 2.0 的组件正式公布。所以在过后把它叫做“Sun 网络文件系统”可能更为贴切。另外，你没有看错，第一个正式对外公布的版本就是 v2 版本（v1 版本从未对外正式公布，这也是咱们从不探讨 NFS v1 的起因）。

不过 NFS 并不是最早的网络文件系统，彼时曾经有一些更早的网络文件系统存在，比方 UNIX SVR3 零碎中蕴含的 RFS(Remote File System)[2] RFS 曾经引入了 RPC（Remote Procedure Call）概念，并成为 NFS v2 的借鉴的范本。但 RFS 也有本人显著的问题，比方其为每个客户端关上文件记录状态（即有状态协定），所以很难应答服务端宕机或重启的状况。NFS v2 为了在设计层面很好的解决 RFS 的缺点，设计成了一个齐全无状态的协定。

1995 年，NFS v3 正式公布。此时 NFS 协定的开发曾经不再齐全依赖 Sun 公司，而是多家公司独特主导实现. NFS v3 蕴含泛滥优化，但大多数能够认为是性能层面的优化。总体看来，NFS v3 依然遵循无状态协定的设计。

无状态协定的设计，天然是升高了应答服务端宕机重启状况的解决难度。但想要彻底挣脱“有状态信息”的解放并不容易。比方，作为网络文件协定，就须要反对“文件锁”操作，但锁信息人造就是一种“状态信息”。所以在 NFS v2/v3 运行的环境中，NFS 将这部分累赘“外包给”了 NLM（Network Lock Manager）。当 NFS Client 接管到一个文件锁申请时，会产生一个 NLM 协定的 RPC 调用，而不是产生一个 NFS 协定的 RPC 调用。但这样 NLM 就成为了一个“有状态”协定。所以它须要解决呈现服务端解体、客户端解体、网络分区呈现后的故障复原问题。NFS v2/v3 协定与 NLM 的配合工作总体来说不够协调（比方 NLM 协定自身会标记和辨认每把锁由哪个过程申请和持有，但 NFS server 解决读写申请时，却无奈辨别申请来自于哪个远端过程），这也导致了难以完满的实现锁逻辑。

即使抛开文件锁的问题不谈，无状态协定设计自身也带来了新的问题。NFS 服务作为“无状态服务”，无奈记录各个 NFS 协定客户端关上文件的状态，也就没有简略间接的方法判断文件内容是否曾经被其它客户端批改，即 cache 是否还无效。在 NFS v2/v3 协定中，NFS 协定客户端通常将文件的批改工夫和文件大小保留在 cache 详细信息中，以一个工夫距离，定期对 cache 进行有效性验证：NFS 协定客户端获取以后的文件属性，和 cache 中的批改工夫及文件大小做比拟，如果仍统一，则假设文件没有批改过，cache 依然无效；如果不匹配，则认为文件产生了了变动，cahce 不再无效。这样的形式显然是低效的。而更不侥幸的是，因为很多文件系统保留工夫戳的精度有余，NFS 协定客户端无奈探测出那些在一个较粗精度的工夫单位（秒）中间断的批改，比方刚校验过 cache 有效性后，同一秒内又产生了更改（笼罩写），那么从批改工夫和文件大小都察看不出须要从新更新 cache。这种状况下，只有该 cache 被 lru 驱赶，或者文件后续被再次批改，否则 NFS 协定客户端无奈感知到文件的最新变动。

<font color=#262626 size=3>2. 无状态到有状态，进化为成熟单机网络文件系统 </font>

2002 年 NFS v4.0 版本公布。此时 NFS 协定的开发齐全由 IETF 主导，最大的一个变动就是 NFS 协定的设计从无状态协定变为有状态协定。

从无状态协定再次演变为有状态协定，并不是谋求一种 old fasion，而是因为以后曾经具备了更好的工程能力，来设计开发出足以应答有状态协定设计下简单问题的机制（当然，这背地的能源显然也是拜长年忍耐无状态设计中的种种缺点之苦所赐）。

NFS v4.0 的有状态设计次要体现在如下几个方面：

<font color=#00a971 size=3>a.</font> 协定本身退出了文件锁性能，会保护锁信息这样的状态信息，不须要 NLM 帮助。

<font color=#00a971 size=3>b.</font> 在 cache 一致性问题的解决上，NFSv4 反对了 delegation 机制。因为多个客户端能够挂载同一个文件系统，为了放弃文件同步，NFSv4 能够依附 delegation 实现文件同步。当客户端 A 关上一个文件时，NFS 服务端会调配给客户端 A 一个 delegation。只有客户端 A 持有 delegation，就能够认为与服务端放弃了统一，能够释怀的的在 NFS 协定客户端侧做缓存等解决。如果另外一个客户端 B 拜访同一个文件，则服务端会暂缓解决（即短暂阻塞）客户端 B 的拜访申请，并向客户端 A 发送 RECALL 申请。当客户端 A 接管到 RECALL 申请后，会将本地缓存刷新到服务端中，而后将 delegation 归还给服务端，这时服务端开始持续解决客户端 B 的申请。

当然，delegation 机制仅能了解为在思考缓存一致性的状况，以一种更加激进的形式进行读写解决，所以该机制更应该被了解为是一种性能效率优化，而不是齐全解决 cache 一致性问题的计划，因为当 NFS 服务端发现多个客户端对同一文件的竞争呈现，并回收之前发放的受权后，又会回退到跟 v2/v3 版本中类似的机制去判断 cache 的有效性。
除了上述两点，v4.0 版本相较之前的版本还有以下优化：
<font color=#00a971 size=3>a.</font> NFSv4 减少了安全性设计，开始反对 RPC SEC-GSS[3] 身份认证。
<font color=#00a971 size=3>b.</font> NFSv4 只提供了两个申请 NULL 和 COMPOUND，所有的操作都整合进了 COMPOUND 中，客户端能够依据理论申请将多个操作封装到一个 COMPOUND 申请中，减少了灵活性的同时缩小了交互次数，大大提高了性能。
<font color=#00a971 size=3>c.</font>NFSv4 版本中批改了文件属性的示意办法，显著加强对 Windows 零碎的兼容性，而简直同时，微软开始把 SMB 协定重塑成 CIFS（Common Internet FileSystem），这看起来绝非偶合，可见两者的竞争象征。
通过下面这些改良，能够说 NFS 曾经进化成为了成熟高效的单机网络文件系统，然而软件的世界曾经缓缓向文件系统提出了更多扩展性的需要和更多的企业级个性需要，NFS v4.0 版本对此还未给出答案。

<font color=#262626 size=3>3. 具备更强扩展性，企业级集群文件系统雏形已现 </font>

2010 年及 2016 年, NFS v4 的演进版本 v4.1 和 v4.2 陆续公布。

2010 年，NFS v4.1 的问世，让 NFS 向集群文件系统的方向迈出了重要一步 — 因为其引入了并行文件系统的概念（Parallel NFS/pNFS）：即在协定层面将元数据与数据拆散，发明出元数据节点和数据节点的角色，对数据的拜访具备了肯定扩展性。并行拜访数据的设计也让整体吞吐晋升到新的高度，这与很多古代分布式文件系统思路类似。

但须要指出的是，在此设计中，元数据的解决扩展性仍未失去解决。另外作为有状态协定，在用来保障高可用性的主备架构中，因为备节点中并没有主节点中保护的状态信息，所以故障切换过程很难做到足够平滑。

<center>Parallel NFS 根本架构图 </center>

除此之外，NFS 协定开始退出了更多的数据中心级企业级个性：

NFSv4.1 开始反对 RDMA（Remote Direct Memory Access）[4]，并在 NFS v4.2 中开始反对稠密文件（sparse file）以及反对 server 侧拷贝（Server-Side Copy）。

这都帮忙 NFS 协定能够更好地撑持更加庄重的数据中心 / 企业级利用。

<font color=#262626 size=3>4. NFS 的持续进化和工程层面的摸索：内核态 vs 用户态 </font>

NFS 协定一直的倒退，在复杂性一直进步的同时，也在集群扩展性 / 可用性方面一直摸索，但这无疑也给工程实现层面提出了新的挑战。在 Linux 世界中，最常应用的就是内核态的 nfsd 服务，然而随着机制和架构的复杂性的减少，在用户态去实现一个 NFS 服务仿佛成为了一个工程更正当的计划。作为 NFS 在 Linux 世界中的竞争对手，Samba[5] 服务就是基于用户态打造了一套较为残缺的集群计划。

针对这一问题，开源社区也给出了一些摸索，其中最具影响力同时也是利用最宽泛的要数 nfs-ganesha[6] 我的项目，该我的项目目前由 RedHat 保护，其在用户态实现了残缺的 NFS 服务性能。

<center>NFS Ganesha 架构图 </center>

如图 nfs-ganesha 架构图所示，该我的项目自身专一于协定解决逻辑（反对所有的 NFS 协定版本），同时设计独立的 SAL（State abstraction layer）形象层，和 FSAL（File-System abstraction layer）形象层。前者有助于在解决有状态协定的“状态”时扩大一些集群逻辑，而后者不便接入包含本地 VFS 文件系统和各种开源 / 商业分布式存储。这样的设计有利于借助内部中间件和服务来打造更好的集群逻辑，为更多开放性的设计提供了空间，同时也通过对接更多的后端存储系统来保障社区生机和扩充利用范畴。

在将来相当长的一段时间里，NFS 协定仍会承当重要的角色，而 NFS 的工程实际想要进一步取得倒退，满足日渐收缩及简单的需要，仍须要在用户态持续摸索。

<center><font color=#00a971 size=5> 结束语 </font></center>

NFS 协定不然而咱们平时共享文件的背地功臣，也在超算和广电等行业撑持着各类外围业务。
作为一个有多年历史的网络文件协定，NFS 有其历史局限性，甚至每次迭代都有其惨重的历史包袱捆绑手脚，但它仍能够被当作文件系统的经典范例去钻研。能够说对 NFS 协定理解逐渐深刻的过程，也是对古代分布式文件系统从新了解的过程。

参考资料

1 . Why NFS Sucks (Olaf KirchSUSE/Novell, Inc)

https://www.kernel.org/doc/ol…

2.Review of “Why NFS Sucks” Paper from the 2006 Linux Symposium

http://nfsworld.blogspot.com/…

3.NFS and file locking

https://docstore.mik.ua/orell…

4.. NFS 各个版本之间的比拟（ycnian）

https://blog.csdn.net/ycnian/…

5.. NFS Ganesha Architecture
https://github.com/nfs-ganesh…

援用链接

[1] SMB https://en.wikipedia.org/wiki…

[2] RFS (Remote File System) https://en.wikipedia.org/wiki…

[3] RPC SEC-GSS https://en.wikipedia.org/wiki…

[4] RDMA https://en.wikipedia.org/wiki…

[5] Samba https://en.wikipedia.org/wiki…

[6] nfs-ganesha https://github.com/nfs-ganesh…

本文由博客一文多发平台 OpenWrite 公布！