LWN: NFS近期需求

NFS topics

By Jake Edge

May 14, 2019

LSFMM

在2019 Linux Storage, Filesstem, and Memory-Management Summit上，Trond Myklebust和Bruce Fields组织了一个NFS相关的讨论。Myklebust介绍了NFS和容器（container，例如Docker）的最新结合成果，还有NFS即将拥有的TLS支持。Fields也提到了一些容器相关的改动，还有不少其他信息。

Myklebust先介绍了NFS中RPC层的TLS支持。这里一个难点在于如何让RPC层调用user-space daemon（用户态守护程序）来实现TLS握手。只要握手成功了，kernel就能支持后续的TLS。还有去年基于Intel和Mellanox的代码，实现了TLS的硬件加速，而RPC就可以利用这部分代码，不过首先还是需要完成握手。

要实现握手，还是有几种可能方案的。可以像rpc.gssd一样来实现到user space的调用。这种需要有一个daemon守护进程来监听握手申请（handshake requests），等握手成功之后，会把这个connection（网络连接）交还给kernel来处理后续的RPC通讯数据。

另一个方案是利用netlink。这会更加通用，但是需要跟网络相关开发者来讨论实现了。他打算先看看他们感兴趣不，如果没兴趣的话，他还是回到rpc.gssd方案。毕竟这跟容器兼容的更好。

对Container容器来说，近来有不少patch都进入kernel了。还有不少都在Fields和Anna Schumaker的kernel分支里排队等待合入主干分支。后续一个主要问题是如何处理用户的各自命名空间（user namespaces）。可以有两个问题，首先是NFSv4 ID mapper (rpc.idmapd)一直在用keyring upcall interface，根本不支持user namespaces。有rpc.idmapd在运行的user namespace里，Kernel还没法把kernel user ID (kuid)对应到user ID。现在已经有patch在实现这部分功能了。

还有个问题是网络上传输的究竟是哪个ID。使用NFSv3或者部分的NFSv4配置场景下，原始的user和group ID直接被client发送给server。是不是应该用对应的container里的user/group ID？确实，合理方案是使用相应的namespace里的ID，毕竟没有道理隐藏，也不应该用一个相应的container看不懂的ID。

Fields问Myklebust是否还了解其他的container相关的NFS缺陷？还有一个，是在container系统力DNS域名查找相关的。因为这里也用了keyring upcall interface。这个属于该fix的一个bug，不过不急，毕竟用到的情况不多。

每个container里面，NFSv4的状态都应该是独立、不相干的。那么用户都不应该用相同的client ID。Myklebust指出，很多container系统根本没有制定一个hostname，所以软件有时候不容易决定在跟NFS server交互时该用哪个ID。他在实现一个更加通用的创建ID的方式，这样其他文件系统也能用这个方法来获取ID，而不是非要依赖NFS特有的daemon。

Chuck Lever问他是不是指"clientid4"（这是NFSv4协议的一部分）。Myklebust确认了。他已经利用udev调用进container namespace，不过patch还没有发布出来。包括非container的NFS客户端也会用这个方案，因为很多 Linux 发行版都没有强制要求设定hostname，这样导致server会看到很多“localhost.localdomain"这样的客户端，很不利于规范化操作。这个patch还在修改，估计Linux 5.3里面可能会包含。

接下来，Fields走上主讲台。他介绍了这么一种场景：有时候服务器需要记录一些client的状态，这样服务器重启之后，这些client还能获取到它们之前拥有的锁。不过在container里面，现有的这套机制失灵了，开发者正在修复。这个改动部分在kernel里，部分在user-space，所以还会需要一些时间实现最终版本。

他比较担心一个问题，duplicate reply cache对server来说是一个全局数据，也就是说所有的container都公用的数据。这样有恶意客户端的话，很可能能够窃取到这个cache的内容。还有他也担心这里很容易出bug，因为客户端有可能取到错误的cache entry。他建议要么针对每个client创建独立的cache，要么对每个cache entry利用network namespace来标记区分，这样就能解决这个问题。

Lever问，server跟container结合之后，性能如何？Fields说这个不太重要，有一些性能指标是大家都关心的，更多的指标是只有特殊人群关心的。只要更多人开始在container里使用NFS，那么很快就会有更多的corner case需要处理。

Server-to-server copy offload也是现在在做的一件工作。这组patch提出来的时候，Dave Chinner注意到VFS层和文件系统里都有一些问题。Chinner发出了一些patch来解决这部分问题，不过没有继续推进下去，可能是因为没有太多时间。Fields认为需要有志愿者能接手继续推进到upstream上。

下一步提到了delegation，这个机制可以让server授予一个client对某个文件的独有的读写权限。多个client可以共同拥有对一个文件的read delegation，不过只要某个client用write模式打开这个文件，server就需要把素有的read delegation都收回。这时如果还剩一个client拥有read delegation，并且也是它在写这个文件，那么就没有必要收回这个delegation授权。

这里的实现方式需要在VFS层记录client ID。不过在VFS层完全处理是不现实的。后来人们尝试在task structure里面记录一些信息，不过其他开发者觉得这样不太好。最近一次尝试是利用thread-group ID (tgid)，实现方法是修改kernel thread daemon (kthreadd)这样NFS daemon就能有一份私有的进程组，把它的所有进程都归并入这个进程组里。看起来没人介意这个方案，不过他还没有找到合适的reviewer。

Steve French觉得是不是可以让NFS协议支持更多文件属性（file attributes），就像statx()系统调用里已经实现的那么多属性。其中有一些文件属性是internet场景所用，例如archive bit。而其他的例如birth time就早就在规范定义好了，Myklebust说可以加入Linux NFS实现里面去。

Ted Ts'o提问关于大小写无关的文件名的问题。近期ext4已经有这个能力了。他想知道NFS这边需要做些改动来支持这个功能吗？Myklebust回答道，NFS client和NFS server都需要修改才能支持。他会等ext4的改动合入之后（峰会之后，这部分代码已经合入Linux v5.2 prepatch），再来看NFS具体需要做什么工作。至少需要修改文件名查找代码，以及directory entry cache (dcach)。