【RocksDB 内核机制】WAL 与 WriteBatch：持久化与原子批写
从 log::Writer 的 32KB Block 分片 record、WriteBatch 二进制布局，到 DBImpl::WriteImpl 中 Group Commit 与 sync/fsync 语义，钉住写路径第一步：先 WAL 后 MemTable 的提交顺序与原子性边界。
fsync 标签归档
共 6 篇文章 · 返回首页
fsync 失败的真相：当它返回错误，你的数据可能已经没了
fsync() 返回 EIO 后再调一次为什么会成功？为什么这反而是灾难？从 2018 fsyncgate 到 Linux errseq_t，再到本机内核 6.6 上用 dm-error 单块故障注入的实测，讲清 writeback 失败时脏页被标记 clean、数据静默丢失的真相，以及 PostgreSQL 为什么选择 PANIC。
【存储工程】数据完整性：从 fsync 到端到端校验
数据丢失最令人恐惧的形式不是磁盘报错——而是数据悄无声息地变了，没有任何告警，没有任何日志，直到几个月后你从备份里恢复出一堆损坏的文件，才发现"完整性"这个词从来就不是理所当然的。
【PG 内核】配置陷阱与生产最佳实践：11 个最危险的 GUC 和它们的正确设置
逐一拆解 11 个最容易被误解和配错的 PostgreSQL GUC 参数：shared_buffers 的 double buffering 反噬、work_mem 作为'每个操作'而非'每个查询'的内存炸弹、effective_cache_size 和 random_page_cost 如何误导优化器走向灾难计划、fsync=off 和 synchronous_commit=off 的数据丢失边界、huge_pages 在容器中的静默退化、maintenance_work_mem 不足导致 VACUUM 瘫痪、idle_in_transaction_session_timeout 为什么必须设、log_lock_waits 与 deadlock_timeout 的联动、以及 log_min_duration_statement 与 auto_explain 的日志洪水叠加。每条配查验 SQL 和 shell 命令——不是'设成 X 就好了'，而是'通过什么视图和日志确认当前设置有问题'。
【存储工程】Direct I/O 与 O_DIRECT：绕过缓存的得与失
在 Linux 的传统 I/O 路径中，应用程序通过 read() 和 write() 系统调用与文件交互时，数据并不会直接在用户空间缓冲区（User Buffer）和磁盘之间传输。内核会在两者之间插入一层页缓存（Page Cache），作为磁盘数据在内存中的缓存副本。一次典型的写入流程如下：
【存储工程】写入性能优化
深入分析存储写入性能优化——WAL 分组提交、批量写入、Write Buffer 调优、fsync 频率控制、写入限速与写停顿分析