我刚刚听说吃我的数据fsync，当不需要数据安全（测试、CI 构建等）时，它可以加快速度：
libeatmydata 是一个小型 LD_PRELOAD 库，旨在（透明地）禁用 fsync（以及 open(O_SYNC) 等朋友）。这有两个副作用：使将数据安全写入磁盘的软件速度更快，并使该软件不再崩溃。
这是 2007 年的作品，但仍然在 Github 上积极维护。但是，并非所有发行版都包含它；例如，Fedora 有一个不同步包，它或多或少是等效的（它不包含包装器命令，而是需要使用LD_PRELOAD）。
但是，在不同的机器（一台带有 HDD，另一台带有 SDD）上尝试了几种工作负载之后，无论是在 Ubuntu 还是 Fedora 上，执行时间的差异都可以忽略不计：2 小时的任务大约需要 5 秒；2 分钟的任务大约需要 0.5 秒；等等。根据 Google 的结果，老用户报告执行时间有非常大的改善。
从那时起是否发生了什么事情，使得这种“优化”变得没有必要？最近的操作系统在处理方面是否更智能fsync？是否存在一些易于测试的工作负载，其中仍然可以观察到较大的差异？
答案1
当不需要数据安全时（测试、CI 构建等）：
测试和 CI 构建通常不经常使用显式 fsync。据我所知，eatmydata 最常见的用途是以下情况：每一个文件。将在继续执行下一个操作之前单独进行 fsync。两个示例是 的解包阶段apt-get和 SVN 中的各种操作（例如svnsync sync）。
最近的操作系统在处理 fsync 方面是否更智能？
文件系统可能会以不同的方式处理它，例如，如果我没记错的话，ext4 的工作方式使得单个文件的 fsync 比通常更加全局（以及最近添加的“快速提交”功能应该会对此进行改进），但在 XFS 上可能并非如此。
请注意，这里的“全球”意味着其他在同一台机器上运行的作业也会产生影响 - 例如正在写入的日志文件，或者任何产生大量写入但仍然处于缓冲状态的近期任务，并且尝试 fsync() 单个文件最终也会刷新这些不相关的 GB 写入。当您使用完全专用的空闲系统进行基准测试时，您不会看到这种情况......