原文

摘要

文章分析了iBench 的I/O 行为，揭示了iBench 和一般文件系统在组织文件、顺序读写、异步与原子性操作等方面的差别。文章为下一代的本地文件系统和基于云的存储系统给出了意见。（这里ramification 不懂什么意思）

引言

分析包括两个Apple 软件套件：iWork（Pages，Numbers 和keynote）和iLife（iPhoto，iTune和iMovie）。为了分析iBench 套件的I/O 行为，建立了一个称为DTrace 的框架并开发了一个基于Apple-script 的应用。得出以下结论：

1. A file is not a file.用户看来的一个文件实际上也是由多个小文件组成的。
2. Sequential access is not sequential.顺序访问也不是真正的顺序访问
3. Auxiliary files dominate.辅助文件占据主导地位
4. Writes are often forced.写操作是被强迫了，许多程序定期的会使用fsync 刷到磁盘里
5. Renaming is popular.重命名是十分常见的（一致性）
6. Multiple threads perform I/O.有些应用会起上百个线程来进行I/O ，所以存储/文件系统应该是可感知线程的，这样才能够合理的分配带宽。
7. Frameworks influence I/O.开发框架影响I/O ，里面举例了在引用cocoa.h 头文件时会从689个文件中包含112047行代码。

文章的主要贡献：

1. tracing framework
2. 解构iBench I/O 行为
3. 描述了哪些性质上的变化影响了I/O
4. present the 34 traces from the iBench task suite

Case Study

通过创建一个文档，接着插入15 幅JPEG 图（每个2.5MB）并保存文档为一个Microsoft .doc 文档格式。观察这个过程中十个线程对六类文档进行的I/O 解释了引言中的七个结论。

IBENCH TASK SUITE

这个section 用前面提到的iWork 和iLife 作为workload 进行了iBench 的测试。系统调用的traces 是通过DTrace 收集（The system call traces were gathered using DTrace）。

ANALYSIS OF IBENCH TASKS

一开始就提出了四个问题：

1. 访问了哪些文件，以及这些文件的大小？
2. 读和写文件时如何访问的？是顺序的？还是预留空间（预取）的？
3. 什么是事务性（transactional）属性？写是通过fsck 命令写入还是自动执行的？
4. 多线程的应用是如何把I/O 分担到各个线程中的？

文章比对了iPhoto, iTunes, iMovie, Pages, Numbers, Keynote 在iBench 测试操作（start，Dup 等）时获取文件类型的个数和比率，以及指定类型文件的个数和比率，这里需要提出的是文章把访问的文件类型分为了multimedia，productivity(像doc，xls等)，plist，sqlite，strings，other 六个类型。接着将文件大小分别对文件个数和操作文件总大小取加权。对应的得出四个表：

1. 访问某类型（六个中一个）文件个数占所有访问类型文件个数的比率
2. 访问某类型文件总大小占所有访问文件大小的比率
3. 访问某大小文件（<4KB, <64KB, <1MB, <10MB, >10MB）个数占所有文件个数的比率
4. 访问某大小文件的总大小占所有文件大小的比率

从1,2 两个图可以看出iPhoto，iTunes 和iMovie 访问multimedia 类型文件的个数和大小都比较大，从文件大小的个数来看，访问<4KB 文件个数占访问所有文件个数的比率都比较高，特别是Pages，Numbers 和Keynote 应用超过60% 访问文件的格式是<4KB 文件。很有意思的是，虽然访问4KB 文件数目很多，但由于这些文件很小所以占所有文件大小的比率很小，我想如果对访问这些文件的耗时进行下分析，可能会对系统性能提高有更好说服力。

下面一部分是关于sequentiality 的分析，我又回头看了下对这些workload 的操作：start 打开对应的应用程序，open 是打开媒体或文档等文件，imp 是将media 等导入到媒体库library 中，new 是创建新的文件并保存。

首先看这些操作读的连续性，所有workload 中start 操作读的连续性超过了75%，可见这些程序在开启的时候大部分I/O 是连续的（这点其实可以拆分来看，虽然连续读操作在容量上占了大部分，但是时间上可能还是随机写所占的时间更长，可以考虑在这方面做工作）。iPhoto 和iTunes 中Imp 操作类似于一个copy 操作，所以连续性较好；有点不理解iTunes 中PlayS （播放10 首歌曲）全部是近似读操作，而PlayM （播放三分钟电影）几乎就没有连续的操作（WHY）。

接着说了预取在除了copy 之外的操作上基本没有什么用！大部分操作也没有过多的采用预取。

Writes typically involve a trade-off between performance and durability.

写操作往往是在性能和持久性之前做了一个权衡。这部分是对sync 命令的分析：

The graph further subdivides the source of the fsync activity into six categories. SQLite indicates that the SQLite database engine is responsible for calling fsync; Archiving indicates an archiving library frequently used when accessing ZIP formats; Pref Sync is the Preferences Synchronize function call from the Cocoa library; writeToFile is the Cocoa call writeToFile with the atomically flag set; and finally, Flush-Fork is the Carbon FSFlushFork routine.

fsync 被具体分类六类：SQLite 是SQLite 数据库调用fsync，archiving 为在访问ZIP 格式文档的时候产生，Pref Sync 是cocoa 库中一个函数调用的fsync ，writeToFile同上，Flush-Fork 是Carbon 库调用的。图看的眼花了~~

中间插一段atomic write（原子性写），即写操作要么失败，回滚到写之前状态，要么成功               – Step W1: Acquire “write lock” on the existing file. (this is usually part of your app semantics, so you might not need any Win32 APIs here)
– Step W2: Copy the old file in a new temporary file. (copy Foo.txt Foo.Tmp.txt)
– Step W3: Apply the writes to the new file (Foo.Tmp.txt).
– Step W4: Flush all the writes (for example those being remaining in the cache manager).
– Step W5: Rename the old file in an Alternate form (ren Foo.txt Foo.Alt.txt)
– Step W6: Rename the new file into the old file (ren Foo.Tmp.txt Foo.txt)
– Step W7: Delete the old Alternate file (del Foo.Alt.txt)
– Step W8: Release “write lock” on the existing file.

这是对应的流程图：

这样实际上，为了保证写的原子性，会有大量的重命名操作，可见为保证写的原子性系统I/O付出了较大代价。

再就是多线程和异步，家用电脑为了提高交互性能及减少对用户的延迟，常常采用异步写策略。实验得出的结论却是异步读写在所实验的内容中很少采用，但一旦采用了操作中异步I/O比率占用较高。另外iBench 中任务为了会使用很多线程进行I/O 减少对用户的延时（有些可能是上百个线程）。

相关工作

关键字：研究的对象，学术和工程环境，个人应用程序行为，多媒体应用程序，动态workloads，元数据特征，静态存储，长期存储

讨论和结论

有一段话非常有意思：

The iBench tasks also illustrate that file systems are now being treated as repositories of highly-structured “databases” managed by the applications themselves. In some cases, data is stored in a literal database (e.g., iPhoto uses SQLite), but in most cases, data is organized in complex directory hierarchies or within a single file (e.g., a .doc file is basically a mini-FAT file system).

文件系统现在越来越被当作为应用程序管理的高度结构化“数据库”。在一些情况下，数据保存在字母顺序的数据库中，大部分情况下，数据通过复杂目录层次结构组织起来，或者只是一个文件（比如.doc文件实际上就是一个mini-FAT 文件系统）。

完了完了~~~这篇看的还是太慢！

1 Introduction:

The current state of the art in file-system crash consistency as follews.

At one extreme is a lazy, optimistic approach that writes blocks to disks in any order;

At the other extreme are eager, pessimistic approaches that carefully order disk writes;

2 Background

File system consistency: Metadata/Data/Version

Teches for consistency: File system check/Journaling/Soft updates(检查内存元数据块之间的依赖关系，然后顺序地写入到磁盘)/Copy-on-write

3 Design

里面解释了什么是数据的consistency 觉得挺有道理的：Data consistency provides the guarantee that all the data accessed by a file belongs to that file; it may not be garbage data or belong to another file.

文章的idea 之一就是Backpointers ，就是在所有的目录和文件的后面添加一个指向父节点的指针（这点代价我看来是很小的，因为每次文件、目录访问都是要访问其父节点才会访问孩子节点）。通过其来进行一致性验证，文中提到了：This checking happens both at the file level and the data block level.这里能够进行块一级的校验有点不明白，为什么块一级也可以呢，这个backpointers 不是只在文件一级的么？

还有一个idea 是non-persistent allocation structures。

4 Implementation

Backpointer 有三种： Block backpointer{inode, block offset}数据块回溯到所在的inode 的指针，Directory backpointer{directory block backpointer}目录块回溯到所在inode，Backlinks{parent inode}当前inode 回溯到之前的父inode 。（注：这里我有个小疑问，Directory backpointer 实际上就是当前目录的指针，这个在原有的文件系统中不是就有么，用一个黑点’.’代替的么？）。

接下来就讲了在create ，read ，write 等操作的时候这些指针的变化，以及在crash 的时候如何使用backpointer 进行恢复。

Non-persistent allocation structure 是ext2 中bitmaps 和组描述符的替代，不同的是它不在硬盘上持久化存储，而是启动的时候根据backpointers 生成的。（这点和hdfs 以及很多分布式文件系统的元数据管理很类似，1.hdfs 中文件->块的映射是开机时产生的，所以和本文NoFS 同样有冷启动问题。2.hdfs 中目录树结构永久性存储在硬盘上fsImage，但是开机会加载到内存）。

文中提到了，元数据（inode）和数据的扫描都是顺序扫描而不是按目录结构，这样就速度更快。

5 Evaluation评估

这部分分为可靠性测试和性能测试，可靠性测试使用了伪磁盘驱动器进行了错误注入，并查看NoFS 和ext2 文件系统的检测和纠错机制；性能测试比对了NoFS 和ext2、ext3 读写和IOPS 等性能（感觉性能测试接近于ext2 是因为作者就是根据ext2 来改的，做的唯一冗余就是添加了backpointer ，所以结果略差接近于ext2 也是显而易见的，这点感觉是想说明在性能没有损失的前提下可靠性强）。后面关于scan 性能的没怎么看。

6 Discusion

ext2 没有提供强数据一致性，ext3 通过日志记录保证数据一致性，NoFS 提供了强一致性且没有数据上的冗余，性能上也优于ext3 ，唯一的问题就是启动问题。