Linux 7.1 来了:新 NTFS 驱动、干掉 i486、FRED 默认开启,这次更新有点东西
- 2026-06-30 05:58:59
上周末 Linus 把 7.1 推出来了。说实话，一般 .1 版本我不太会单独写文章聊，但这次翻了一下 changelog，发现几个改动还挺有意思的，尤其是搞存储和运维的兄弟可能会比较关注。
先说最让我兴奋的——新的 NTFS 驱动终于合进主线了。
NTFS 驱动重写：不只是"能写了"这么简单
做过双系统或者处理过 Windows 磁盘数据迁移的应该都知道，Linux 下挂 NTFS 一直是个半残废状态。内核自带的老 NTFS 驱动只能读，想写得靠 ntfs-3g。那个 FUSE 方案用过的都懂——每次 I/O 都要在用户态和内核态之间来回切换，大文件拷贝的时候 CPU 占用高得离谱，实际吞吐量也就机械硬盘的水平，就算你底下是 NVMe 也白搭。
这次 7.1 合进来的新驱动是 Namjae Jeon 搞了四年的成果。不是在 NTFS3 上打补丁，是基于现代内核基础设施重新实现的。技术架构上有几个关键变化值得展开说：
第一，用 iomap 取代 buffer_head。
这个变化对熟悉内核文件系统开发的人来说意义很大。buffer_head 是 Linux 内核里非常古老的 I/O 抽象层，每个 block 对应一个 buffer_head 结构体，管理脏页、回写、映射关系。问题是这套东西太重了——一个 4KB 的页面对应一个 buffer_head，一个大文件可能产生成千上万个 buffer_head 链表节点，内存开销和遍历开销都很可观。
iomap 是现代替代方案。它不再按 block 粒度管理，而是按 extent（连续区间）来做映射。文件系统只需要告诉 iomap 层"这段文件偏移对应磁盘上哪段连续区域"，后面的 buffered I/O、direct I/O、writeback 全都由 iomap 框架统一处理。XFS 最早用这套，后来 ext4 也在逐步迁移。
对于 NTFS 驱动来说，换到 iomap 意味着：
• 大文件顺序读写性能显著提升（减少了元数据管理开销） • 内存占用更低（不用维护海量 buffer_head 链表） • writeback 路径更短、更干净
第二，folio 转换。
folio 是 5.16 开始引入的页面管理抽象，用来替代 struct page。简单说就是把 compound page（多个物理页组成的大页）当作第一公民来处理，而不是每次都要判断"这个 page 是不是某个 compound page 的尾页"。
新 NTFS 驱动原生支持 folio，意味着在大页（huge page）场景下效率更高，pagecache 管理也更现代化。内核文档里已经明确说了：buffer_head is deprecated, new filesystems should use iomap instead。这个新驱动从设计上就走了正确的路。
第三，实际测试数据。
新驱动通过了 326 个 xfstests 用例，之前的 NTFS3 是 273 个。差的这 53 个用例覆盖了 fallocate、idmapped mounts、权限控制等场景，都是生产环境里真会遇到的东西。
# 新驱动的 Kconfig 选项
CONFIG_NTFS_FS=m
# NTFS3 暂时还保留着，但内核文档已经指向新驱动
# 未来 NTFS3 大概率会被标记 deprecated
# 配套的用户态工具
# ntfsprogs-plus 提供了 fsck.ntfs 等
# 之前 ntfs-3g 那套工具依赖 FUSE，新方案不需要还有个小插曲——Linus 在合并的时候因为 Git 树的结构问题把代码 un-pull 了一次。具体原因是 pull request 的 commit 组织方式不对，Linus 要求重新 rebase 后才接受。他给的评价是 "ntfs resurrection"，复活。这个词用得确实到位。
对运维的实际影响：如果你的工作涉及 Windows/Linux 混合存储环境——比如跨平台的 NAS、双系统数据盘、或者从 Windows 服务器迁移数据——升级到 7.1 之后可以直接 mount NTFS 分区读写，不需要再装 ntfs-3g，性能和稳定性都有本质提升。
Intel FRED：四十年来最大的中断处理改革
FRED 全称 Flexible Return and Event Delivery。7.1 之前需要手动加 fred=on 启动参数，7.1 开始默认开启。
先说这东西解决什么问题。
x86 的中断处理机制依赖一个叫 IDT（Interrupt Descriptor Table）的结构，这玩意儿是 80286 时代设计的，距今 40 多年了。整个流程大概是这样：
CPU 收到中断/异常
→ 查 IDT 找到对应的 handler 地址
→ 根据 DPL/CPL 判断是否需要切换特权级
→ 如果要切换，从 TSS 里取新的 SS:RSP
→ 压栈：SS, RSP, RFLAGS, CS, RIP（可能还有 error code）
→ 跳到 handler
→ handler 处理完后 IRET 返回
→ IRET 反向恢复所有寄存器和栈看起来清晰，但实际写过内核中断处理代码的都知道这里面坑有多深：
1. IRET 指令不是原子的。 它恢复 SS 和 RSP 的时候如果中间又来了中断，状态可能不一致。内核为了规避这个问题写了大量的 workaround 代码。 2. ring 切换的开销。 从 ring 3 到 ring 0 的 transition 要读 TSS、切栈、压一堆寄存器，每次中断都来这么一套。 3. 特权级有四个（ring 0-3），但实际只用了两个。 ring 1 和 ring 2 几乎没有 OS 在用，但 IDT 的设计要兼顾所有情况，增加了无谓的复杂度。 4. 缺少对嵌套中断的良好支持。 NMI 嵌套、#MC 嵌套等场景需要各种 IST（Interrupt Stack Table）hack。
FRED 怎么解决这些问题？
它把事件分成两种入口：ring 0（内核态事件）和 ring 3（用户态事件），各自有独立的处理路径。核心改变：
• 用 ERETS/ERETU 替代 IRET。 ERETS 用于内核态返回（supervisor），ERETU 用于向用户态返回。两条指令语义清晰，不需要 IRET 那样靠栈内容来判断返回目标。 • 事件入口固定，不再查 IDT。 CPU 直接根据事件类型和当前特权级跳到预设地址，减少了一次内存读取。 • 栈帧格式统一。 所有事件共用一个标准化的栈帧布局，包含 event type、error code、原始 CS/RIP/RFLAGS/SS/RSP，不用再 case-by-case 处理。 • 原子性保证。 FRED 的 transition 是单指令完成的原子操作，不存在中间状态被打断的问题。
AMD 也宣布 Zen 6 会支持 FRED。Linus 在邮件列表里公开表态支持 FRED 方案，说它是 "a more complete clean-room solution that gets rid of legacy cruft entirely"。
对性能的影响主要体现在：
• I/O 密集型场景：每秒中断次数多的负载（高频网络包、存储 IOPS）受益最大 • 虚拟化：VM exit/entry 涉及大量 ring transition，FRED 减少了每次 transition 的 cycle 数 • 实时性：中断延迟更低且更可预测
# 验证 FRED 是否生效
dmesg | grep -i "fred"
# 预期输出类似：
# x86/fred: FRED enabled
# 如果你的 CPU 不支持 FRED，这行不会出现
# 目前只有 Intel Panther Lake / Arrow Lake 以及未来的 AMD Zen 6 支持
# 如果想关闭（比如怀疑兼容性问题）
# 内核启动参数加 fred=offPhoronix 在 Panther Lake 上的测试表明，FRED 开启后 I/O 密集型 benchmark（fio randread/randwrite、nginx 高并发）有单位数百分比的性能提升。看起来不多，但考虑到这是"免费的"——不需要改任何应用层代码，只是升了个内核——还是很香的。
告别 i486：一个 37 年的句号
7.1 正式移除了 i486 的构建支持。M486、M486SX、MELAN 这几个 Kconfig 选项被删除，你没法再编译出一个能在 486 上跑的内核了。
这是继 2012 年砍掉 i386 支持之后，Linux 第二次移除一个主要的 x86 子架构。
Linus 的态度很明确："zero real reason to continue support"。Ingo Molnar 在去年 4 月提出这个 patch 的时候给的理由也很充分——为了兼容 486，内核里有一些模拟指令和条件编译路径，比如 486 不支持的某些 CPUID 指令需要用软件模拟、缺少 CMPXCHG8B 的 fallback 实现等等。这些代码不仅占空间，还会偶尔引入难以复现的 bug。
// 以前内核里这类代码到处都是
#ifdef CONFIG_M486
/* i486 doesn't support this, use software fallback */
...
#endif
// 现在可以全部干掉了实际影响对绝大多数人为零。但从代码卫生的角度，每砍掉一块死代码意味着：
• 减少编译时的条件分支（CI 测试矩阵变小） • 原子操作相关的代码可以直接用 CMPXCHG8B/CMPXCHG16B，不用 fallback • lock prefix 相关的优化可以更激进
复古玩家不用慌，LTS 内核照样跑，只是主线不管了。
QAT Zstd 硬件卸载：日志压缩场景的福音
这个改动比较细但对特定场景非常有用。
Intel QAT（QuickAssist Technology）是集成在 Xeon 里的硬件加速器，主要做两件事：加解密和压缩解压缩。之前内核里的 QAT 驱动只支持 deflate 算法，7.1 加了 Zstd 支持。
具体来说：
• Gen4/Gen5 QAT（4th/5th Gen Xeon）：基本的 Zstd 压缩卸载 • Gen6 QAT（Diamond Rapids 平台）：原生 Zstd 实现，覆盖压缩和解压缩
为什么这个有用？举个真实场景：
假设你有一个日志收集管道 —— 几百台机器的日志通过 Filebeat 采集，中间经过 Kafka，最终写入对象存储或者 Elasticsearch。日志在传输和存储前通常会做压缩。如果用 CPU 做 Zstd 压缩，假设单核 Zstd level 3 能跑到 400-500 MB/s，听起来不错，但当你有几十个 TB 日志要处理的时候，压缩这一步就得吃掉好几个核。
QAT 硬件卸载的意思是把压缩操作丢给专用加速器，CPU 核心完全不参与。根据 Intel 的数据，QAT 在 deflate 场景下能释放 43% 的 CPU 占用。Zstd 场景虽然官方还没有公开 benchmark，但原理一样。
# 检查系统是否有 QAT 设备
lspci | grep -i "quickassist\|qat"
# 预期看到类似：
# 76:00.0 Co-processor: Intel Corporation Device 4944
# 内核模块
modprobe intel_qat
modprobe qat_4xxx # Gen4
# 验证设备就绪
cat /sys/bus/pci/drivers/4xxx/*/qat/state
# 预期输出: up对运维的建议：如果你管的机器是 4th Gen Xeon 以上，而且有大量压缩需求（日志、备份、数据传输），可以调研一下 QAT 加速。虽然 7.1 目前只是加了内核层面的支持，应用层（比如 zstd 命令行工具或者各种框架的 codec）还需要适配 QAT plugin 才能真正用上，但路已经铺好了。
其他运维相关改动速览
AMD amd-pstate 驱动：加了三个新特性——CPPC Performance Priority 允许给不同核设不同的优先级；Dynamic EPP 可以根据负载动态调整能效策略；Raw EPP 给你直接写寄存器的能力。如果你在 EPYC 上跑混合负载（比如同一台物理机上既有延迟敏感的数据库又有吞吐型批处理），这些提供了更细粒度的调控手段。
ARM32 RT 内核：32 位 ARM 现在可以不打 out-of-tree 补丁直接编译 PREEMPT_RT 内核。嵌入式和工控场景的兄弟终于不用自己 backport 了。
AMDGPU GCN 1.1 支持：Kaveri/Mullins 这些老 APU 现在能用 AMDGPU 驱动（之前只能用 radeon 驱动）。如果你还有一批这类芯片的瘦客户端或工控机在服役，升级内核之后显示稳定性会好很多。
网络驱动：新增 Realtek RTL8157（2.5G USB 网卡）支持。如果你买过那种 USB-C 转 2.5G 网卡的加密狗，可能之前在 Linux 下不好使，现在应该能直接识别了。
Scheduler 改进：一些调度器的 bugfix 和微优化。7.2 里会有更重磅的 Cache Aware Scheduling，这个值得到时候单独聊一篇。
升级建议
滚动发行版（Arch、Fedora）：正常更新，这周应该就推过来了。
企业发行版（RHEL/Rocky/Alma/Ubuntu LTS）：别急。等厂商测试完打包好再说，除非你有明确的 blocker 需要 7.1 解决。
手动编译：只建议在测试环境玩，或者你明确知道自己需要某个新特性。
# 查看当前版本
uname -r
# 想尝鲜的话
# 1. 从 kernel.org 下载 7.1 tarball
# 2. cp /boot/config-$(uname -r) .config
# 3. make olddefconfig (继承当前配置，新选项用默认值)
# 4. make -j$(nproc)
# 5. make modules_install && make install
# 6. update-grub 或者 grub2-mkconfig
# 7. 重启选新内核
# 不过说真的，在生产环境别这么干7.1 整体来看是一个质量很高的功能版本。NTFS 驱动填补了一个十几年的坑，FRED 对新硬件的中断处理性能有实质性改善，QAT Zstd 给特定场景提供了硬件加速路径。下个版本 7.2 的 merge window 已经开了，Cache Aware Scheduling 和 Rust Zerocopy 看起来都很有意思。
如果觉得这篇文章对你有帮助，欢迎点赞、转发、在看三连，让更多人看到。
公众号：耕云躬行录
个人博客：躬行笔记
