fsync 失败的真相：当它返回错误，你的数据可能已经没了
内容提要
fsync() 的使用存在误区，尤其在失败时重试可能导致数据丢失。PostgreSQL 社区发现，fsync() 失败后，脏页被标记为干净，重试返回成功但数据未写入磁盘。应用应在 fsync() 失败时崩溃重启，以确保数据安全。
关键要点
-
fsync() 失败时，脏页被标记为干净，导致数据丢失。
-
重试 fsync() 可能会返回成功，但数据并未写入磁盘。
-
PostgreSQL 社区发现 fsync() 的错误处理存在安全隐患，建议在失败时崩溃重启。
-
POSIX 对 fsync() 失败后的状态规定模糊，导致开发者误解其行为。
-
不同文件系统在 fsync() 失败时的行为不一致，可能导致数据丢失。
-
应用应在 fsync() 失败时不再重试，而是采取崩溃恢复策略。
-
恢复逻辑应依赖磁盘的持久状态，而非页缓存中的数据。
-
使用 O_DIRECT 可以绕过页缓存，降低数据丢失风险。
-
故障注入测试应纳入应用开发流程，以确保数据安全性。
延伸解读
fsync() 失败的潜在风险
fsync() 失败后，脏页被标记为干净，导致数据丢失。开发者在处理 fsync() 错误时，重试操作可能会误导他们认为数据已安全写入。了解这一点对于确保数据完整性至关重要，尤其是在关键应用中。
不同文件系统的行为差异
不同文件系统在处理 fsync() 失败时的行为存在显著差异。例如，ext4 和 XFS 在失败后都会将脏页标记为干净，而 Btrfs 则会回退到磁盘上的一致版本。这种差异可能影响应用的恢复策略，开发者需根据具体文件系统的特性来设计数据保护机制。
崩溃恢复策略的重要性
PostgreSQL 社区建议在 fsync() 失败时采取崩溃恢复策略，而非重试。这一做法确保了数据的持久性和一致性，避免了因错误处理不当导致的数据丢失。开发者应考虑在应用中实现类似的策略，以增强数据安全性。
延伸问答
fsync() 失败时应该如何处理？
在 fsync() 失败时，应用应崩溃重启，而不是重试，以确保数据安全。
为什么重试 fsync() 可能导致数据丢失？
重试 fsync() 可能返回成功，但脏页已被标记为干净，导致数据未写入磁盘而丢失。
PostgreSQL 如何应对 fsync() 失败？
PostgreSQL 在 fsync() 失败时会触发 PANIC，崩溃重启并用 WAL 重放来恢复数据。
不同文件系统在 fsync() 失败时的行为有何不同？
不同文件系统如 ext4、XFS 和 Btrfs 在 fsync() 失败时的错误上报和脏页处理方式各不相同，可能导致不同的安全隐患。
如何降低 fsync() 失败导致的数据丢失风险？
使用 O_DIRECT 可以绕过页缓存，降低数据丢失的风险，同时恢复逻辑应依赖磁盘的持久状态。
fsyncgate 事件的背景是什么？
fsyncgate 是指 PostgreSQL 社区在 2018 年发现的 fsync() 错误处理不当，导致数据丢失的事件。
