作者:陆麟
转载请征得作者同意.
2026.2.7

上次写的断电这个场景挺受欢迎的，今天延续着再写点内容。

Express Mail 的 Windows 版本，性能比 Linux 版本差上不少。 我想很多人会下意识觉得，这是因为 Windows 系统本身的性能就不如 Linux，但实际背后的原因，若没深入钻研过操作系统内核，大概率是无从知晓的。

2000-2010年这个区间，新闻组里关于linux操作系统和windows操作系统优劣的讨论基本分成两派：做 Linux 程序开发的，对 Linux 各种推崇；微软的开发人员（当然并非所有微软开发者，Windows 内核的讨论组里就有几位很专业靠谱的），则觉得 Linux 不过是个玩具。

那段时间我对 Linux 的看法，和微软这边的观点大体一致，也认为它只是个玩具。其他人这么觉得的原因我不清楚，但单就断电这个问题来说，我在文件系统驱动和 Disk.sys 的源代码里，能清晰看到文件操作的 API 调用链路 —— 从写操作的 IRP，到写操作 CDB（SCSI 命令）中 FUA 标志的处理，整个链路的逻辑都很完整。只要这个标志被正确设置，保障数据落盘的义务就是磁盘固件了，固件应当负责对这些标识按照规范进行处理。但是，linux的调用链条有点问题。 当文件系统把缓存flush后，磁盘驱动那边我实在没找到哪个地方有FUA这个标志位的操作，而且linux的磁盘驱动自带differred write功能，flush cache调用并不等待磁盘写入完成。因此写操作的缓存控制实际到了 磁盘驱动这一层就断了链条。

ExpressMail linux版速度快，其中有一部分是有linux磁盘驱动的bug因素在里面的。

如果大家搞数据库，一个数据库软件同时有linux的数据库和windows的数据库，结果也是差不多，windows的数据库性能比linux差很多，但是如果断电重启呢，windows的数据库损坏比例要比linux显著少。其中很大原因我想也是拜不同 操作系统磁盘写入的机制差异所赐。

Linux在2008年的2.6版内核开始修复这个bug，但是当时主流linux都在2.4版本的内核上修补。2.6的新内核在相当长的时间内都没有见哪个企业版本的linux用上。因此可靠性问题没有直接摆在桌上，实际一直都在改良。

这些话题都是因邮件系统而起，讲点题外话，我的工作经历中和好多国家的人打交到。日本团队有人非常聪明，有人非常勤奋，日本人总体没人偷懒。国内好多人受“厉害了，我的国”的影响，无视他人优点的基本事实， 看到“日本原来也有人做假”的案例，就有意无意要让人认为“日本人都是做假的”，是非常不合实际情况的。
搞邮件的日本方负责人是专家，姓千页，我非常佩服，是聪明型的。聪明的意思是他能一边review设计书一边提出我们没想到的场景，可能发生概率非常非常低，但是一定会发生，只不过是大家不知道哪个时间会发生。 他在设计规格的时候编写原型代码基本来说已经bug非常少，可以性能优化的空间也不多。负责测试的叫江上，非常勤奋。所谓勤奋，指的是如果我们做个位数的正整数加法程序，设计出来的测试用例真的就是从0+0，0+1，...9+8，9+9，在不知道内部实现的情况下 尽最大力量验证每个可能发生的用例。有聪明的有勤奋的，这样的组织出来的东西就会厉害。口嗨说人家不行是没有用的。我做准入系统（就是陌生人的电脑接到公司傻交换机也要让他电脑无法正常工作的这种系统）时候日本那边 负责人名年代久远记不清了，我对那人印象不好，觉得对方给的指示会影响性能，在代码里面专门写了一段注释，大致意思是“xx让写的，他是个蠢货，我觉得应该怎样怎样”，人家是真遵守软件工程流程review代码的，指出应 当删掉这些注释。。。

这样的软件工程流程，软件里面是做不进去彩蛋的。反而老美软件动不动有彩蛋，代码review的执行肯定是有问题的。