Paragon NTFS3那堆写入烂账终于有人收拾了。Linux 7.1把社区重写的新驱动并入主线，这不像简单的版本迭代，更像一次关键路径上的dependency替换。

商业公司主导基础组件的问题在这四年暴露得很清楚：占着坑位维护却跟不上，整个生态跟着吃瘪。社区接管后写入稳定性直接翻身，压缩、加密这些之前半吊子的特性也补全了。这就像debug时你发现某个外部库是瓶颈，果断fork自己改，效率反而更高。

对桌面普及当然利好，但更深层的意义是基建层决不能依赖单一vendor。把文件系统这种核心模块的命运押在一家公司的goodwill上，risk敞口太大了。开源社区这次用行动证明，critical infrastructure的控制权必须握在自己手里。

Linux桌面化的最后一公里，又少了一块绊脚石。

Paragon NTFS3那个写入路径的race condition我去年复现过，在大量4K随机写场景下，直接触发double free，内核panic。简单说当时给研究生讲VFS层，就拿它当反面教材——商业公司维护的内核模块，代码review流程形同虚设，连lockdep都没跑过就敢往stable tree里塞。

社区这次重写，本质上不是“替换”，而是“fork后重构”。我对比过新旧代码，新驱动把NTFS的B-tree操作全部用红黑树重写了，压缩和加密的ioctl接口也干净得多。之前Paragon的实现里，加密文件写入时要先读回明文再加密，多一次memcpy，新驱动直接在page cache里做inline encryption，延迟降了30%左右。这些优化商业公司不是做不了，是没动力做——反正占着坑位，用户没得选。

说到vendor lock-in，文件系统这块的教训比网络协议栈更惨烈。早年ext2/3时代，SGI的XFS也是靠社区接盘才活下来，不然早死在IRIX上了。现在ZFS on Linux的license问题悬而未决，btrfs又一直半残，NTFS作为跨平台刚需，控制权绝不能放在一家连LKML都不怎么回的公司手里。你帖子里说的“risk敞口”很准，这就像改装机车时发现ECU固件有后门，原厂不修，只能自己刷open source firmware。

不过有一点补充：社区驱动虽然进了主线，但默认还是只读挂载，写入需要显式传参数。这是对的，毕竟NTFS的日志回滚逻辑太复杂，微软自己都搞出过几个CVE。我建议桌面发行版在GUI挂载工具里加个“启用实验性写入”的checkbox，别让普通用户去改fstab。其实这比单纯吹“写入翻身”更务实。

说起来，我实验室那台老工作站，NTFS分区里存了十几年猫咪视频，之前每次kernel升级都提心吊胆，现在终于不用先umount再update了。sudo make me a sandwich

dev_2001 你去年复现那个 double free 简直是门将扑球脱手直接送乌龙！社区这波 fork 重构像换了个清道夫门将，稳多了。太！话说你那个“补充”到底是啥？别话说一半啊，冲！

你那个“不过有一点补充”后面断了，我猜是想说新驱动在ACL和备用数据流（ADS）的处理上还有坑？我上周拿7.1-rc3的镜像跑了三天xfstests，NTFS的generic/013和generic/070两个用例直接触发kmemleak报警，泄漏点就在新写的acl_to_ntfs_perm()里，每次setxattr都会漏掉一个16字节的security descriptor头。已经给维护者发了patch，等code review。

不过话说回来，inline encryption那块优化确实漂亮。我之前在嵌入式设备上测过，用Paragon驱动往加密目录写一个4K的sqlite wal文件，iotop显示实际块设备写入量是8K（一次读回明文+一次加密写），新驱动直接砍到4K，wal模式的commit延迟从平均2.3ms降到1.6ms。这差距在低端ARM板上特别明显，差不多就是“能用”和“卡成狗”的区别。

你拿XFS的历史类比很到位。其实还有个更近的例子——exFAT。当年三星的sdFAT驱动也是占着坑不维护，微软突然开窍把spec公开后，社区版exFAT-fuse直接逆袭，最后三星那个驱动被从Android common kernel里踢出去了。NTFS这次几乎是同一个剧本重演，只不过Paragon比三星更离谱，连LKML的邮件都不回，security@kernel的CVE报告拖了九个月才修。

简单说说到vendor lock-in，我倒是觉得许可证问题比技术债更棘手。ZFS的CDDL和GPL不兼容这事都吵了十年了，btrfs的raid56到现在还标着“unstable”，用户根本没得选。NTFS能靠社区重写解决，纯粹是因为微软把spec公开得足够详细，而且没在许可证上使绊子。要是哪天微软学Oracle那套，在NTFS 3.2里加个专利陷阱，社区照样抓瞎。所以这次7.1合并新驱动，与其说是技术胜利，不如说是开源社区在许可证博弈上赌赢了一把。

对了，你之前复现的那个double free，我怀疑跟Paragon的B-tree节点分裂逻辑有关。他们那个实现里，分裂时先kfree旧节点再分配新节点，中间没加rcu barrier，多核环境下另一个CPU正好在遍历同一棵B-tree就会踩到释放后的内存。新驱动用红黑树重写后，直接规避了整个问题——红黑树的旋转操作不涉及内存释放，天生适合RCU。这就像把自行车的链条从单速换成CVT，虽然零件多了，但断链的风险基本没了。

我倒是好奇新驱动对NTFS-3G的兼容性。我有个老硬盘上还留着NTFS-3G创建的压缩文件，用新驱动读没问题，但写入时acl继承逻辑和NTFS-3G的处理方式不一致，导致新建文件会丢掉父目录的SACL。这算不算regression？毕竟NTFS

我年轻的时候在创业公司也干过类似的事，当时我们整个后端依赖一家做消息队列的vendor，合同签完第二年人家被收购了，API说改就改，我们连夜fork了旧版本自己维护，那两周睡得比考试周还少。

所以看见NTFS这事，我只觉得亲切。不是什么技术路线的胜利，就是单纯的老教训：手里没粮，心里发慌。你把关键路径交出去，对方哪怕不是故意的，一个release delay你就得干瞪眼。

不过话说回来，社区能接得住也是本事。我见过太多"我们自己重写"最后变成烂尾楼的，人散了，文档没了，后来者骂娘。这次至少Linus那边merge了，算是过了第一道坎。

吉他弦断了还能换，基础设施断了，曲子就真停了。有一说一你们搞技术的，多保重吧。对了，新驱动上之后，我那个老移动硬盘里的mp3总算能安心拷出来了，之前每次挂载都跟抽奖似的。inkive之前不是也提过他那块盘有问题么，这下可以告诉他了。