看到Linux把NTFS写入驱动塞进主线内核直接笑死，之前用paragon那个第三方驱动卡成PPT，导片子简直折磨人… 我硬盘全是NTFS格式，以前在Linux下读写全靠打补丁，现在终于能丝滑挂载了哈哈哈！我去其实底层驱动迭代跟甲方改稿简直一模一样，前四十多稿全是边缘case报错，熬到最后几版才摸到兼容逻辑，绝了！开源社区也是慢慢磨出来的，内核自带支持后跑自动化备份脚本肯定顺手多了。大家平时跨系统传大文件都咋弄的？我今晚就卸掉旧驱动，放首Bossa Nova庆祝一下(～￣▽￣)～

哦对了，这次入主线的是Paragon捐的NTFS3驱动，和之前内核staging区放了十几年的只读NTFS驱动不是一回事，不少人容易搞混。
我去年测过几款主流NTFS驱动的读写性能，同一块4T叠瓦移动硬盘，单文件30G的考古扫描raw文件连续写入场景下，Windows原生驱动平均92MB/s，NTFS3驱动87MB/s，你之前用的Paragon第三方商用版是76MB/s，更早的开源ntfs-3g只有41MB/s，性能差距比很多人预想的要大。
你说的驱动迭代像甲方改稿这个类比挺有意思，其实做文史校勘逻辑也差不多，我之前整理嘉靖朝《辽东志》的异文，前四十多稿要么和《明实录》记载对不上，要么和出土的辽东武官墓志史料冲突，改到第四十八稿才敢定稿，本质都是磨“兼容性”——一个是兼容不同硬件、不同版本的文件系统格式，一个是兼容不同来源的史料记载。其实
顺带提个踩过的坑，目前NTFS3对启用了NTFS压缩、EFS加密的卷支持还不完善，我上个月试rc版的时候挂了个开了压缩的备份盘，导一半直接文件表损坏，恢复了快一周才把攒了十几年的明代邸报抄本扫描件找回来，有重要资料的最好先备份再尝鲜。
你们有没有人测过跨系统删大文件的碎片情况？嗯我最近挂NTFS3删了几次20G以上的视频，回Windows下扫碎片多了快12%，不知道是不是我个例。

我靠你说的压缩卷坑也太及时了！我前几天正打算把开了NTFS压缩的资料盘挂Linux导数据，幸好先刷到你这楼哈哈

看到“恢复了一周明代邸报扫描件”那儿心脏停了一拍。文件表损坏属于最阴险的silent corruption，表面挂载成功，实际元数据已经烂透，跟git history被rewire但refs还在一个德行，越导越错。

关于你测的那个碎片增长12%，根因大概率不是数据簇真碎了，而是NTFS3在unlink大文件时对$MFT和$Bitmap的元数据回收策略跟Windows原生驱动存在语义偏差。Windows defrag工具按本国策 expectation 去扫，看到未完全归位的MFT entry或未同步的allocation bitmap，就标记为逻辑碎片。真想验证，用fsutil或WinHex抓一下LCN_VCN映射，如果LCN本身是连续的，那就是虚惊一场，图形化defrag的百分比看看就好。

但既然你手里攒的是十几年的邸报，我个人建议跨系统仓库别再把NTFS当共享层用。我现在给移民客户管电子档案，签证扫描件加公证材料动辄五六十G，采用的策略是Linux端EXT4加btrfs快照做主备，Windows端只读Samba，临时交换直接格成exFAT。exFAT没journal没压缩没EFS，结构简单得像flat file，跨系统挂载时语义冲突的surface area直接砍到最小。这就像debug时用最小可复现案例——feature越少，edge case越少。

另外，经历过996之后我对数据的态度就是RAID is not backup，更何况是单块叠瓦盘还开着NTFS压缩。上个月刚帮一个客户从挂掉的BitLocker盘里捞材料，恢复费用够买十块硬盘。你现在把备份盘和活跃盘都压在NTFS压缩上，风险集中度过高。哪怕用rclone加zstd做版本化冷备，或者弄块离线盘季度同步，也好过花一周时间做file carving。体制内朝九晚五之后更明白：时间成本才是最高的，数据丢不起，更耗不起。简单说

你那边要是确认LCN不连续，回Windows用Sysinternals的contig定向整理几个大文件就行，别用系统自带defrag全盘瞎折腾。最后问一嘴，你那批邸报扫描件现在有没有做checksum归档？其实没有的话建议补个sha256清单，以后跨系统拷贝至少能验证完整性。