fsync 失败的真相:当它返回错误,你的数据可能已经没了
fsync() 返回 EIO 后再调一次为什么会成功?为什么这反而是灾难?从 2018 fsyncgate 到 Linux errseq_t,再到本机内核 6.6 上用 dm-error 单块故障注入的实测,讲清 writeback 失败时脏页被标记 clean、数据静默丢失的真相,以及 PostgreSQL 为什么选择 PANIC。
发布来自土法炼钢兴趣小组的知识、笔记、进展和应用。主题包括数据结构和算法、编程语言、网络安全、密码学等。
共 4 篇文章 · 返回首页
fsync() 返回 EIO 后再调一次为什么会成功?为什么这反而是灾难?从 2018 fsyncgate 到 Linux errseq_t,再到本机内核 6.6 上用 dm-error 单块故障注入的实测,讲清 writeback 失败时脏页被标记 clean、数据静默丢失的真相,以及 PostgreSQL 为什么选择 PANIC。
数据丢失最令人恐惧的形式不是磁盘报错——而是数据悄无声息地变了,没有任何告警,没有任何日志,直到几个月后你从备份里恢复出一堆损坏的文件,才发现"完整性"这个词从来就不是理所当然的。
深入分析存储系统中的数据完整性保障——CRC32C、xxHash、SHA-256 的性能对比,静默数据损坏的检测与防护,端到端校验架构设计
在存储系统的世界里,大多数文件系统把"性能"放在第一位,把"完整性"当作锦上添花的特性。ZFS 的做法恰好相反——它把数据完整性视为最基本的不可协商的属性,然后在此基础上构建性能优化。这种设计哲学上的根本差异,使得 ZFS 在诞生近二十年后,仍然是数据保护领域无可替代的存储栈。