香港服务器要不要升 Linux 7.2 内核？先看清楚你跑的是不是 Btrfs
Linus 在 8 月 16 日放出了 Linux 7.2 正式版。稿子传到中文圈以后，被反复引用的是两个数字：写入吞吐最高 +59%，顺序写 +15%。工单里很快就有人来问，我的香港服务器要不要升。
这两个数字是真的，出处也确实是 7.2 的更新记录。但它们有个前提，转述的时候几乎都被吃掉了。
59% 和 15% 是 Btrfs 的，不是所有人的
翻一下 7.2 的 Btrfs 变更就很清楚：一条是不再强制串行执行 direct I/O 写，官方给的观测值是 DIO 吞吐提升约 59%；另一条是限制回写路径提交的 bio 大小，顺序写改善约 15%。两条都挂在 Btrfs 名下，不是块层或 VFS 的通用改进。
问题是，香港机房交付的机器有多少在跑 Btrfs？我们这边的实际情况是接近于零。客户拿到机器，装 AlmaLinux、Ubuntu 或者直接上宝塔，分区一路默认下来是 ext4，少数做大容量存储的会选 XFS。真正主动把数据盘做成 Btrfs 的，一年也见不到几个。
所以对绝大多数人来说，这两个数字的实际收益是 0。
反过来说，如果你确实在用 Btrfs 做快照式备份或者多子卷管理，这一版是值得认真测的：large folios 从 6.17 的实验特性转为默认开启，而且没有功能限制，另外还加了最高 2M 的 huge folio 实验支持。这类高存储服务器上的备份节点，是 7.2 少数几个能拿出明确收益的场景。
ext4 和 XFS 用户，真正该看的是内存回收那条
被标题数字盖过去的，是 MGLRU 这次的改动。7.2 重写了它的回收循环和脏页回写处理，官方给出的参考数据是：MongoDB 跑 YCSB 这类负载最高约 30% 提升，file refault 大幅下降，而且整个过程不涉及 swap。
这条跟文件系统无关，跟你用什么发行版也无关。数据库、缓存、内存吃得紧的应用节点都可能吃到，覆盖面比 Btrfs 那两条宽得多。
同一版里还有几条同样偏实用的：ext4 对 fast commit 做了较大重构，主要解决锁竞争和死锁；iomap 在迭代结束后省掉一次多余的 memset，4K 随机读 + NVMe + io_uring 轮询这种高 IOPS 场景下，ext4 和 XFS 的 IOPS 约有 5% 改善；XFS 的 zoned allocator 去掉了实验标记；swap table 第四阶段把静态元数据开销压到接近零，挂 1TB swap 设备能省下大约 512MB 内存。
单看每一条都不惊人，但它们的共同点是不挑文件系统。真要评估 7.2 值不值，该看的是这一组，不是那个 59%。
缓存感知调度：多核机器值得实测，别指望立竿见影
7.2 最被官方强调的特性是缓存感知调度（Cache Aware Scheduling）。思路是让共享数据的任务——通常就是同一个进程的多个线程——尽量待在同一个 LLC 域里，减少 cache bouncing 和 cache miss。
谁可能受益：MySQL、PostgreSQL、多进程 API 服务、KVM 宿主机、跑满核的编译和转码任务。这些负载的线程之间确实在共享数据，调度器少搬几次家是有意义的。
谁基本没感觉：CPU 常年 20% 利用率的企业展示站、日均几千 IP 的 WordPress。这类站点的瓶颈从来不在内核调度——是 PHP-FPM 进程数、没走缓存的慢查询，以及回国线路的抖动。换个内核解决不了其中任何一个。
顺带提醒一句：不少转载稿里还写着 7.2 带来了"更公平的 DRM/GPU 调度器"。那部分代码在发布前最后一周被回退掉了，正式版里没有。跑 GPU 业务的不要照着这条做规划。
NFS 和 SMB 的改动，前提比结论重要
7.2 把 NFSD 的默认读写块大小提到了 4MB，但有两个限定条件：一是要求主机内存不低于 16GB，内存更小的机器保持原有计算值；二是这个值本来就可以通过 /proc/fs/nfsd/max_block_size 调，也就是说想用大块传输，不必等 7.2。
SMB 这边是内核态服务端（ksmbd）加了压缩文件属性处理和 SMB2 读响应压缩，跨机传大文件、传备份的场景确实有意义。
但更该先问自己的是：多机部署之间到底走的是不是内核态 NFS/ksmbd。以我们看到的情况，多数客户的香港服务器集群其实是 rsync、rclone 或者对象存储在扛跨机传输，NFS 只用来挂个共享目录。那这一版的网络文件系统改进跟你关系不大。
最现实的问题是：你现在根本装不到它
前面聊的都是"值不值"，但对租机器的人来说，还有一个更前置的问题——7.2 是主线内核，不是发行版内核。
Ubuntu 26.10 会带它；Ubuntu 26.04 LTS 要等 HWE 栈，大概是 2027 年初；RHEL 系和 Debian stable 这一轮基本不会跟，只会把安全修复回合到现有内核上。也就是说，如果你的机器装的是 AlmaLinux、Rocky、Debian 或者 Ubuntu LTS，7.2 短期内不会出现在你的 dnf update 或 apt upgrade 里。
想现在就用，只有两条路：装 Canonical 的 mainline .deb 或第三方 PPA，或者自己编译。两条路的共同代价是丢掉发行版自带的补丁集和支持——驱动、安全特性、内核模块都可能对不上，出了问题也很难走正常的支持流程。
我们的建议很直接：生产机不要这么干。业务跑在租来的机器上，为了几个还没在你自己负载上验证过的百分比，去换一个不受发行版支持的内核，风险和收益完全不成比例。
真要测，先把回退路径修好
想验证的话，找一台闲置机或者按小时计费的实例复制环境，不要在生产上直接动手。几个容易被跳过的点：
云实例开始前先打快照，这一步很便宜。独立服务器没有快照这回事，得确认备份真的落在另一块盘或者异地节点上——系统盘挂了备份跟着一起没的情况，我们见过不止一次。
装新内核时保留旧内核的启动项，确认 GRUB 默认项指向哪个版本，并且提前确认带外管理能进得去。新内核起不来的时候，SSH 是指望不上的，只剩控制台和 IPMI。管理口的正确用法在之前那篇安全清单里写过，这里不重复。
还有一件最容易忘的事：升级前先用 fio、sysbench 在旧内核上跑一遍基线，存好结果。没有基线，升完拿什么比？光看"机器能开机、网站能打开"，等于什么都没测。
判断升级成功的标准也应该是这个——不是能重启，是你自己的压测数据确实比旧内核好，同时数据库、定时任务、监控、备份全部正常。
最后再说下
7.2 是一个内容扎实的版本，Btrfs、内存回收、ext4、调度器都有真东西。但内核版本号不是 KPI。
大部分香港服务器的性能瓶颈压根不在内核——在回国线路的绕行、带宽峰值被打满、磁盘选型不匹配业务，或者一条从来没加过索引的查询。这些问题换十个内核版本也不会消失。
等发行版把 7.2 送进你的软件源再说，通常是最省事、也最划算的答案。