☰

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

tag-icon • tag-icon compression btrfs cp
在 lzo 压缩的 BtrFS 之间复制：解压缩/重新压缩？

我正在同一台机器上安装的不同驱动器上的两个 lzo 压缩 BtrFS 文件系统之间复制大量文件。文件似乎正在被解压缩/重新压缩。有没有办法避免这种情况？

答案1

事实并非如此，这取决于系统调用。举个例子：

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要复制的文件，然后调用write新文件。您可以在上面的跟踪中看到它。

  1. 打开源文件，得到文件描述符编号 3。
  2. 打开目标文件，得到文件描述符编号 4。
  3. 从描述符 3（源文件）读取。
  4. 将从3读入的数据写入目标文件描述符4中。
  5. 关闭所有东西。

系统read调用请求文件供进程使用，从而触发 BTRFS 解压缩。然后将检索到的数据输入到调用中write，这将触发目标上的 BTRFS 压缩。此行为是 Linux 文件系统层工作方式的基础。

要绕过此问题，请不要使用cp。您必须使用专门用于 btrfs 的工具来处理完全在 btrfs 卷内移动的数据结构。问题是，我不知道是否存在这样的工具。

答案2

正如@sysadmin1138 所说明的那样，如果在文件系统中使用cp/ rsync/ send- ，则无法避免此问题receive；但在某些情况下有一种方法可以避免它。如果您使用种子设备，添加新设备（如 raid1），然后删除种子，您将获得与源基本相同的重复卷。（尽管 UUID 会发生变化。）

正如开发列表中指出的那样，“... 重复的卷本质上与源相同（该过程复制块），这意味着块配置文件也被保留。”

关于我的具体用例，我可以使用这种方法进行复制，将服务器安装到子卷中，然后将mv文件复制过来。这样可以节省大量工作。

相关内容