在Btrfs文件系统下使用cp --reflink意外修复损坏视频文件，原因是什么？

嘿，这个神奇的现象其实是Btrfs的写时复制特性加Transmission的文件标记逻辑共同导致的，我给你拆解清楚：

首先得先搞懂cp --reflink在Btrfs上到底干了啥——它并没有真的把视频数据复制一份，而是创建了一个和原文件共享所有数据块的副本。只有当你修改其中一个文件时，Btrfs才会真正复制被修改的那块数据，这就是写时复制（CoW）的核心逻辑。

那为啥原文件打不开、副本却能正常播放呢？问题出在Transmission对损坏文件的标记方式上：

• Transmission发现部分数据损坏后，并没有直接破坏视频的实际数据块，而是在原文件的扩展属性（xattr）或者特殊元数据里记录了“这个文件有损坏块需要重下”的标记。
• 当你用默认的cp --reflink复制时，cp命令不会自动复制文件的扩展属性这类额外元数据（除非你加上--preserve=all参数），所以副本完全没带上这个“损坏标记”。
• 而视频的实际数据块其实是完整可读取的，Celluloid播放器不会识别Transmission的专属标记，自然就能正常解析播放了。

你可以做两个小测试验证这个逻辑：

• 试试用cp --preserve=all --reflink original.mkv test3.mkv创建副本，这个副本大概率和原文件一样打不开，因为它把原文件的所有属性（包括损坏标记）都复制过来了。
• 用getfattr original.mkv和getfattr test.mkv分别查看两个文件的扩展属性，对比一下就能发现原文件多了一些Transmission相关的特殊属性。

简单说就是：原文件是被Transmission“标记”为损坏，而非数据真的没法读；cp --reflink的副本没继承这个标记，所以播放器能正常识别播放。

备注：内容来源于stack exchange，提问作者Jo-Erlend Schinstad