问题标签 [fsync]

我正在编写一些软件来处理非常关键的数据，并且需要知道我需要做什么才能实现持久性。

我到处都是矛盾的信息，所以我很感激任何见解。

我有三种方式写入磁盘。

• 使用 O_DIRECT | O_DSYNC，先读后写 512 字节 - 16 MB 块。

• 使用 O_DIRECT，先读取然后写入 512 字节块，并根据需要定期调用 fdatasync。

• 使用内存映射文件，我根据需要定期调用 msync(..., MS_SYNC | MS_INVALIDATE)。

这一切都在带有默认标志的 ext4 上。

对于所有这些，数据是否可能丢失（在写入或同步返回后）或因电源故障、恐慌、崩溃或其他任何原因而损坏？

如果我的服务器在 pwrite 中间死机，或者在 pwrite 开始和 fdatasync 结束之间，或者在被更改的映射内存和 msync 之间，我会有新旧数据的混合，或者它会是一个还是其他？我希望我的个人 pwrite 调用是原子的和有序的。是这样吗？如果它们跨越多个文件，情况是否如此？所以如果我用 O_DIRECT | 写 O_DSYNC 到 A，然后是 O_DIRECT | O_DSYNC 到 B，我是否保证，无论发生什么，如果数据在 B 中，它也在 A 中？

fsync 是否甚至可以保证数据已写入？这说没有，但我不知道从那以后情况是否发生了变化。

ext4 的日志记录是否完​​全解决了这个 SO 答案所说的存在损坏块的问题？

我目前正在通过调用 posix_fallocate 然后 ftruncate 来增长文件。这两者都是必要的吗，它们是否足够？我认为 ftruncate 实际上会初始化分配的块以避免这些问题。

为了增加混乱，我在 EC2 上运行它，我不知道这是否会影响任何东西。尽管它使测试变得非常困难，因为我无法控制它被关闭的积极程度。

我们需要一个应用程序来尽可能地保证当它报告一条记录时，它确实是持久的。我知道要做到这一点，你使用fsync(fd). 然而，出于某种奇怪的原因，使用 fsync() 似乎加快了写入磁盘的代码，而不是像预期的那样减慢它。

一些示例测试代码返回以下结果：

下面是产生这些结果的代码：

我有一段遗留代码在调用以确定目标文件的文件大小fsync之前发出调用。fstat（特别是代码只是从 stat 结构中访问 st_size 。）

看过文档后，我不认为这是一个必要的电话，但我想要专家的意见。

我有两个（POSIX）线程写入这样的日志文件：

该文件main()以fopen()“a”模式打开。在进程运行时，我看不到文件中出现的任何内容，cat或者tail尽管在进程终止并且文件被fclose()-ed 之后，这些行都在那里。

我究竟做错了什么？

我有很多客户得到标题中提到的异常，但我无法在我的任何设备上重现它。

错误报告似乎表明该错误仅发生在索尼设备上，但我似乎找不到任何关于索尼在 Android 上使用他们的数据库做任何有趣事情的报告。

触发此异常的代码正在结束事务

这里的堆栈跟踪是：

数据库驻留在外部存储上（但根据客户报告，它发生在安装外部存储时）：

请不要对代码太苛刻，我知道（例如）应该有一个 try/catch 围绕在 endTransaction 的 sql 语句中，但在这种情况下它没有任何区别（而且我没有获得资源来清理这个遗留的混乱）。

我在 AIX 上发现了一些关于 SQLITE_IOERR_DIR_FSYNC 的旧报告，其中不支持目录上的 fsync() ，但这并没有真正帮助我，因为我显然无法在 Android 上使用正确的编译器标志重新编译 SQLite ...

有任何想法吗？

我已经在装有 Ubuntu 12.04.1 LTS 的机器上安装了 postgresql 9.2.4。根据此文档页面（http://www.postgresql.org/docs/9.2/static/pgtestfsync.html），似乎 *pg_test_fsync* contrib 模块是 postgresql 9.2.4 的一部分。但是当我检查 *pg_available_extensions* 系统视图以及系统/usr/share/postgresql/9.2/extension上的以下位置时，我找不到这个模块。即使在此处的 contrib 文档中也似乎缺少它（http://packages.debian.org/experimental/postgresql-contrib-9.2）。

我错过了什么吗？谁能指导我如何在 postgresql 9.2.4 上测试 'pg_test_fsync' ？

谢谢。

我打算在日志或磁盘队列等系统中使用 fdatasync。首先是在像 ext4 这样的文件系统中创建一个 10MB 的文件，其中包含“000000...”。但我不知道如何正确地做到这一点。

我在 MongoDB 中执行 fsync() 操作，但它只是立即返回。它似乎没有做任何事情。如何验证数据是否确实已刷新到磁盘？

注意：我将 syncdelay 设置为 0，这意味着写入不会每 60 秒自动 fsync 一次。

我的实际命令是使用 perl 驱动程序：

谢谢。

目前我正在编写一个需要在本机端处理大量文件的 Android 应用程序。

最近我在更新或重命名这些文件时遇到了几个数据丢失或不一致的问题。（所有这些文件都存储在公共父/根目录的几个子目录中。）

在阅读了几篇关于 fsync() 的文章后，我决定使用它。但是我有一件事不清楚：

在父目录上调用 fsync() 是否保证递归地同步所有子目录的元数据？

也就是说，假设我对一个公共父目录中不同子目录中的多个文件进行了很多重命名操作。

那么我应该在每个子目录上分别调用 fsync() 还是在父目录上调用 fsync() 足以确保所有子目录（及其子目录递归）的元数据与物理设备同步？

基本上，这个想法是通过避免多次 fsync() 调用来节省时间。或者与每个单独的子目录上的 fsync() 相比，顶级目录上的 fsync() 是否需要更多时间？（假设顶级目录上的 fysnc() 同步所有子目录元数据）

从确保数据在磁盘上的信息（http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-application-developers/），即使在例如断电，在 ​​Windows 平台上，您似乎需要依靠其“fsync”版本FlushFileBuffers才能最好地保证缓冲区实际上从磁盘设备缓存刷新到存储介质本身。FILE_FLAG_NO_BUFFERINGwith的组合FILE_FLAG_WRITE_THROUGH并不能确保刷新设备缓存，而仅对文件系统缓存有影响，如果此信息正确的话。

鉴于我将使用相当大的文件，需要“事务性”更新，这意味着在事务提交结束时执行“fsync”。所以我创建了一个小应用程序来测试这样做的性能。它基本上使用 8 次写入执行一批 8 个内存页面大小的随机字节的顺序写入，然后刷新。批处理循环重复，每写完这么多页，它就会记录性能。此外，它还有两个可配置的选项：在刷新时 fsync 以及是否在开始页面写入之前将字节写入文件的最后一个位置。

我获得的性能结果（64 位 Win 7，慢主轴磁盘）不是很令人鼓舞。似乎“fsync”性能在很大程度上取决于要刷新的文件的大小，因此这占主导地位，而不是要刷新的“脏”数据量。下图显示了小基准应用程序的 4 个不同设置选项的结果。

如您所见，“fsync”的性能随着文件的增长呈指数下降（直到几 GB 时它才真正停止运行）。此外，磁盘本身似乎并没有做很多事情（即资源监视器显示它的活动时间只有大约百分之几，并且它的磁盘队列大部分时间都是空的）。

我显然预计“fsync”性能会比正常缓冲刷新差很多，但我预计它或多或少是恒定的并且与文件大小无关。像这样，它似乎表明它不能与单个大文件结合使用。

是否有人有解释、不同的经验或不同的解决方案来确保数据在磁盘上并且具有或多或少的恒定、可预测的性能？

更新 请参阅下面的答案中的新信息。