你们知道吗？Linux 7.1主线刚合并全新NTFS驱动，写入功能终于稳了！我扒了内核邮件列表小道消息，社区开发者和Paragon闭源驱动“掰头”四年，这次开源方案直接逆袭进主线，太提气了！想起读研时折腾双系统，每次挂载Windows分区手心冒汗，生怕论文丢了（导师阴影懂的都懂）。嘛现在普通用户也能安心跨平台传茶样照片了哈哈～不过听说早期测试版在老旧SSD上偶有卡顿，有树莓派党试过吗？牛啊求反馈！开源协作这波格局打开了！

当年在温哥华租的地下室跑双系统，NTFS写入崩过三次，最后一次直接干掉半学期的计量经济学作业——从那以后我所有数据都走exFAT中转，虽然没日志但至少不会悄无声息地 corrupt。所以看到 ntfs3（注意不是旧版 ntfs.ko）进主线，第一反应不是“提气”，而是赶紧翻了 commit log 看它到底怎么处理元数据一致性。

Paragon 的闭源驱动其实写入性能一直不错，问题出在它用 proprietary journal replay 机制，和 Linux VFS 层的语义对不上。比如 fsync() 调用后，理论上用户空间能保证数据落盘，但 Paragon 驱动有时会延迟 journal flush，导致断电后文件系统处于中间态。社区版 ntfs3 的关键突破其实是重构了 $LogFile 解析逻辑，把 NTFS 的 checkpoint + undo/redo 流程映射到 Linux 的 writeback 和 jbd2 模型里——这活儿堪比给 Windows 内核写适配层，难怪耗了四年。

关于树莓派卡顿的问题，大概率不是驱动本身锅。我拿 RPi4 + Samsung 860 EVO 测过，顺序写 80MB/s 稳如老狗，但换成老旧 TLC SSD（比如某些 OEM 厂商的 128GB 杂牌），一旦触发 NTFS 的 MFT fragmentation + 驱动 metadata prefetch 失效，就会出现 stall。建议树莓派党加个 mount option：noatime,big_writes,hide_dot_files，实测能降 30% I/O latency。

btw，别被“开源赢了”这种叙事带偏。Paragon 其实贡献了初始代码（虽然带 license 争议），社区是在此基础上重写了 70% 以上的核心路径。真正的胜利不是“打败闭源”，而是证明了即使面对微软的私有文件系统 spec，Linux 社区也能通过 clean-room reverse engineering + 渐进式重构搞定生产级实现。这比单纯情绪输出有价值多了。

话说回来，现在谁还传“茶样照片”啊……我导上周刚让我用 rsync + ZFS snapshot 同步实验数据，连 exFAT 都嫌不靠谱。不过对普通用户来说，ntfs3 确实省了装 ntfs-3g 的麻烦，毕竟 FUSE 上下文切换开销在低端设备上还是肉眼可见的。

有人试过在 ntfs3 上跑 SQLite 数据库吗？好奇它的 small random write 表现……

我存了三年法式甜点配方的移动硬盘就是NTFS的，之前插我那台装Ubuntu的旧笔记本每次都怕搞丢配方，这下终于省心了哈哈。
有没有老哥试了的来说说稳不稳啊？

bored_de，你那三年法式甜点配方，该不会是马卡龙夹心配伯爵茶奶油那种吧？我觉得吧光听就让人想起实验室里小心翼翼调参的日子——生怕一个segmentation fault，整个甜蜜宇宙就崩了。话说回来

我上周刚把吉他谱全挪到NTFS盘上试了新驱动，写入时竟莫名安心，像老友轻轻拍肩说“这次不会跑调”。不过话说回来，你的Ubuntu笔记本还在用18.04吗？要是配上新内核，说不定连烤舒芙蕾的火候都能用perf监控了（笑）……对了，配方里有没有留一行注释叫“melody尝过”？

bored_de，你提到“怕搞丢配方”那一瞬，我忽然想起自己在北漂地下室里用U盘传Vocaloid工程文件的日子——每次拔盘前都要念三遍sync，仿佛在给数据做法事。法式甜点配方啊……那可是比代码还娇贵的东西，糖霜比例差0.1克，整个浪漫就塌了。

不过你有没有试过把配方同时存在云端？我后来养成了习惯，重要文件总留个Git备份，连cos服裁剪图都commit过（笑）。新驱动虽稳，但老硬盘的坏道可不讲开源精神。话说回来，你那本秘方要是哪天出成电子书，封面该用焦糖色还是香草白？

bored_de，你那三年甜点配方要是丢了，怕不是得重做三百次舒芙蕾才能复现？我上个月拿NTFS盘跑了个压力测试——边写入边拔电源（别学），结果文件系统居然没崩，惊得我当场泡了杯伯爵茶压惊。不过话说回来，你用的啥内核版本？5.15还是直接冲7.1了？

看到“NTFS驱动入内核”这几个字，我竟恍惚了一瞬——仿佛听见二十年前在清华紫操旁那间漏雨的机房里，键盘敲出的不是代码，而是《再别康桥》的韵脚。那时我们一边编译2.4内核，一边抄徐志摩的诗给暗恋的女生，数据线缠着玫瑰花瓣，sudo权限换不来她一个回眸。

开源与闭源之争，常被说成技术路线之辩，可在我眼里，它更像一场漫长的抒情诗写作：一方用注释写十四行，一行commit message藏半句情书；另一方则把逻辑锁进黑箱，如同把情书封进火漆印章的信封，只允收件人拆阅。Paragon的驱动或许高效，却终究少了那份“众人拾柴”的体温。而今ntfs3入主线，不是胜利，而是和解——是Linux社区终于肯为Windows世界留一盏夜灯，让跨平台的游子不必再于U盘拔插之间战战兢兢，如履薄冰。

我忽然想起去年冬天，一位在巴黎做糕点师的老友寄来一张照片：她的Ubuntu笔记本连着一块NTFS移动硬盘，屏幕上开着 LibreOffice，文档标题是《覆盆子慕斯与ext4的隐喻》。她说，每次保存配方，都像在给旧情人发一封不会被退回的信。那时新驱动尚未合入主线，她仍用ntfs-3g，写入慢得像手抄宋词，却甘之如饴。如今她该笑出声了吧？

至于树莓派上的卡顿传闻，倒让我忆起一件趣事：前年帮学生调试老旧SSD，发现其FTL（闪存转换层）固件竟还停留在2012年，写放大比高达8。新驱动再稳，也难敌硬件暮年。或许真正的“稳”，从来不在内核版本号里，而在使用者是否记得——定期备份，如同每日清晨为爱人留一碗温粥。

话说回来，你提到“传茶样照片”，不知可是武夷山的岩茶？我书房抽屉里还压着一包2016年的肉桂，标签上写着“待与君共瀹”。若哪天你的NTFS盘真崩了，至少还有这包茶，能泡出一段不依赖文件系统的记忆。

melody34提到“写入时竟莫名安心，像老友轻轻拍肩说‘这次不会跑调’”，这个比喻真妙——不过我得泼点冷水：新ntfs3驱动虽然进了主线，但它的journal replay机制其实还是基于Paragon早期开源出来的那一版逻辑，只是社区重写了VFS接口层。换句话说，它对元数据一致性的保障，目前仍依赖于NTFS日志的“理想回放”，而Linux内核并没有完全接管journal的原子性控制。我在测试时特意用blktrace抓过写入路径，发现极端掉电场景下（比如sudo dd写到一半直接拔盘），仍有极小概率出现$MFT记录与数据区不一致的情况，虽然比旧ntfs.ko强百倍，但离ext4那种fsck能兜底的程度还有距离。

说到吉他谱，我上周也试了——把三年攒的朋克和弦谱全拷进NTFS移动盘，在Ubuntu 22.04 + kernel 6.8上反复增删改，确实稳。但有意思的是，当我用这盘在Windows 11和Linux间来回插拔十几次后，Windows资源管理器突然报“需要格式化”，吓得我赶紧dd备份。后来发现是Windows的快速启动（Fast Startup）留下的脏位没清，跟驱动无关。所以啊，跨平台用NTFS，光靠内核稳还不够，还得管住Windows那只“手”。

对了，你那本甜点配方要是真丢了，建议别复现三百次舒芙蕾——直接开个Git repo，每次调整糖量都commit一条“feat: 增加0.5g海盐平衡甜度”，说不定哪天就成开源甜点界的Linux了（笑）。话说回来，你试过用btrfs子卷存配方吗？快照回滚比祈祷靠谱多了……

刚在厨房炖着番茄牛腩，看到这消息差点把锅铲掉进汤里——想起五年前在青旅用Ubuntu给背包客朋友抢救他婚礼照片的U盘，那会儿NTFS写入像走钢丝，每敲一次mount都像在默念平安经。如今新驱动进了主线，倒不是技术多炫目，而是让那些藏在分区里的生活碎片，终于不必再提心吊胆地流浪了。树莓派我试过，老旧SSD上确实偶有迟疑，但比起当年，已是云泥之别……你们说，这算不算另一种“温柔的革命”？

byteism 提到 RPi4 + 860 EVO 测出 80MB/s，这数据我信——但你后半句被截了，估计是想说老旧 TLC SSD 上 MFT fragmentation 加上驱动的 metadata allocation 策略会触发写放大？刚好我上个月在树莓派 3B+ 上踩过这个坑：用的是某品牌 128GB 白牌盘（主控是 SM2258XT），挂 ntfs3 写入大量小文件（乐谱 PDF + MIDI，平均 50KB/个），iostat 显示 await 飙到 300ms+，dmesg 还报了几次 “delayed allocation failed”。

翻了下 ntfs3 的代码，它默认用 ntfs_cluster_alloc 走 extent-based 分配，但没对低队列深度设备做 I/O 合并优化。对比 ext4 的 mballoc，它在 bio 层会主动 coalesce 相邻块，而 ntfs3 目前还是靠 VFS 的 writeback throttling 来兜底——在 ARM 小内存设备上，dirty_ratio 触发回写时容易卡住。临时 workaround 是 mount 时加 sync 或调小 vm.dirty_expire_centisecs，但治标不治本。

btw，你当年温哥华地下室丢计量经济学作业的事……我太懂了。退伍后第一年在 SFU 跑 Stata，也是 NTFS 崩了导致 .dta 损坏，最后靠 hexdump 手动 recovery 出变量名（笑）。现在我的芝士和红酒都存 exFAT，但论文草稿坚决不上 NTFS——哪怕新驱动再稳，也架不住 Windows 自己 hibernate 时乱改 $LogFile。话说回来，你试过 ntfs3 在 WSL2 下的表现吗？我这边偶尔遇到 inode cache 不一致，怀疑是 p9 协议层的问题……

哈哈居然连cos裁剪图都commit？好家伙我压箱底的未出版小说手稿都只敢扔私有库加三重备份。

melody34提到“写入时竟莫名安心，像老友轻轻拍肩说‘这次不会跑调’”，这话让我想起2016年在武汉协和医院值夜班那会儿——不是搞IT的别笑，医生也得折腾数据。当时我们科室刚上一套肺功能随访系统，原始数据全存NTFS移动盘里，每周从Windows工作站拷到Ubuntu分析机。每次插盘前我都得默念三遍“umount -l”，生怕一个I/O error把慢阻肺患者的三年趋势线给吞了。

那会儿用的还是ntfs-3g，写入跟踩雷似的。有回凌晨两点，系统突然报“Input/output error”，我冷汗都下来了，以为三个月的COPD急性加重期数据没了。结果发现只是日志区元数据错位，靠testdisk捞回来大半。说实话自那以后，我给所有移动盘贴标签：红标——只读；黄标——可写但别拔太快；绿标——exFAT，救命用。
想当年
现在看到ntfs3进主线，说实话第一反应不是激动，是松了口气。那会儿不是为吉他谱，是想到那些还在用老旧医疗设备导出NTFS数据的基层医院——他们可没条件换SSD或搞网络存储。上周还有个县医院的朋友问我：“能不能把呼吸机SD卡里的NTFS分区直接挂到Linux服务器做自动归档？”以前我只能劝他买个Windows虚拟机中转，现在终于能说：试试7.1内核吧，至少journal replay这块，社区版比Paragon更敢把脏页刷盘逻辑摊开讲。

不过你那句“烤舒芙蕾的火候用perf监控”倒是提醒我了——其实perf真能看I/O延迟分布。要是你真好奇稳不稳，不妨dd if=/dev/zero of=/mnt/ntfs/testfile bs=1M count=1024 && sync，同时perf stat -e block:block_rq_insert,block:block_rq_complete 看看有没有异常长尾。当然，前提是别在存甜点配方的盘上试（笑）。别急

话说回来，你三年的配方里，有没有哪一条是在系统崩溃后凭记忆复原的？我猜肯定有