文件系统写入缓冲区通常在几秒后被刷新？答案

【问题标题】：After how many seconds are file system write buffers typically flushed?文件系统写入缓冲区通常在几秒后被刷新？
【发布时间】：2012-11-18 23:08:11
【问题描述】：

在覆盖文件中的数据之前，我想确定旧数据是否存储在磁盘上。它可能是一个非常大的文件（数 GB），因此需要就地更新。通常写入将是 2 MB 或更大（我的计划是使用 4 KB 的块大小）。

代替（或除此之外）调用 fsync()，我想保留（不覆盖）磁盘上的旧数据，直到文件系统写入新数据。我不想依赖 fsync() 的主要原因是：most hard disks lie to you about doing an fsync.

所以我正在寻找的是文件系统、操作系统（例如 Windows）、硬盘驱动器在不使用 fsync 或类似方法将数据写入磁盘之前的典型最大延迟。如果可能的话，我想拥有真实世界的数字。我不是在寻求使用 fsync 的建议。

我知道没有 100% 可靠的方法可以做到这一点，但我想更好地了解操作系统和文件系统在这方面的工作原理。

到目前为止我发现的是：30 seconds is / was the default for /proc/sys/vm/dirty_expire_centiseconds。然后是“dirty pages are flushed (written) to disk ... (when) too much time has elapsed since a page has stayed dirty”（但我找不到默认时间）。所以对于 Linux，40 秒似乎是安全的。但这适用于所有文件系统/磁盘吗？ Windows、Android 等呢？我想得到一个适用于所有常见操作系统/文件系统/磁盘类型的答案，包括 Windows、Android、普通硬盘、SSD 等等。

【问题讨论】：

只是一个问题：你为什么要写入你要丢弃的数据？
您可能还想在您的fsync(2) 系统调用之后使用sync(2) 或syncfs(2) 系统调用，并且您可能还需要谨慎使用sync_file_range(2)。
请注意，“默认”值（由操作系统内核定义，或由分发打包程序通过启动脚本定义）无法保证。特定系统可能具有完全不同的值有很多正当的原因，因为管理员已经以这种方式对其进行了调整。在不必做出这样的假设的情况下弄清楚如何解决您的问题可能会更好......
@NikosC。我正在写图书馆。无法控制应用程序调用什么方法的库。
@BasileStarynkevitch 您是否阅读了问题中的文章“大多数硬盘对您撒谎以进行 fsync”？ fsync 和相关方法不是一个可靠的解决方案，我不想依赖它们。此外，它们并非在所有操作系统上都可用。

标签： file file-io filesystems data-persistence

【解决方案1】：

让我用稍微有点不友好的术语重申您的问题：您正试图控制其在操作系统中的驱动程序无法控制的物理设备的行为。如果你想要的是一个实际的保证，而不是一个很好的猜测，那么你试图做的似乎是不可能的。如果您想要的只是一个很好的猜测，那很好，但请注意这一点并相应地记录。

您也许可以使用正确的设备驱动程序来解决这个问题。例如，SCSI 协议在其READ 和WRITE 命令中有一个Force Unit Access (FUA) 位，用于指示设备绕过任何内部缓存。即使数据最初是缓冲写入的，读取未缓冲的数据也应该能够验证它确实存在。

【讨论】：

我不是要主动控制行为，我只是想知道典型的行为是什么。特别是，我想知道在不使用 fsync 的情况下，大多数数据在磁盘上结束的几秒后。尝试在不使用缓冲区的情况下从磁盘读取数据是一个聪明的想法，但不幸的是没有跨平台的方法来实现这一点。
当您说“我想确保旧数据存储在磁盘上”时，这听起来像是硬保证，这意味着您需要控制磁盘写入的某些方面，或者更详细地说限制磁盘的行为远离某些禁止的行为。如果你不（或不能）控制它，你就不能提供硬性保证。这就是我通过适当记录它的意思。
我知道可能无法为所有操作系统和硬盘获得硬质保证。我只是想尽可能多地了解事实。
这是为 Windows 2000 编写的，但仍然主要相关：msdn.microsoft.com/en-us/library/bb742613.aspx#ECAA
特别是：“一个较旧的缓存管理器实用程序 [来自 SysInternals] 记录了惰性写入算法中使用的一些内部常量 [...]。其中包括 CcFirstDelay，它在写入后延迟写入三秒第一次访问；CcIdleDelay，触发写入一秒进入空闲期；和 CcCollisionDelay，如果推测性延迟写入遇到磁盘繁忙条件，则触发 100 毫秒延迟。在撰写本文时，不确定这些参数是否控制缓存管理器的操作被带到了 Windows 2000 中，但看起来很可能是这样。”

【解决方案2】：

可靠地确保数据已同步的唯一方法是使用操作系统特定的同步机制，并按照PostgreSQL's Reliability Docs。

当操作系统向存储发送写请求时硬件，几乎无法确保数据已到达在一个真正的非易失性存储区域。相反，它是管理员有责任确保所有存储组件确保数据完整性。

所以不，没有真正可移植的解决方案，但可以（但很难）编写可移植的包装器并部署可靠的解决方案。

【讨论】：

我正在寻找“数据最多在 30 秒后写入磁盘”类型的答案。此链接不回答此问题。
如果没有刷新和配置，答案是它可以任意长，因为理论上磁盘缓冲区可以永久保留一个写入请求，等待其他通过写入加速刷新它的请求。
你有链接来备份这个吗？
根据我找到的文档（参见上面的链接，“将脏页写入磁盘”），对于 Linux，您错了，脏页被“刷新（写入）到磁盘...自从页面保持脏状态以来已经过去了太多时间”，设置为dirty_expire_centiseconds。但是如果你有链接说数据可能永远不会被写入，请发布它！另外，我正在寻找其他操作系统 (Windows) 和文件系统（特别是 SSD）的工作原理的信息。
我相信磁盘会在几秒钟内写入数据。如果您说某些磁盘可能需要几分钟，那么如果您能提供一个链接会很好。我真的会对它的实际工作原理感兴趣，而不是猜测......

【解决方案3】：

首先感谢硬盘关于刷新数据的信息，这对我来说是新的。

现在解决您的问题：您要确保写入的所有数据都已写入磁盘（最低级别）。您是说需要控制两个部分：操作系统写入硬盘的时间和硬盘写入磁盘的时间。

您唯一的解决方案是使用模糊逻辑计时器来估计何时写入数据。

在我看来，这是错误的方式。您可以控制操作系统何时写入硬盘驱动器，因此请使用并控制它！那么只有说谎的硬盘是你的问题。这个问题不能可靠地解决。我认为，您应该告诉用户/管理员，他在选择正确的硬盘驱动器时必须小心。当然，实现您建议的附加计时器可能是个好主意。
我相信，您可以开始使用不同的硬盘驱动器和 Brad Fitzgerald 的工具进行一系列测试，以便很好地估计硬盘驱动器何时会写入所有数据。但当然——如果硬盘想撒谎，你永远无法确定数据是否真的已写入磁盘。

【讨论】：

是的，测试这是要走的路，我会这样做。我知道这无法可靠地解决，但我想获得有关已知延迟的更多信息，例如 Linux 中的dirty_expire_centiseconds。我会尝试重新表述这个问题。

【解决方案4】：

为用户提供响应式系统涉及很多缓存。

有cpu缓存、内核/文件系统内存缓存、磁盘驱动器内存缓存等。你问的是刷完所有缓存需要多长时间？

或者，另一种看待它的方式是，如果磁盘驱动器坏了会发生什么？所有刷新都不能保证成功的读取或写入操作。

磁盘驱动器最终会变坏。您正在寻找的解决方案是如何拥有一个冗余的 CPU/磁盘驱动器系统，以使系统在组件故障后仍能继续工作。

您可以提高系统在 RAID 阵列和其他高可用性配置等硬件的帮助下继续工作的可能性。

就软件解决方案而言，我认为答案是，相信操作系统会做最优化的事情。他们中的大多数定期刷新缓冲区。

【讨论】：

我更感兴趣的是“通常需要多长时间”，而不是“可能发生的最糟糕的事情是什么”

【解决方案5】：

这是一个老问题，但在 2019 年仍然相关。对于 Windows，基于this，答案似乎是“至少每隔一秒”：

为确保进行适量的刷新，缓存管理器每秒生成一个称为惰性写入器的进程。惰性写入器进程将最近未刷新的页面的八分之一排队以写入磁盘。它不断地重新评估要刷新的数据量以获得最佳系统性能，如果需要写入更多数据，它会将更多数据排队。

要清楚，上面说懒惰的作家是在每一秒之后产生，这与每秒写出数据不同，但这是迄今为止我自己能找到的最好的搜索类似问题的答案（在我的情况下，我有一个 Android 应用程序可以将数据延迟写入磁盘，我注意到使用 3 秒的间隔时会丢失一些数据，所以我将其减少到 1 秒看看这是否有帮助...它可能会损害性能，但如果您考虑 恢复数据所需的时间，丢失数据会更严重地影响性能。

【讨论】：