一种日志结构文件系统的设计与实现(二）

一种日志结构文件系 统的设计与实现(二）

The Design and Implementation of a Log-Structured file system

Mendel Rosenblum and John K. Ousterhout

Electrical Engineering and Computer Sciences, Computer Science Division

University of California

Berkeley , CA 94720

mendel@sprite.berkeley.edu, ouster@sprite.berkeley.edu

 

邓辉 译

 

原文： http://www.eecs.berkeley.edu/~brewer/cs262/LFS.pdf

2 、 1990’ s 的文件系统设计

       文件系统的设计受两个约束力所限制：技术和工作负载（ workload ），其中技术为我们提供了一组可用的基本构建块，工作负载则要求操作必须高效地运行。本节中会对当前的技术变化进行总结，并描述其对文件系统设计的影响。本节还会介绍 Sprite LFS 的工作负载以及其对设计的影响，同时，对当前的文件系统在处理工作负载和技术变化方面的不足进行了分析。

2.1 、技术

       对于文件系统设计来说，有三种技术尤为重要：处理器、磁盘和主存。处理器的重要性体现在其速度以接近指数的速度不断增长上面，这种增长在 1990’ s 中一直持续。这种增长就要求计算机系统中的所有其他部件都必须进行相应的提速，从而达成系统在速度上的平衡。

 

       磁盘技术同样进步得很快，不过改进主要集中在成本和容量方面，而不是性能。磁盘的性能由两部分组成：传输带宽和存取时间。虽然这两个部分都在改进，但是改进的速度却远低于 CPU 。磁盘阵列（ disk array ）和平行磁头（ parallel-head ）磁盘 [5] 技术确实可以大大地提升磁盘的传输带宽，但是对于存取时间却没有任何重大的改进技术出现（存取时间由难以改进的机械运动决定）。如果应用中存在一系列小的磁盘传输，其中穿插着磁盘寻道，那么该应用在接下来的 10 年中也难以得到大的提速，即使使用更快的处理器。

 

       第 3 种技术是主存储器，其容量以指数级增长。现代的文件系统会把最近使用的文件内容缓存在主存储器中，主存越大，文件缓存就可能越大。这对文件系统的有两个影响。首先，大的文件缓存承担了更多的读磁盘的读请求 [1,6] ，从而改变了磁盘的工作负载分布。出于安全考虑，写请求最终必须得反映到磁盘之上，因此磁盘负载（和磁盘性能）将越来越依赖于写入的性能。

 

       大文件缓存的第二个影响是，它们可以当作写缓冲区使用，可以把大量被修改的块收集起来，然后再写入磁盘。缓冲区可以提高块写入的性能（例如，仅用一次寻道，在一次连续的传输中，就把它们全部写入）。当然，写缓冲会增加崩溃所造成的数据丢失量，这是一个缺点。在本文中，我们假设崩溃并不经常发生，在每次崩溃中，丢失几秒或者几分钟的数据也是可以接受的；对于那些对崩溃恢复要求更高的应用来说，可以用非易失（ non-volatile ） RAM 充当写缓冲区。

2.2 、工作负载

       在计算机应用中，文件系统所要应对的工作负载，有几种是公共的。对文件系统设计来说，其中最难以高效应对的工作负载情况之一为：办公室和工程环境。办公室和工程应用中往往对小文件的访问居多；一些研究给出的度量为：平均文件大小仅有几 K 字节 [1,6-8] 。小文件通常会导致小的随机磁盘 I/O ，小文件的创、删开销中的绝大部分也都是对文件系统“元数据”（用来定位文件块和属性数据结构）的更新。

 

       对大文件进行顺序访问的情况（比如那些超级计算机环境中），也会带来一些有趣的问题，但是这些问题不是针对文件系统软件的。已有很多技术可以保证这种大文件可以顺序地存放在磁盘上，从而 I/O 性能就仅受限于 I/O 带宽和内存子系统，而和文件分配策略无关。在日志结构文件系统的设计中，我们仅关注于小文件的存取效率，把针对大文件的带宽提升问题留给硬件设计人员。幸运的是， Sprite LFS 中所采用的技术对于大文件同样工作良好。

2.3 现有文件系统的问题

       当前的文件系统中有两个常见问题，正是这两个问题使得这些系统无法跟得上 1990’ s 的技术和工作负载情况。首先，它们把信息分布在磁盘上所采用的方法会导致太多的小的存取操作。例如， Berkeley Unix 快速文件系统（ Unix FFS ） [9] 可以非常高效地在磁盘上顺序地存放文件，但是不同的文件在物理上是分离的。此外，文件的属性（ inode ）和文件内容也是分离的，包含文件名的目录项也是如此。在 Unix FFS 中创建一个新文件至少需要 5 个独立的磁盘 I/O 操作，每个操作都需要先进行寻道操作：两个对文件属性的访问操作，以及针对文件数据、目录数据以及目录属性的三个访问操作。当在这样的系统中写入小文件时，磁盘可用带宽中仅仅不足 5% 的部分用于新数据的写入，其他都花费在寻道上面。

 

       当前文件系统的第二个问题是，它们都是同步写入的：应用必须得等到写入完成，而不能在后台进行写入工作的同时继续运行。例如，即使 Unix FFS 在写入文件数据块时是异步的，但是其在写入文件系统元数据结构（比如目录或者 inode ）时却是同步的。在应对大量小文件时，同步元数据写入就成为磁盘负载中的支配因素。同步写操作把应用的性能和磁盘的性能耦合在一起，从而使得应用难以利用更快的 CPU 。同时，也无法把文件缓存当成写缓冲区来使用。遗憾的是，像 NFX[10] 这样的网络文件系统中还引入了以前并不存在的附加同步行为。这确实简化了崩溃恢复设计，但是却降低了写入性能。

 

       在本文中，我们将一直使用 Berkeley Unix 快速文件系统（ Unix FFS ）作为当前文件系统的设计实例，并和日志结构文件系统进行比较。之所以把 Unix FFS 当作例子是因为在文献中对其进行了良好的介绍，并且它也被用于几个流行的 Unix 操作系统之中。本节中提出的几个问题并不是 Unix FFS 所独有的，在其他所有的文件系统中也都存在。

3 、日志结构文件系统

       日志结构文件系统的基本思想是：在文件缓存中缓冲一系列的文件系统更改，然后把所有这些更改在一次顺序的磁盘写操作中全部写入磁盘，从而提升了写入的性能。在写操作中写入磁盘的信息包括：文件数据块、属性、索引块，目录以及几乎所有其他用于文件系统管理的信息。在包含大量小文件的工作负载情况中，日志结构文件系统把传统文件系统中的许多小的同步随机写操作变成了大的异步顺序传输，几乎利用到了 100% 的磁盘原始带宽。

 

       虽然日志结构文件系统的基本思想很简单，但是要想把日志方法的潜在好处变成现实，就必须得解决两个关键问题。第一个问题是：如何从日志中获取信息；这是 3.1 小节中的内容。第二个问题是：如何管理磁盘空闲空间，以保证在写入新数据时总有“大块”空闲空间可用。这个问题更困难一些；在 3.2-3.6 小节中对其进行讨论。表 1 总结了 Sprite LFS 中解决上述问题所使用的磁盘数据结构；本文的后面小节会对这些数据结构进行详细的讨论。

3.1 、文件定位和读取

       虽然“日志结构”这个术语听起来似乎必须得通过顺序扫描才能从日志中获取到信息，不过在 Sprite LFS 中却不是这样。我们的目标是要获得和 Unix FFS 一样或者更高的读取性能。为了实现这个目标， Sprite LFS 把索引结构放到日志中以支持随机的信息获取。 Sprite LFS 中所使用的基本结构和 Unix FFS 中的一样：每个文件都有一个称为 inode 的数据结构，其中包含着文件的属性（类型，所有者，许可操作，等等）以及文件前 10 个块的磁盘地址；对于大于 10 个块的文件， inode 中还会包含一个或者多个间接块（ indeirect blocks ） 的磁盘地址，每个间接块中都含有其他数据或者间接块的磁盘地址。一旦找到了文件的 inode ，读取文件所需要的磁盘 I/O 的数量在 Spritel LFS 中和 Unix FFS 中是完全一样的。

 

       在 Unix FFS 中，每个 inode 都位于磁盘中的一个固定位置；对文件的标示数字进行简单的计算，就可以得到该文件 inode 的磁盘地址。 Sprite LFS 则不把 inode 放在固定的磁盘位置；它们被写入到日志中。 Sprite LFS 使用一个称为 inode 映射（ inode map ） 的数据结构来保存每个 inode 的当前位置。有了文件的标示数字，还必须得对 inode 映射进行索引才能找出该 inode 的磁盘位置。 Inode 映射被分成块写入日志中；每个磁盘中都有一个固定的检查点（ checkpoint ）区域来标示所有 inode 映射块的位置。幸运的是， indoe 映射非常的紧致，其活动部分可以完全被缓存在主内存中： inode 映射查询基本上不需要磁盘操作。

 

       图 1 中展示了在不同的目录中创建两个新文件后， Sprite LFS 和 Unix FFS 中的磁盘布局情况。虽然这两个布局具有完全相同的逻辑结构，但是日志结构文件系统在排列方面要紧致得多。因此，在读性能和 Unix FFS 一样优良的同时， Sprite LFS 的写入性能要远优于 Unix FFS 。

3.2 、空闲空间管理：段

（待续）