在lzo压缩的BtrFS之间复制：去压缩/重新压缩？

不是真的，这涉及到系统调用。 举个例子：

open ("tuppence", O_RDONLY) = 3 fstat (3, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 open ("/tmp/tuppence", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 fstat (4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 read (3, "I have cheese.\n", 32768) = 15 write (4, "I have cheese.\n", 15) = 15 

（这是strace数据，为了清晰起见清理了一下，在复制文件时完成了。）

要将一个文件从A点复制到B点，尤其是在不同的安装点上，Linux将调用read文件来复制文件，然后调用新的文件。 你可以在上面的轨迹中看到它。

1. 打开源文件，生成文件描述符号3。
2. 打开目标文件，产生文件描述符号码4。
3. 从源文件第3章中读取。
4. 将从3中读入的数据写入目标文件描述符4中。
5. closures一切。

read系统调用请求文件供进程使用，触发BTRFS解压缩。 这个检索的数据然后被送入write调用，这将触发目标上的BTRFS压缩。 这个行为是Linux文件系统层如何工作的基础。

要绕过这个，不要使用cp 。 您将不得不使用特定于btrfs的工具来处理完全在btrfs卷中移动的数据结构。 问题是，我不知道这些工具是否存在。

如@ sysadmin1138所示，如果在文件系统中使用cp / rsync / send – receive ，这个问题是不可避免的。 但在某些情况下有办法避免它。 如果您使用种子设备，添加一个新设备（如raid1），然后删除种子，您将得到一个与源相同的重复卷。 （虽然UUID会改变。）

正如开发人员名单上指出的那样：“…复制卷本质上与源（过程复制块）相同，这意味着块configuration文件也被保留。

作为关于我的具体用例的说明，我可以使用这种方法来复制，完成我的服务器安装到一个子卷，然后只是mv的文件。 这将节省大量的工作。