Linux：6.1.64-1 中的 Ext4 数据损坏

Bug 的范围与性质

• 在某些 Linux 6.1 稳定内核中，使用直接 I/O（O_DIRECT）时会发生 ext4 数据损坏，这是由于一个回溯移植的 ext4 变更依赖于另一个并未回溯移植的直接 I/O 变更。
• 如果两个提交都存在（例如在较新的内核中），行为就是正确的；如果只有 ext4 提交存在（例如 6.1.64/65），写入可能会落到错误的偏移位置。
• 这种损坏被描述为“非灾难性”的：文件系统元数据保持完好，但单个文件的内容可能会被静默损坏，这对使用 O_DIRECT 的 VM 镜像和数据库尤其糟糕。

上游 vs Debian 的责任

• 多条评论强调，这是一项上游稳定内核 bug，不是 Debian 单独打补丁的问题；Debian 跟踪的是 kernel.org 的稳定版发布。
• 线程中有一些混淆；其他人通过内核变更日志和邮件列表链接澄清，指出上游 6.1.64 受影响，而 6.1.66 包含修复。
• 据说一些 Ubuntu 内核不受影响，因为它们默认并不提供 6.1。

对稳定内核流程的批评

• 有人强烈批评大量回溯移植的模式：成千上万的提交被拉入较旧的 LTS 分支，带来非平凡的依赖风险。
• 有人担心“稳定”内核变化太快，如今甚至比 Debian 的其他部分更不稳定；一些人宁愿只运行最新的 mainline 内核。
• 相关事件：6.1.66 中另一个缺失的依赖补丁破坏了 Wi‑Fi，后来在 6.1.67 中修复，这进一步加深了对该流程的怀疑。

Debian 的处理与更新

• 用户抱怨即使已知这个严重 bug，unattended-upgrades 还是拉取了这个坏内核。
• 解释是：Debian 的仓库工具并不是为即时撤销而设计的；新的内核必须为许多架构构建，然后传播到每天只同步几次的镜像站。
• 讨论中的变通方法包括：用 apt preferences 文件固定 6.1.64-1、启动较旧的内核，以及通过停止/禁用 .timer 单元或重新配置软件包，正确关闭 unattended-upgrades。

文件系统与恢复

• 一些人认为这削弱了 ext4 天然比 ZFS 或 btrfs 更安全的说法；另一些人强调，所有文件系统都有 bug。
• ext4 因其成熟的 fsck 和简单的元数据布局而受到称赞，据称这使它几乎能从任何损坏中恢复；怀疑者质疑这实际上能挽救多少真实的用户数据。

严重性与“非严重数据丢失”

• 讨论集中在 Debian 的术语上：“grave” 与 “non-serious data loss”，以及能否通过 fsck（或备份）修复的损坏，在实践中是否算“可恢复”。
• 重点指出，静默损坏尤其危险，因为备份也可能静默地把坏数据一起保存下来。