多线程写文件保证顺序_[博客搬运] 我的文件去哪儿了？

我的文件去哪儿了？

本文部分编译自：Files are hard

我很长时间没有用过本地邮件客户端了。不论是Pine，Eudora，还是Outlook都不能处理我如此大容量的邮件，这些客户端或多或少都发生过崩溃，使得我必须从备份中恢复它们。究竟是什么原因使得他们没有gmail更加可靠？要知道的是，gmail不仅处理更多数量的邮件，并且能够允许世界各地同时的访问。尽管分布式系统有它独特的优势——他们能够容忍部分服务器中的磁盘故障，但我所遇到的数据损坏问题却与磁盘故障无关。

崩溃一致性可能是其中的原因之一，也是最容易考虑的因素，毕竟我们假设了从文件系统到磁盘的所有部分工作正常。

译者按: 崩溃一致性在这里是指在系统崩溃前后所维持的数据一致性，一般情况下文件系统本身的一致性可以由日志（Journaling）或者写时复制（Copy-on-Write）保证，而本文所讨论的则是应用层面的一致性，即编程人员在系统崩溃时期待的、应用数据应保持的不变性，例如，数据库在事务（Transaction）中的原子性。

---

崩溃一致性

Pillai 等人在OSDI'14中的 文章 以及 演讲 展示了正确地保存数据是多么的困难。

我们先来看一个例子。假设我们希望将一个数据为“a foo”的文件更新为“a bar”，我们可以用pwrite系统调用完成这个操作。

pwrite([file], “bar”, 3, 2)  // 在偏移量2处写入bar

这个操作会发生什么？如果一切正常，文件内容将会是“a bar”。如果在这个操作中间发生了崩溃（例如断电）， 我们可能会得到“a bar”，“a foo”，或者一些随机数据。当然这只是一个示例，大部分磁盘都保证了一个sector内数据写入的原子性，请考虑将几个字符或者字节的写入替换为多个Block或者Sector。

如果编程人员希望这个更新操作是原子的，即崩溃后文件内容只有旧数据或新数据两种可能，那么我们可以试图做以下修改：

creat(/dir/log);  // 预写式日志，Write-Ahead Logging
write(/dir/log, “2,3,foo”, 7);
pwrite(/dir/orig, “bar”, 3, 2);
unlink(/dir