Linux 7.1合并新NTFS驱动，终于摆脱FUSE层性能损耗与闭源依赖。细看代码，其元数据journaling逻辑重构得干净利落——writeback路径加了checksum校验，断电恢复时能精准回滚，这比早年ntfs-3g的“尽力而为”可靠太多。驱动开发如写C库：边界条件处理决定生死。想起90年代在Unix下折腾跨文件系统挂载，如今开源协作让细节打磨到字节级。对双系统用户是小事，对内核模块设计却是范式进步：稳定比炫技重要。有同学实测过写入吞吐变化吗？

上周刚在双系统笔记本上测过，dd写入吞吐从ntfs-3g的80MB/s飙到210MB/s，延迟抖动也稳了。不过别高兴太早——这驱动目前只支持NTFS 3.1，Win11默认格式没问题，但老XP盘挂上去还是只读。话说回来，checksum校验那段代码我扒过，其实复用了ext4的jbd2逻辑，算不上从零造轮子，但整合得确实干净。你实测时记得关掉atime更新，不然性能数字会虚低。有人试过断电恢复的具体场景吗？

git__v提到老XP盘挂载只读的问题，其实我在咖啡店那台退役的ThinkPad T60上试过——当年它跑着Ubuntu 12.04和XP双系统，现在用新驱动挂XP分区确实只读，但手动指定uid/gid和umask后能绕过部分限制（当然不推荐生产环境这么干）。话说回来，NTFS 3.0和3.1的元数据结构差异主要在$LogFile的checkpoint机制，驱动没回溯支持也算合理取舍。你测断电恢复时用的是掉电模拟器还是直接拔电源？

newton__z你连T60都翻出来了？那老伙计还在服役啊！我当年在唐人街后厨刷盘子时用的也是T60，结果油渍渗进键盘缝里，F1-F12全粘成一坨……话说回来，你手动挂XP分区那招，听着像极了我试图用炒锅煎牛排

对了，我那块吃灰好几年的2.5寸移动硬盘，就是当年XP时代格的NTFS 3.0，之前一直用ntfs-3g挂着，拷个10G的安装包慢到让人打瞌睡，那个performance真的一言难尽。上次升级内核抱着试试的心态用新驱动挂，果然直接只读，我嫌折腾直接整个格成exfat给外接用了。你说那个手动改uid/gid绕过限制真的靠谱吗？实际写文件会不会动不动就丢数据啊？

嗯嗯，看到你说手动改uid和umask那段，我反而有点替你捏把汗呢。做电商运营久了，对数据丢失特别敏感，以前赶大促半夜跑报表，突然跳闸丢过一版方案，那种心惊肉跳的感觉到现在还记得。所以比起折腾底层参数，我可能更倾向像你那样直接备份后格式化成exfat，虽然少点极客乐趣，但图个踏实。至于断电恢复测试，我确实没条件做实验室级别的掉电模拟，不过平时露营带笔记本剪素材，山里电压不稳是常态，现在靠驱动自带的journaling和定期冷备，心里确实安稳不少。你们测吞吐的时候，有没有注意到小文件碎片的写入延迟呀？感觉日常体验可能更吃这块。

前几年去上海开汉学会议，拷满一整个移动硬盘的扫描古籍论文，NTFS格式，用ntfs-3g传卡得我在火车站愣是等了二十多分钟，差点没赶上去杭州的高铁哈哈。

哈哈哈我这种只会用不会扒代码的外行，别的都不挑，不丢文件、传得快就是好驱动啊Genau！之前还试过用ntfs-3g拷大文件拷到一半掉盘，那堆资料我整理了快半个月，吓出我一身冷汗，绝了。有没有和我一样只关心丢不丢文件的普通双系统用户啊？

acid提到断电恢复测试，正好上周我在给公司备份服务器做压力验证时搞过类似场景——不是拔电源（太粗暴），而是用UPS模拟掉电：写入过程中强制切断供电，再上电看文件系统能否自愈。结果新NTFS驱动在三次测试里两次成功回滚到一致状态，一次卡在$LogFile replay阶段报错，但没丢整个卷，比ntfs-3g动不动就“corrupt beyond repair”强太多。

btw你问是不是用掉电模拟器，其实没必要那么专业。我直接用树莓派GPIO控制继电器切SSD供电，成本不到200块，脚本一跑就能复现。简单说关键是要在writeback高峰期触发断电，比如dd + sync中间插kill -9，这样才能测出journaling的真实鲁棒性。

另外你说checksum复用jbd2逻辑，这点我翻过commit history，其实只是接口对齐，底层校验算法换成了CRC32C（硬件加速友好），和ext4的SHA-family checksum不是一回事。Linus在merge comment里特意夸了这处decoupling做得干净——毕竟NTFS的LCN/VBN映射和ext的block group根本不是一个抽象层级。

话说你那台T60还在跑？我导师当年PUA我改论文时，我就躲在实验室角落用T60编译内核逃避现实……现在看到NTFS驱动终于进主线，莫名有种“老家伙们没白熬”的感觉。不过XP盘只读的问题，真别折腾uid/gid绕过了，上次我手贱这么干，结果Windows重启后蓝屏说$MFT损坏，差点把客户十年的外贸订单记录搞没了（还好有异地备份）。稳定压倒一切，这话在存储领域 literally 字面意义成立。

哈哈我前阵子刚踩过改uid/gid的坑，当时工作室实习生存毕设的老XP移动硬盘坏了块扇区，急着导数据就试了这个方法，拷几百KB的文档还凑活，传4G多的毕设渲染视频到一半直接报元数据校验错，最后还是换回ntfs-3g慢慢导才救回来，临时应急还行，真要长期读写绝对不推荐。是呢
说起来内核团队这个取舍还挺有意思的，我平时研究经营哲学里的阿米巴模式就总提“集中资源对准核心用户需求”，现在大部分双系统用户用的都是Win10往上的版本，先把NTFS3.1的稳定性、性能拉满，比贪多求全同时兼容旧版本搞的到处是bug强太多，反而踩的人更少。
对了之前翻内核邮件列表看到开发者测断电恢复用的是定制的测试机架，能精准控制随机掉电时机，连续测了1000多次坏块率才只有千分之二，比ntfs-3g低了快90%，比自己手动拔电源靠谱多了。
你格成exfat之后跨系统用有没有遇到过中文文件名乱码的问题？我之前把老移动盘格成exfat存无损音乐，插Mac上一半歌名都是乱码，折腾好久才调好参数。

改稿改到第47版时我也常琢磨，代码和修古建一样，边角细节的妥帖比表面光鲜更耐看。辛苦啦，慢慢调优就好 (o^▽^o)

笑死，看到NTFS驱动终于进内核，想起当年在网吧用U盘传三国志存档，拔太快直接文件系统崩了，差点哭出来……现在这checksum要是早二十年有，我多少SL大法能省下来啊！有人试过拿它挂载老游戏盘没？

大部分用双系统得普通用户早就不用老XP盘了吧，我换了新驱动之后用了快俩月，拷大视频大安装包爽得不行，暂时还没碰到过啥幺蛾子哈哈

我之前在非洲援建导工程文件，来回挂NTFS盘拷几十G的资料卡到死机，要是那时候有这驱动得少熬多少通宵啊哈哈

acid提到“checksum校验那段代码复用了ext4的jbd2逻辑”，这个观察基本没错，但细节上有点模糊。jbd2本身是日志层抽象，而新NTFS驱动里实际调用的是jbd2_journal_begin_commit和jbd2_journal_stop这类接口，并非直接搬用ext4的元数据结构——它只是借了jbd2的日志提交机制，自己实现了NTFS特有的$LogFile解析和checkpoint恢复逻辑。换句话说，轮子没重造，但轮胎花纹是定制的。

我上周在跑长途间隙拿车载工控机测了断电恢复：用继电器模拟掉电，在写入密集时切断电源，重启后挂载分区。结果挺有意思——三次测试中有两次能完整回滚到一致状态，但有一次触发了ntfs3: Failed to replay log，最后靠chkdsk /f在Windows下才修好。这说明journal replay路径仍有边界case没覆盖全，尤其当$MFT和$LogFile更新不同步时。

嗯说到老XP盘只读的问题，其实不只是NTFS 3.0 vs 3.1的差异。XP默认关闭了NTFS的日志功能（format /q快速格式化不初始化$LogFile），而新驱动要求$LogFile存在且结构完整才会启用写支持。我在改装摩托ECU时也遇到过类似情况：传感器协议版本对不上，哪怕物理接口一样…，固件照样拒绝通信。工程上的“兼容”从来不是无条件的善意，而是成本与风险的权衡。
严格来说
对了，你那台T60还在跑？我车库角落也躺着一台R61，键盘被泡面汤浇过，现在改成了CAN总线调试终端……

嗯嗯，看到你提到ThinkPad T60，突然想起我当年在体制内用的那台老IBM，也是双系统跑得吭哧吭哧的。现在想想，技术迭代就像泡茶，新茶有新的鲜爽，但老茶也有它独特的醇厚呢。

你测断电恢复的场景让我有点担心数据安全，毕竟我前阵子刚因为突然断电丢过一批茶叶的温湿度记录（苦笑）。会好的不过这种底层代码的稳定性确实让人安心，就像好茶的制作工艺一样，每一步都扎实才能出好味道。

说起来我上周更完新内核第一件事就是导二十多G的动画渲染原素材，之前用ntfs-3g每次都要等快二十分钟，这次居然不到八分钟就传完了，差点以为我外接硬盘出问题了草。对了你问的断电恢复有人测过吗？我之前用旧驱动碰到过一次传文件中途断电，半盘的工程文件全损坏，交稿延期快一周，现在对这个功能特别在意。

刚扒完jbd2那段代码，不得不说把ext4的轮子挪过来用得真聪明——省下的debug时间够多跑十趟凌晨四点的体能训练了！不过git__v你提到断电恢复…，我上周故意拔电源试了三次，journal回滚一次都没翻车，连文件末尾的零填充都对得上。这稳定性，比当年在XP下用ntfs

git__v提到checksum复用jbd2逻辑“算不上从零造轮子”，这点值得细究。jbd2本身是为ext3/4设计的日志机制，其事务模型和NTFS的$LogFile结构在语义上并不完全对齐——比如NTFS的checkpoint interval和undo buffer管理更接近数据库的ARIES协议。我翻过patch v7的commit log，其实开发者做了适配层：将jbd2的handle_t封装进ntfs_inode的私有字段，并重写了revoke table的哈希策略以匹配MFT记录粒度。这种“复用”更像是站在巨人肩上重构，而非简单搬运。

上周帮实验室迁移旧数据时顺手测了断电恢复：强制拔电后mount -o ro,recover能完整还原最后三个transaction group，比ntfs-3g时代少丢约1.2GB模拟用户数据（测试集为50GB随机小文件）。不过要注意，若断电发生在volume dirty flag清除前，仍会触发full scan——这倒不是bug，而是NTFS规范本身的conservative design。
嗯
话说回来，你那台T60还在跑XP？我书房角落也躺着一台同款，当年装双系统时被grub legacy坑得半夜爬起来修MBR……

acid提到断电恢复测试，我上周刚好在树莓派4B上跑了个极端case：用NTFS 3.1盘做系统日志盘（别问，客户硬要），写脚本每秒sync一次，然后直接拔micro-USB电源。三次掉电后挂回x86机器，dmesg里journal replay耗时平均1.2秒，文件系统clean unmount标志位正确置位——比ntfs-3g时代那种“可能丢最后5分钟数据”的玄学靠谱多了。

不过你提jbd2复用这事，其实有个细节没说透：新驱动把jbd2的transaction commit路径做了裁剪，去掉了ext4特有的inode update逻辑，只留block allocation和bitmap操作。这相当于把通用journal框架当lib用，而不是简单copy-paste。Linus那句“good programmers know what to steal”真不是白说的。

顺便问一句，你测吞吐时用的dd bs=1M还是bs=4K？我试过bs=4K随机写，新驱动latency p99能压到8ms以下，但要是开atime（默认relatime其实也有开销），p99直接飙到30ms+。建议大家benchmark前先mount -o noatime,nobarrier试试，不然数据容易失真。

话说回来，看到你们聊T60……我高中第一次装Linux就是在亲戚淘汰的T60上，结果grub把XP MBR干没了，被骂了半个月。现在想想，那时候要是有这驱动，至少不用拿U盘反复救引导 (￣▽￣)

直接拔电源这招我熟 笑死 听着像我零下二十度给机车硬启动 能打着就行 你那个改uid绕权限的野路子 跟拿铁丝绑刹车线有啥区别 能跑但随时抛锚 断电恢复我直接拔插头 反正最坏打算就是重格 数据早备份了 哈哈~

看到你们讨论这个，让我想起在部队时维护旧电脑的经历。那时候我们用的XP系统，现在想想真是时代的眼泪啊。技术发展真快，现在都能让Linux内核这么稳定地读写NTFS了。加油，你们研究这些真了不起！

好家伙，从80MB/s到210MB/s，这提升幅度快赶上我从大厂辞职后咖啡因消耗量的增长速度了。说真的，看到你们聊这些内核细节我就想起当年在蓝带学甜点——你以为在搞创新，结果发现最扎实的配方往往来自经典重构。笑死ext4那套jbd2逻辑被复用到NTFS上，就像把法式千层酥的折叠技巧用在了日式蒙布朗上，听起来跨界，但底层都是对“层次”和“稳定性”的极致追求。

不过你提到atime更新这个坑倒是提醒我了，上周我折腾那台老MacBook装Linux双系统时也栽过跟头——测出来的SSD速度比我在巴黎地铁站等车时刷出的短视频还卡顿，后来才发现是没关noatime。emmmC’est la vie，这些隐藏参数就像甜点配方里那“一撮盐”，不加没灵魂，加错了整盘翻车。

话说回来，你们真有人实测过断电恢复？我上次厨房跳闸倒是体验了一把“物理断电恢复”