vNFS：运用复合和矢量化I/O优化存储性能的NFSv4.1兼容客户端

ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月vNFS：使用复合和矢量化I/OMing Chen和GEETIKA BABU BANGERA，石溪大学Dean Hildebrand，IBM研究-AlmadenFARHAAN JALIA，石溪大学GEOFF KUENNING，Harvey Mudd学院HENRY NELSON，Ward Melville高中EREZ ZADOK，石溪大学现代系统广泛地使用网络，通过本地和远程网络访问服务和存储延迟是一个关键的性能挑战，将多个小操作打包到更少的大操作中是摊销成本的有效方法，特别是在带宽而不是延迟方面有了多年的显着改善之后为此，NFSv4协议支持复合功能以组合多个操作。然而，复合自其概念以来一直没有得到充分的使用，因为同步POSIX文件系统API每次只发出一个（小）请求。我们提出了vNFS，一个NFSv4.1兼容的客户端，公开了一个矢量化的高级API，并利用NFS复合过程，以最大限度地提高性能。我们将vNFS设计并实现为一个用户空间RPC库，它支持对多个文件和目录进行批量操作。我们发现很容易修改多个UNIX实用程序、HTTP/2服务器和Filebench以使用vNFS。我们在各种工作负载和网络延迟条件下评估了vNFS，结果表明，即使对于低延迟网络，vNFS也能提高性能。在高延迟网络上，vNFS可以将性能提高两个数量级。CCS概念：·信息系统→信息存储系统;存储体系结构;网络附加存储;·网络→网络协议;网络文件系统（NFS）协议;其他关键词和短语：NFS，vNFS，复合过程，POSIX，文件系统APIACM参考格式：Ming Chen，Geetika Babu Bangera，Dean Hildebrand，Farhaan Jalia，Geoff Kuenning，Henry Nelson，and Erez Zadok.2017年。vNFS：使用复合和矢量化I/O最大化NFS性能 ACM Trans. 存储13，3，第21条（2017年9月），24页。https://doi.org/10.1145/3116213这项工作之所以成为可能，部分要归功于Dell-EMC、IBM和IBM的支持; NSF授予CNS-1251137、CNS- 1302246、CNS-1305360和CNS-1622832;以及ONR授予N 00014 -16-1-2264。作者Chen，G.班格拉湾Jalia和E.Zadok，349 New Computer Science，Stony Brook University，Stony Brook，NY11790; email：{mchen，gbangera，farhaan，ezk}@cs.stonybrook.edu; D.Hildebrand，IBM Research-Almaden，650Harry Rd，San Jose，CA 95120;电子邮件：dhildeb@us.ibm.com; G.Kuenning，计算机科学系，Harvey Mudd学院，301 Platt Blvd。Claremont，CA 91711;电子邮件：geoff@cs.hmc.edu; H.纳尔逊，沃德梅尔维尔高中，380老城路，Setauket-东Setauket，纽约11733;电子邮件：hcnelson99@gmail.com。允许免费制作本作品的全部或部分的数字或硬拷贝，以供个人或课堂使用，前提是制作或分发副本的目的不是为了盈利或商业利益，并且副本的第一页上有本声明和完整的引用。必须尊重作者以外的其他人拥有的本作品组件的版权。允许使用学分进行摘要。以其他方式复制、重新发布、在服务器上发布或重新分发到列表中，需要事先获得特定许可和/或付费。从permissions@acm.org请求权限。© 2017 ACM 1553-3077/2017/09-ART21 $15.00https://doi.org/10.1145/311621321ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月第二十一M. Chen等人1导言和背景现代计算机硬件支持高并行性：智能手机可以有8个核心，NIC可以有256个队列。虽然并行可以提高吞吐量，但许多标准软件协议和接口无法利用它，并且由于调用的串行化而成为瓶颈[9，19]。两个著名的例子是HTTP/1.x和POSIX文件系统API，它们每次都只支持一个同步请求（每个TCP连接或每个调用）。随着摩尔例如，HTTP/2 [5]增加了对每个连接发送多个请求的支持。然而，据我们所知，在文件系统API方面几乎没有取得什么进展。在本文中，我们同样建议批处理多个文件系统操作。我们特别关注网络文件系统（NFS），并研究通过使用对NFSv 4友好的文件系统API可以提高多少性能[36，37]; NFS的最新版本支持将多个操作打包到单个RPC中的复合过程，因此只需要一次往返就可以处理它们。不幸的是，尽管NFS复合已经在大多数NFS客户机和服务器中设计、标准化和实现，但它们没有得到充分利用-主要是因为低级POSIX文件系统接口的限制[9]。为了解释NFS 4的复合过程的操作和前提我们从图1开始，它显示了POSIX API如何限制读取小文件这个简单的任务涉及四个系统调用（stat、open、read和close），它们生成五个复合，每个复合都需要到服务器进行一次往返因为复合是由低级POSIX调用初始化的，所以每个复合只包含一个重要的操作（粗体），其余的都是普通的操作，比如PUTFH和gETFH。Compounds通过将syscall操作（查找、操作、读取）与NFSv4状态管理操作（PUTFH、gETFH）和属性检索（gETATTR）相结合，略微减少了往返次数，但由于POSIX API的序列化特性，syscall操作本身无法组合理想情况下，一个小文件应该只使用一个NFS复合（和一次往返）来读取，如图2所示。这将减少80%的读取延迟（通过删除五个往返中的四个）。我们甚至可以使用一个化合物读取多个文件，如图3所示。所有这些示例都使用标准（未修改）NFSv4协议。NFSv4服务器为每个NFSv4客户端维护一个称为当前文件句柄（CFH）的状态。操作pUTR ooTFH将CFH设置为根目录的文件句柄。PUTFH和GETFH分别设置和检索CFH。lookUP和OPENn假定CFH是一个目录，分别在其中查找或打开指定的名称，并更改CFH。GETATTR、READ和DECODE都对CFH指示的文件进行操作。sAVEFH和REStoREFH对保存的文件句柄（SFH）进行操作，这是一种类似于当前文件句柄（CFH）的NFSv4状态。SAVEFH将CFH复制到SFH;restoREFH从SFH恢复CFH为了使复合体充分发挥其潜力，我们需要一个文件系统API来传达高级语义和批处理多个操作。我们设计并开发了vNFS，这是一个NFSv4客户端，它公开了一个高级矢量化API。vNFS符合NFSv4.1标准，无需更改NFS服务器。它的API易于使用，并且足够灵活，可以作为新的更高级别功能的构建块。vNFS完全在用户空间中实现，因此易于扩展。vNFS对于处理大量元数据或执行小I/O的应用程序特别有效和方便。例如，vNFS允许tar使用单个RPC读取许多小文件，而不是为每个文件使用多个RPC;它还允许一次解tar设置许多提取文件的属性，而不是为每个属性类型（所有者、时间等）进行单独的系统调用。我们使用标准NFSv4.1协议实现了vNFS，并添加了两个小的协议扩展来支持文件追加和复制。我们将GNU的Coreutils包（ls、cp和rm）、bsdtar、nghttp 2（一个HTTP/2服务器）和Filebench [ 16，41 ]移植总的来说，我们发现vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月≤××图1.一、内核NFS客户端用来读取小文件的NFS复合每个编号的请求都是一个复合，其操作由子分隔有几个操作管理复合中的当前文件句柄（CFH）：p UTR oo T f H将CFH设置为根目录的文件句柄，而p UT fH和g ET f H设置或检索CFH。looKU p和opE n要求CFH是一个目录，但随后将CFH设置为指定名称的目录GETATTR、READ和decode都对CFH指示的文件进行操作图二、只使用一个复合词读取/home/Bob/.bashrc这个复合物在功能上与图1中的五个相同，但只使用一个网络往返。图3.第三章。一个NFS复合读取三个文件。这些操作可以分为四组：（a）将当前和保存的文件句柄设置为/home/Bob;（b）、（c）和（d）读取文件.bashrc、.bash_profile和.bash_login。s A v E f H和RE s to RE f H确保打开文件时CFH为/home/Bob。答案被省略了。更容易修改应用程序以使用vNFS。我们在具有不同延迟的网络上运行了一系列微观和宏观基准测试，表明vNFS可以在小网络延迟（5.2ms）的情况下将此类应用程序加速3本文的其余部分组织如下：第2节总结了vNFS的设计。第3节详细介绍了矢量化的高级API。第4节描述了我们的原型的实现第二十一M. Chen等人ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月第5节通过对我们移植的应用程序进行基准测试来评估vNFS的性能和可用性。第6节讨论相关工作，第7节结束。2设计概述在本节中，我们将总结vNFS的设计，包括我们的目标、所做的选择和架构。2.1设计目标我们的设计有四个目标，按重要性排序：高性能：vNFS的性能应大大优于现有的NFS客户端，并改善延迟和吞吐量，特别是对于强调元数据和小I/O的工作负载。其他工作负载的性能应相当。符合标准vNFS应完全符合NFSv4.1协议，它可以用于任何兼容的NFS服务器。易于采用：vNFS应该提供一个易于程序员使用的通用API。它应该为POSIX兼容代码的开发人员所熟悉，以实现平稳和增量的采用。可扩展性：vNFS应该使添加功能以支持新功能变得容易，性能改进。例如，添加对服务器端复制（SSC;当前NFSv4.2草案中的一个功能[20]）的支持或创建新的特定于应用程序的高级API应该很简单2.2设计选择vNFS的核心思想是通过使用标准NFS的复合特性来提高性能。我们将讨论我们所面临的选择，并证明我们所选择的选择是为了实现2.1节所列的目标。2.2.1公开与暗聚。 为了利用NFS复合，vNFS使用高级API来公开表达复合操作的意图。另一种方法是在仍然使用POSIX API的情况下，在引擎盖下隐藏操作。隐蔽合并是存储和网络中的一种常见技术;例如，磁盘I/O处理器将许多小的请求合并为几个较大的请求以最小化寻道[3]; Nagle虽然公开复合改变了API，但我们认为它在四个重要方面优于隐蔽合并：（1）通过使用高级API，公开复合可以批量处理不可能隐蔽合并的依赖操作。例如，使用POSIX API，我们不能发出读，直到我们收到来自前面的开放的答复。(2)显性复合可以使用新的API来表达在低级原语中无法有效传达的高级语义。NFSv4.2(3)公开复合提高了吞吐量和延迟，而隐蔽合并以延迟为代价提高了吞吐量，因为将调用合并到一起本质上需要等待。因此，隐蔽的合并是有害的元数据操作和受延迟限制的小型I/O。这在具有更快SSD和40GbE SSD的现代系统中非常重要，其中延迟的改善速度比原始网络和存储带宽慢得多[35]。(4)公开的复合允许实现使用所有可能的信息来最大限度地提高性能;隐蔽合并取决于可能不是最佳或错误的策略，例如时间和I/O大小。例如，Nagle····vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月图四、vNFS体系结构。 粗箭头显示vNFS的数据路径，虚线箭头显示内核NFS客户端的数据路径。 vNFS库和客户端（阴影框）是我们添加的新组件;其余组件已经存在。2.2.2矢量化与基于开始/结束的API。两种类型的API可以表达明显的复合：矢量化的一种将许多所需的低级NFS操作复合到单个高级调用中，或者使用start_compound和end_compound等调用来组合所有低级调用的API[34]。我们选择矢量化API有两个原因：（1）矢量化API比基于开始/结束的API更容易基于开始/结束的API的用户可能会将I/O与其他代码（例如循环和测试文件系统状态）混合在一起，而NFS组合无法支持这些代码。(2)矢量化的API逻辑上位于高级，使用起来更方便，而使用低级的基于开始/结束的API对于高级任务来说更繁琐（类似于C++编程与C++编程）。组装）。2.2.3用户空间与内核实现。vNFS的内核空间实现将允许它利用内核但是，我们选择在用户空间设计和实现vNFS有两个原因：(1)添加用户空间API比添加系统调用到内核要容易得多，并且简化了未来的扩展;（2）用户空间开发和调试更快更容易。虽然内核实现可能更快，但之前的工作表明性能影响可能很小[40]，本文中的结果表明，即使使用我们的用户空间方法，性能也有很大2.3架构图4显示了vNFS的体系结构，它由一个库和一个客户机组成。应用程序不使用POSIXAPI，而是调用vNFS库提供的高级向量化API，该API直接与vNFS客户端通信。vNFS库促进了应用程序的采用，因为大多数现代应用程序都是使用库和框架而不是OS系统调用开发的[2]。为了提供通用支持并鼓励增量采用，该库检测何时不支持复合操作，并在这种情况下将vNFS操作转换为标准POSIX操作。因此，vNFS库也可以与不支持复合的文件系统一起使用，例如，作为一个实用程序库来执行NFS文件系统操作。vNFS客户端从库中接受向量化操作，将尽可能多的操作放入每个复合中，使用独立传输RPC（TI-RPC）将它们发送到NFS服务器，最后处理回复。请注意，现有的NFSv4服务器已经支持复合，并且可以与vNFS一起使用而无需更改。TI-RPC是一个通用的RPC库，第二十一M. Chen等人ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月表1.vNFS矢量化API函数功能描述vopenvclose打开/关闭多个文件。vreadvwrite读/写/创建/追加文件，自动打开和关闭文件弗盖塔特尔斯弗塞塔特尔斯获取/设置文件系统对象的多个属性。血管镜检查vcopy使用/不使用服务器端复制全部或部分复制文件。vmkdir创建目录。vlistdir（递归地）列出目录中的对象及其属性。vsymlink创建多个符号链接。vreadlink阅读多个符号链接。硬链接创建多个硬链接。vremove删除许多对象。弗尔热讷很多物体。每个函数都有两个返回值：一个错误代码和一个成功操作的计数。一旦复合中的任何操作失败，NFS服务器将停止处理复合中的剩余操作。为了促进逐步采用，vNFS还提供了类似POSIX的标量API函数，这里为了简洁而省略了。每个vNFS函数都有一个不遵循符号链接的版本，也被省略了。Linux每个调用仅支持单个数据缓冲区）;TI-RPC也可以与内核NFS客户端类似，vNFS客户端也管理NFSv43VNFS API本节详细介绍vNFS每个API函数扩展其POSIX对应项以操作文件系统对象的向量（例如，文件、目录、符号链接）。vNFS函数以标准的方式处理错误：返回成功操作的结果，在复合中报告第一个失败操作的索引（如果有的话），并忽略服务器未执行的任何剩余操作。图5演示了使用vNFS API读取一个NFS复合文件中的三个小文件。为了简化编程，vNFS还为常见任务（如递归删除整个目录等）提供了实用程序函数。3.1Vread/Vwrite这些功能可以读或写多个文件使用一个单一的化合物，自动按需打开和关闭文件。这些调用同时提高了吞吐量，减少了延迟，并简化了编程。这两个函数都接受I/O结构的向量，每个向量包含一个vfile结构（图5）、偏移量、长度、缓冲区和标志。我们的向量化操作比readv和writev系统调用更灵活，可以在一个调用中操作多个文件的许多（不连续）偏移量。在生成复合请求时，vNFS为路径表示的文件添加操作项和缓存在可能的情况下合并操作和操作（例如，当从一个文件读取两次时vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月图五、使用向量化API一次读取三个文件的简化C代码示例由于I/O结构中的文件可以是相同的，因此vread/vwrite也可以用于在单个文件中以多个（不连续）偏移量进行读/写。I/O结构中的长度字段也用作输出，返回读取或写入的字节数。该结构有几个标志，映射到NFS的内部布尔参数和应答。例如，标志is_creation对应于NFSOPEN4_CREATE标志，告诉vwrite在必要时创建目标文件。is_write_stable对应于NFS因此，单个vwrite可以实现多个写入和随后的fsync的效果，fsync是常见的I/O模式（例如，在日志或日志中）。3.1.1国家管理。 NFSv4是有状态的，而OPEN n是一个状态变更操作。NFSv4协议要求客户端在读取或写入文件之前打开文件此外，读和写必须提供由前一个操作返回的stateid（唯一标识服务器状态的ID因此，当vread或vwrite将操作和读/写调用添加到单个复合中时，状态管理是一个关键挑战vNFS通过使用NFS当前状态ID解决了这个问题，它是一个类似于当前文件句柄的服务器端状态为了确保NFS服务器始终使用正确的状态，vread和vwrite利用NFSv43.1.2- 好的 vwrite还为NFSv4协议添加了一个可选的小扩展，以更好地支持追加。正如在Linux 手册页open（2）[25]中所指出的，“如果多个进程同时向文件追加数据，O_APPEND可能会导致NFS文件系统上的文件损坏”。基本NFSv4协议不支持追加，因此内核NFS客户端通过写入等于当前已知文件大小的偏移量来进行此行为效率低下，因为必须首先在单独的RPC中读取文件大小我们的扩展在I/O结构中使用了一个特殊的偏移值（UINT64_MAX）来指示追加，使追加可靠，只需对NFS服务器进行微小的（5 LoC）更改。第二十一M. Chen等人ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月×3.2Vopen/Vclose使用vread和vwrite，应用程序可以访问文件而无需显式打开和关闭。我们的API仍然支持vopen和vclose操作，这为多次读取或写入的大型文件增加了效率。vopen和vclose对于维护NFS的close-to-open缓存一致性也很重要vopen在一个RPC中打开多个文件（由路径指定），包括查找其父目录所需的查找，如图3所示。每个文件都有自己的打开标志（读、写、创建等），这在读和写混合时很有用，如在外部合并排序中。我们还提供了vopen_simple，它为所有文件使用一组通用的标志和模式（在创建时）。一旦打开，文件由文件描述符表示，文件描述符是保存状态（文件游标，NFSv4状态ID和序列ID [37]等）的内部表的整数索引打开的文件。vclose关闭多个打开的文件并释放它们的资源。3.3Vgetattrs/Vsetattrs这两个函数一次操作多个文件的多个属性，组合多个系统调用（chmod、chown、utimes和truncate等）。这对于tar和rsync这样的工具特别有用。老化的POSIX API是一次设置多个属性的唯一限制; Linux内核VFS已经支持使用inode_operations的setattr方法进行多属性操作，NFSv 4协议也有类似的SETATTR支持。vgetattrs/vsetattrs不仅可以一次获取/设置多个属性，而且可以在一个RPC中为多个文件获取/设置属性。vgetattrs和vsetattrs使用属性结构的数组作为输入和输出。每个结构包含一个vfile结构，所有属性（模式，大小等），以及显示正在使用哪些属性的位图。3.4Vsscopy/Vcopy文件复制是如此普遍，以至于Linux已经添加了sendfile和splice系统调用来支持它。不幸的是，NFS还不支持复制，客户端必须使用READ和WRITE来代替。这浪费了时间和带宽，因为数据必须通过网络读取并立即写回。让NFS服务器直接在其端复制文件会更有效这种SSC操作已经被提议用于即将到来的NFSv4.2 [20]。前瞻性地，我们在vNFS中包含了vsscopy，但是，由于SSC需要服务器增强功能，因此我们还提供vcopy以与当前服务器兼容。vsscopy接受一个复制结构数组，每个复制结构包含源文件和偏移量、目标文件和偏移量以及长度。如果需要，目标文件由vsscopy创建长度可以是UINT64_MAX，在这种情况下，有效长度是源偏移和源文件结尾vsscopy可以使用单个RPC将多个文件复制到他们的全部复制结构在长度字段中返回复制的字节数vcopy具有相同的效果，但不使用SSC。当NFS服务器不支持SSC时，vcopy很有用;vcopy可以使用三个RPC（vgetattr、vread和vwrite中的每一个的复合）而不是7个N个RPC（每个文件2个OP_ns、2个paste_ s、1个g_ETATTR、1个READ和1个WRITE）复制N个未来的API可以只提供vcopy，并在SSC可用时静默切换到vsscopy;我们在当前实现中包含了一个单独的vsscopy，以便我们可以轻松地将其与vcopy进行比较。3.5VmkdirvNFS提供vmkdir来一次创建多个目录（如目录树），这在untar、cmake和递归cp等工具中很常见。vNFS具有一个确保目录实用程序vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月使用vmkdir确保深层目录及其所有祖先存在的函数。以 ]查找存在哪些祖先，然后使用vmkdir创建缺少的目录。请注意，只需使用向量参数]不起作用：NFS服务器在尝试重新创建第一个现有祖先并停止处理所有剩余操作时将失败（使用EEXIST）。3.6弗利斯迪尔这个函数通过对readdir的四个改进加快了目录列表的速度：（1）vlistdir一次列出多个目录;（2）在开始列出目录之前不需要opendir调用;（3）vlistdir检索属性以及目录条目，保存后续的stat;（4）vlistdir可以递归工作。这个操作可以看作是一个快速矢量化的ftw（3），它使用尽可能少的RPC读取NFS目录内容。vlistdir有五个参数：要列出的目录数组、指示所需属性的位图、选择递归列表的标志、用户定义的回调函数（类似于FTW的第二个参数[ 18 ]）以及传递给回调的用户提供的不透明指针。对于每个列出的目录条目，回调函数由三个参数调用：一个包含文件路径和活动文件属性的属性结构（见3. 3节），顶层祖先目录（出现在vlistdir的vlistdir按照给定的顺序处理目录;递归是广度优先的。但是，树中同一级别的目录以任意顺序列出。3.7Vsymlink/Vreadlink/Vhardlink这三个vNFS操作允许一次创建或读取多个链接。符号链接通常是批量创建的，以提供另一个目录树的影子树视图;与vlistdir一起，vsymlink可以优化像cp-sr和lndir这样的操作。vhardlink类似于vsymlink，但创建硬链接。这三个函数都接受路径向量和包含目标路径的缓冲区向量3.8Vremovevremove一次删除多个文件和目录。虽然vremove本身不支持递归删除，但程序可以通过递归的vlistdir后跟正确排序的vremoves来实现这种效果; vNFS为此提供了一个实用函数rm_recursive。3.9弗热姆重命名许多文件和目录是常见的，如组织媒体收藏时许多免费工具[7，22，33]甚至商业工具[17]都是为了这个目的而开发的。vNFS提供了vrename来促进和加速批量重命名。vrename使用尽可能少的RPC将源路径向量重命名为目的路径向量。4执行我们在Linux上用C/C++语言实现了一个vNFS的原型如图4所示，vNFS有一个库和一个客户机，两者都在用户空间中运行vNFS库实现vNFS API。应用程序通过包含API头文件并链接到它来使用该库对于NFS文件，库将API函数调用重定向到vNFS客户端，vNFS客户端构建大型复合请求并通过TI-RPC库将其发送到服务器对于非NFS文件，该库将API函数转换为POSIX调用，因此也可以用作实用程序库。(Our如果某个文件位于vNFS配置文件中指定的任何导出目录下，则当前原型将该文件视为位于NFSvNFS客户端第二十一M. Chen等人ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月构建在NFS-Ganesha [13，30]上，这是一个开源的用户空间NFS服务器。NFS-Ganesha可以导出存储在许多后端中的文件，例如XFS和GPFS。我们的vNFS原型使用一个名为PROXY的NFS-Ganesha后端，它从另一个NFS服务器导出文件，并可以重新利用为用户空间NFS客户端。原始的PROXY后端使用NFSv4.0;我们添加了NFSv4.1支持，包括会话管理[37]。我们的原型实现增加了10，632行C/C++代码，删除了1，407行。vNFS是线程安全的;我们已经对其进行了彻底的测试。4.1RPC大小限制vNFS API函数（如表1所示）对每次调用的操作数没有限制但是，每个RPC都有一个可配置的内存大小限制，默认为1MB。我们确保vNFS不会生成大于该限制的RPC请求，无论API调用包含多少操作。因此，我们将长参数拆分为块，并为每个块发送一个复合请求。我们还合并RPC的答复后返回隐藏任何分裂。我们的分裂避免产生小的化合物。对于数据操作（vread和vwrite），我们可以根据缓冲区长度轻松估计请求和应答的大小，因此我们将一个复合只有当它的大小接近1MB时。（内核中的NFS客户端同样根据rsize和wsize挂载选项（默认值也是1MB）拆分大型读取和写入。对于元数据操作，估计回复大小更困难，特别是对于READDIR和gETATTR。我们选择保守的做法，只要元数据操作的组合包含k个以上的NFS操作，就简单地将其拆分。我们为k选择了默认值256，这使得NFS服务器能够进行高效的并发处理，而且不太可能超过大小限制。例如，在列出Linux源代码树时，READDIR（最大的元数据操作）的平均回复大小大约为3，800字节。如果k仍然太大（例如，当列出大的目录时），服务器将返回部分结果，并使用cookie来指示在何处恢复对后续请求的调用。4.2协议扩展vNFS包含对NFSv4.1协议的两个扩展，以支持文件附加（参见第3.1节）和SSC（参见第3.4节）。这两个扩展都需要更改协议和NFS服务器。我们已经在基于NFS-Ganesha的服务器上实现了这些更改[13，30]。文件附加扩展很容易实现，只添加了一个if语句和五行C代码。在服务器中，只要写偏移量是UINT64_MAX，我们就简单地使用文件大小作为有效偏移量。我们的SSC实现遵循NFSv4.2草案中提出的设计[20]。我们将新的复制操作添加到vNFS客户端和NFS-Ganesha服务器。在服务器端，我们使用splice（2）复制数据，这避免了不必要地跨内核/用户边界移动数据。这个扩展为NFS-Ganesha服务器添加了944行C代码。4.3路径压缩我们创建了一个优化，当复合文件路径具有局部性时，可以 这个想法是通过使它们相对于同一化合物中的前一个路径来缩短具有冗余的路径。例如，当列出目录“/1/2/3/4/5/6/7/a”和“/1/2/3/4/5/6/7/b”时，一个简单的实现将为每个目录生成八个查找（每个组件一个）。在这种情况下，我们将第二个目录的路径替换为“./”。b“并只使用一个LOOKUPP和一个LOOKUP; LOOKUPP将当前文件句柄设置为其父目录。对于这个示例，这种简单的技术可以节省多达六个NFS操作。注意，如果当前文件句柄不是一个目录，则LOOKUPP会产生一个错误，因为大多数文件系统都有记录目录父项的元数据，但没有记录文件父项的元数据。在这种情况下，我们使用sAVEFH来记住文件系统树中最深的共同祖先（即，vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月‘‘/1/2/3/4/5/6/7’’ （但是，这种方法不能用于lI nk、REnAME和coP y，它们已经将保存的文件句柄用于其他目的。）我们仅在保存NFS操作时使用此优化：例如，使用“../../”c/d“不保存路径”/1/a/b“和”/1/c/d“的任何内容。4.4客户端缓存vNFS为数据和元数据提供直写客户端缓存。这两个缓存都使用LRU替换算法，并为每个缓存条目设置可配置的过期时间。vNFS我们的缓存实现基于Poco Cache Framework [32]。vNFS元数据缓存使用完整路径作为缓存键，而不是单独的路径组件，因此搜索文件仅涉及一次查找。正如Tsai等人最近的一项研究所示。[42]，在大多数情况下，基于全路径的缓存每个vNFS元数据缓存条目都包括文件系统对象的属性、路径和NFS文件句柄。每个目录的缓存条目都有额外的数据来加速任何常用的目录列表操作。这些数据包括指向目录子目录的缓存条目的指针以及指示是否其所有子节点都被高速缓存的标志。当此标志为true时，目录vNFS数据缓存将缓存的文件数据组织为大小可配置与Linux直写的一个缺点是，每次写操作，无论多小，都必须立即发送到服务器然而，这对于vNFS来说并不是一个大问题，因为许多小的写入仍然可以使用其向量化API进行批处理vNFS的数据缓存的一个特殊策略这是因为缓存小文件并不能证明缓存重新验证引起的延迟开销是合理的。NFS这个重新验证会执行一个额外的GETATTR请求，然后将从服务器返回的ctime与本地缓存的ctime进行比较。如果时间相同，这意味着没有其他NFS客户端更改该文件，本地缓存的文件数据有效;否则，必须丢弃缓存的数据。对于整个内容适合一个请求的小文件，重新读取文件比执行重新验证更有效。这种策略在具有高带宽但不一定具有低延迟的现代网络中特别有用。如本文的早期版本所示[10]，在没有缓存的情况下读取小于512KB的文件更快。此策略是一个可选特性，可以通过将缓存阈值设置为零来关闭。5评价为了评估vNFS，我们运行了微基准测试，并移植了应用程序来使用它。我们现在讨论我们的移植经验，并评估由此产生的性能。5.1实验测试台设置我们的测试平台由两台运行CentOS 7.0的相同Dell PowerEdge R710机器组成，Linux 3.10内核。每台机器都有一个六核Intel Xeon X5650 CPU、64 GB RAM、一个Intel 10 GbE NIC和一个带有电池支持写缓存的PERC 6/i RAID控制器一台机器充当NFS服务器，运行带有我们的文件附加和SSC扩展的NFS-Ganesha 2.4;另一台机器充当客户端，运行vNFS。NFS服务器将Ext4文件系统（存储在Intel DC S3700 200 GB SSD上）导出到客户端。这两台机器直接相连第二十一M. Chen等人ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月××××Dell PowerConnect 8024F 10 GbE交换机。我们测量了两台机器之间的平均RTT为0.2ms为了模拟不同的LAN和WAN条件，我们使用netem向服务器的出站链路注入1- 30 ms的延迟为了评估vNFS（ac选项）已启用，最大读/写大小（rsize/wsize选项）为1 MB。我们的vNFS原型不使用mount，而是从配置文件中读取导出目录的名称。每个实验我们至少做三次，然后取平均值。我们的图表将标准差显示为误差条，这些误差条非常小，以至于在大多数图中看不到在每次运行之前，我们通过卸载和重新装载NFS目录来刷新内核客户机的页面和dentry缓存。我们还在每次运行之前清空了vNFS客户端缓存（参见第4.4节）。内核客户端和vNFS客户端的元数据缓存都有1分钟的超时时间;两个数据缓存的大小都受客户端RAM大小的限制NFS-Ganesha服务器除了使用操作系统的页面缓存和dentry缓存外，还使用内部缓存为了量化移植应用程序的工作量，我们报告每个应用程序的LoC更改，包括错误处理代码。5.2微工作负载5.2.1小型与大档案 vNFS的目标是提高具有许多小型NFS操作的工作负载的性能，同时保持数据密集型工作负载的竞争力。为了测试这一点，我们比较了vNFS和基线在读取和写入1,000个大小相同的文件时所用的时间，同时将文件大小从1 KB改变到16 MB。我们在延迟为0.2ms到5.2ms的网络中重复了这个实验结果如图6所示（以对数标度表示），其中加速比是基线完成时间与vNFS完成时间之比加速比大于1表示vNFS的性能优于基线;加速比小于1表示vNFS的性能较差。由于vNFS将许多小的读写操作组合成大的复合操作，因此当文件大小较小时，它的性能要比基线好得多。vNFS的文件大小为1KB，网络延迟为0.2ms，读取时比基线快9（图6（a）），写入时快4（图6（b））。随着网络延迟增加到5.2毫秒，vNFS的加速比进一步提高到40（读）和23（写）。vNFS随着文件大小（图6中的X轴）增加到1MB或更大，vNFS在延迟为0.2-3.2 ms的快速网络数据缓存在此工作负载中没有帮助，因为每个文件只读取一次。在没有数据缓存的情况下，vNFS对大文件的读取与基线相当，如本文的早期版本所示[10]。然而，vNFS比基线略快，网络延迟为4.2-5.2毫秒;这是因为，尽管数据操作太大而无法组合，但vNFS仍然可以将它们与小的元数据操作（如open，pane和getattr）组合在一起对于大型写入，vNFSvNFS缓存的负面影响vNFS：使用复合和矢量化I/O最大限度地提高NFS性能第二十一ACM Transactions on Storage，Vol.号133、第二十一条。出版日期：2017年9月×图六、vNFS当加速比大于、等于或小于1.0时，vNFS分别快于（蓝色）、等于（白色）或慢于（红色）基线。 网络延迟（Y轴）从0.2ms（而不是零）开始，因为这是我们测试床的测量基础延迟（见第5.1节）。5.2.2复合度。复合的程度（即，每个复合的非平凡NFS操作的数量）是决定vNFS可以提升多少性能的关键因素。理想的情况是在一个复合中执行大量的文件系统操作，但这样做并不总是可行的，因为应用程序可能具有仅依赖于单个文件的关键路径。为了研究复合程度如何影响vNFS图7显示了在0.2ms延迟网络中，当每个API调用的操作数从1增加到256时，vNFS相对于基线的加速比。在每个调用一个操作的情况下，vNFS在14种操作类型中的10种操作类型上优于基线。改进是因为vNFS仍然可以节省单文件调