Tintenfisch: File System Namespace Schemas and Generators

Tintenfisch: File System Namespace Schemas and Generators
复制标题

DOI:
--
复制
发表时间:
2018
期刊:
--
影响因子:
--
通讯作者:
Michael Sevilla;Reza Nasirigerdeh;C. Maltzahn;J. LeFevre;Noah Watkins;P. Alvaro;Margaret Lawson;J. Lofstead;J. Pivarski
Michael Sevilla;Reza Nasirigerdeh;C. Maltzahn;J. LeFevre;Noah Watkins;P. Alvaro;Margaret Lawson;J. Lofstead;J. Pivarski
中科院分区:
其他
文献类型:
--
作者:
Michael Sevilla;Reza Nasirigerdeh;C. Maltzahn;J. LeFevre;Noah Watkins;P. Alvaro;Margaret Lawson;J. Lofstead;J. Pivarski

文献摘要

相似文献

文件系统元数据服务是当今许多工作负载的可伸缩性瓶颈[22、2、3、4、27]。攻击“元数据扩展墙”的常见方法包括:在客户端和服务器上缓存inode[8,26,13,9,29],缓存用于路径遍历的父inode[19,21,6,28,21],以及利用工作负载局部性的动态缓存策略[30,32,17]。这些缓存减少了远程过程调用(RPC)的数量,但其有效性取决于维护缓存一致性的开销以及管理员为给定工作负载选择最佳缓存大小的能力。最近的工作将元数据RPC的数量减少到1个,而根本不使用缓存,方法是让客户端将子树与全局名称空间“分离”,以便它们可以在本地执行元数据操作[31,24]。即使使用这种技术,我们也表明文件系统元数据仍然是一个瓶颈,因为当今工作负载的命名空间可能非常大。该大小对于读取来说是有问题的,因为元数据需要被传输和物化。文件系统元数据的管理技术假定名称空间没有结构,但我们观察到并非所有工作负载都是这种情况。我们提出了Tinenisch,这是一个文件系统,允许用户简洁地表达他们打算创建的元数据的结构。如果用户可以表示命名空间的结构,则Tinenisch客户端和服务器可以(1)压缩元数据,(2)更快地修改较大的命名空间,以及(3)仅生成命名空间的相关部分。这减少了网络流量、存储占用空间以及完成作业所需的元数据操作总数。图1提供了体系结构概述:客户端首先解耦它们想要操作的文件系统子树1,然后客户端和元数据服务器根据需要使用“命名空间生成器”来生成子树。名称空间生成器存储在de-
The file system metadata service is the scalability bottleneck for many of today’s workloads [22, 2, 3, 4, 27]. Common approaches for attacking this “metadata scaling wall” include: caching inodes on clients and servers [8, 26, 13, 9, 29], caching parent inodes for path traversal [19, 21, 6, 28, 21], and dynamic caching policies that exploit workload locality [30, 32, 17]. These caches reduce the number of remote procedure calls (RPCs) but the effectiveness is dependent on the overhead of maintaining cache coherence and the administrator’s ability to select the best cache size for the given workloads. Recent work reduces the number of metadata RPCs to 1 without using a cache at all, by letting clients “decouple” the subtrees from the global namespace so that they can do metadata operations locally [31, 24]. Even with this technique, we show that file system metadata is still a bottleneck because namespaces for today’s workloads can be very large. The size is problematic for reads because metadata needs to be transferred and materialized. The management techniques for file system metadata assume that namespaces have no structure but we observe that this is not the case for all workloads. We propose Tintenfisch, a file system that allows users to succinctly express the structure of the metadata they intend to create. If a user can express the structure of the namespace, Tintenfisch clients and servers can (1) compact metadata, (2) modify large namespaces more quickly, and (3) generate only relevant parts of the namespace. This reduces network traffic, storage footprints, and the number of overall metadata operations needed to complete a job. Figure 1 provides an architectural overview: clients first decouple the file system subtree they want to operate on1 then clients and metadata servers lazily generate subtrees as needed using a “namespace generator”. The namespace generator is stored in the root inode of the de-