哈哈 看到Linux新版内核终于把NTFS驱动好好整了整 我真是热泪盈眶啊 以前装双系统 想从Windows分区拷个电影过来 结果要么只读 要么写一半崩了 文件直接变乱码 气到想砸电脑 后来干脆搞了个exFAT分区当共享盘 但每次复制大文件那个速度简直梦回拨号上网
不是
现在好了 官方搞了个新驱动 支持写入 虽然我还没升级到7.1 但看报道说是从Paragon那个闭源驱动换成了自己维护的 作为在非洲工地上拿Linux当主力机的工程师 我太懂这种痛了 这边机子配置参差不齐 有时候还得帮同事的Windows笔记本倒数据 能稳定读写NTFS真是救命
话说回来 这驱动也就刚进主线 估计还得小修小补一阵子 希望别像某些内核模块那样 修着修着就失踪了（手动狗头）
以前我们用软盘拷画稿，坏一个扇区就全完了。现在你们年轻人遇到的文件系统问题…，说到底还是工具要稳。内核驱动这事，急不得，等它磨上几个版本就踏实了。
bronze48提到软盘坏扇区，我瞬间想起当年用MO盘备份标注数据的事，几千张ImageNet的bounding box文件，坏一个扇区整个tar包就解不开了，那种绝望确实刻骨铭心。不过文件系统驱动的稳定性，现在跟当年不太一样——当年驱动出问题常是硬件容错没做好，现在NTFS这种复杂日志文件系统，更多是边界条件和并发写入的坑。我看过LWN上Paragon和微软的代码对比，这次换自研驱动其实是在前人的兼容性测试上重写，可能不需要“磨几个版本”那么久，5.15到5.19的改动已经收敛很快了。
theorem_de，你提到LWN上Paragon和微软的代码对比，我前段时间正好在追这个系列的讨论。不过有个细节值得商榷——你说这次是"在前人的兼容性测试上重写"，这个表述可能过于乐观了。
我看过5.15到5.19的changelog，NTFS3驱动在5.15刚进staging的时候，其实只通过了基本的smoke test。真正的问题是在5.17左右才暴露出来的：一个台湾的开发者用AFL fuzz出了三个buffer overflow，都是在处理畸形MFT记录时的边界检查缺失。这类bug在Paragon的原版驱动里也存在，但因为闭源，没人能审计。
换句话说，所谓的"重写"并不是站在巨人的肩膀上，而是把一套没经过公开审计的代码用Rust的思路重构了逻辑。好处是内存安全问题确实收敛很快，但坏处是某些NTFS 3.1的特性——比如压缩写入和加密——到现在还是实验性的。微软那套实现虽然臃肿，但至少跑了二十年的回归测试。
所以我觉得"磨几个版本"这个说法，从某种角度看，bronze48说得反而更接近现实。只不过现在磨的不是硬件容错，而是特性覆盖率和fuzzing的边界case。严格来说我上周在5.19内核上试了试，往一个启用了压缩的NTFS分区写50G的虚拟机镜像，写到37G的时候直接kernel panic了。这要是在生产环境，估计运维得疯。
说到MO盘，你当年用tar打包标注数据，其实现在也有类似的问题。我去年帮一个做CV的朋友迁移数据集，他们用的是ZFS的snapshot做版本管理，结果有个snapshot的checksum错了，整个200G的ImageNet变体数据集直接读不出来。最后是用zdb手动修复的metadata，那种感觉大概跟你当年解不开tar包差不多。
不过话说回来，文件系统这玩意确实是最容易被低估的基础设施。我自学编程那会儿，在树莓派上跑了个ext4的U盘当根文件系统，半年后突然开始丢文件，查了半天才发现是U盘控制器的wear leveling算法和ext4的journal写冲突了。那时候才理解为什么企业级存储要那么贵
老兄在非洲工地，电源稳定吗？突然断电对NTFS日志的破坏，可比驱动本身bug还难缠。之前ntfs
等等 非洲工地…你们那边网络条件咋样？我听说有些地方还靠卫星上网 延迟高得吓人 下个内核源码包都得挂一晚上吧
嘛不过说到NTFS驱动这事 我倒是有个疑问 Paragon之前那个闭源驱动不是说挺稳定的吗 怎么突然就换成自己维护了？据可靠消息 Linux基金会那边和Paragon的授权协议去年就到期了 续约谈判好像不太顺利 有人说是微软在背后施压 不想让Linux对NTFS支持太好…当然这只是圈内的说法 真实性你们自己判断
服了
话说你那边测试过新驱动拷大文件的速度没 我好奇和exFAT比起来能快多少
那个台湾开发者的AFL report我追过，三个buffer overflow的根因都是 ntfs_read_mft_record 里 record_size 直接从磁盘读出来就丢给 kmalloc，没做上限校验。fix在5.18-rc2，加了个 MAX_MFT_RECORD_SIZE 常量，literally四行代码。闭源驱动这种bug能躺十年，开源至少能被fuzz到。
网络这块真的笑死你说对了 我们这边属于信号基站基本没有 日常就靠卫星锅 延迟800ms起步 下个内核包挂一晚上是常态 好不容易下完了一断电全白给 所以我现在养成习惯了 啥大文件都分卷压缩成几十个小包 断点续传yyds
不过说到微软施压这个说法 我持保留态度啊 人家Paragon做商业授权的 每年白皮书里 NTFS兼容性问题能列几十条 维护成本太高不续约很正常 没必要啥锅都甩给微软哈哈
速度的话我还没测呢 这边同事的Windows机子还是win7 升级一次能要他们半条命 等回头找台win10的机器试试看 到时候上来汇报
老哥你这是站着说话不腰疼哈哈哈哈 我这边工地UPS供电就够撑5分钟 新驱动哪怕有bug也比每次开机fsck强啊 先爽了再说！
在非洲工地用Linux当主力，这份坚持真的让人敬佩。我之前在东南亚出差也遇到过类似的文件系统问题，那种数据在眼前消失的感觉确实很折磨人。
会好的
新驱动能稳定写入NTFS确实是很大的进步，尤其对你这种需要频繁跨系统传数据的场景。不过quant老兄说的电源问题确实很关键，NTFS的日志机制在突然断电时比较容易出问题，建议你那边有条件的话加个UPS，哪怕是小容量的也能在关键时刻保护数据完整性。
话说你们工地那边的设备都是自己维护吗，还是有人专门负责IT支持？
theorem_de你提到LWN上Paragon和微软的代码对比，我突然想起来一个事——你们觉不觉得这个新驱动的合并过程有点像跳舞？
不是开玩笑，我跳街舞的时候经常遇到这种情况：你跟着别人的编舞跳了很久，动作都顺了，但总觉得哪里别扭。后来自己重新编一遍，虽然框架还在，但发力点全换了，反而跳得更舒服。这个NTFS驱动也是，Paragon那套虽然稳定，但毕竟是别人的东西，现在自己重写，等于是用自己的肌肉记忆重新理解一遍动作。
emmm
说真的，你说的“可能不需要磨几个版本”我有点同意。5.15到5.19的改动收敛快，说明核心逻辑其实已经吃透了，剩下的都是些边界条件的修修补补。卧槽这跟跳舞比赛前最后几天调整细节似的，大框架早就定了，只是微调表情和力度。
不过quant在4楼问的电源问题真的扎心。非洲工地那个环境，UPS估计都是奢望吧？我在国内演出时遇到过舞台电源不稳，灯光音响全跳了，我就在黑暗里即兴跳了三十秒…那种感觉，跟NTFS日志写到一半断电差不多，全靠肌肉记忆撑着。
非洲工地的电源稳定性确实是个大问题，不过NTFS日志的破坏确实比驱动bug更难缠。我之前在实验室里也遇到过类似的情况，突然断电导致文件系统损坏，修复起来真是头疼。话说回来，新驱动拷大文件的速度确实比exFAT快了不少，不过还是得小心电源问题。
scoop_1，你提到授权协议和微软施压那个说法，我在LWN的订阅邮件里看到过类似讨论，但其实有个更技术性的原因——Paragon那个闭源驱动虽然稳定，但它对NTFS journal replay的处理方式比较保守，很多操作走的是bypass路径，相当于绕过了NTFS真正的元数据管理机制。
这就像用Newton力学算水星轨道，大部分时候够用，但一旦遇到进动问题就露馅了。Paragon驱动在小文件和简单写入场景下没问题，但遇到碎片化严重的NTFS卷或者带压缩/加密属性时，它会在kernel log里疯狂吐warning，然后默默fallback到只读模式。Torvalds自己在LKML上就骂过这事，说与其维护一个“假装能写但关键时刻掉链子”的驱动，不如从头搞一个真正理解NTFS on-disk format的东西。
严格来说
不过话说回来，新驱动的性能优化空间还很大。我看过phoronix的benchmark，大文件顺序写比exFAT快了大概30%，但随机4K写简直惨不忍睹，跟用FUSE的ntfs-3g差不多。估计还得调几个版本的VFS参数。你们那边工地网络再差，也得想办法跑个iozone测测看，我也挺想看看实际测试数据的。
看到MO盘那段我手都抖了，当年刻录光盘也这德行，坏一个文件整个项目报废。话说你那些bounding box后来补标了没？我猜你现在看见tar包都PTSD了吧