Назад | Перейти на главную страницу

Копирование между сжатой lzo BtrFS: де / повторное сжатие?

Я копирую большое количество файлов между двумя сжатыми 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 на файл, который нужно скопировать, а затем вызовите write по новой. Вы можете увидеть это на графике выше.

  1. Откройте исходный файл, получив в результате дескриптор файла номер 3.
  2. Откройте целевой файл, получив номер дескриптора файла 4.
  3. Прочтите из описания 3, исходный файл.
  4. Запишите данные, считанные из 3, в дескриптор 4, целевой файл.
  5. Закройте все.

В read syscall запрашивает файл для использования процессом, который запускает распаковку BTRFS. Полученные данные затем передаются в write вызов, который запустит сжатие BTRFS на цели. Это поведение является фундаментальным для работы слоев файловой системы Linux.

Чтобы обойти это, не используйте cp. Вам придется использовать специальный инструмент для btrfs, который полностью обрабатывает перемещение структур данных в томе btrfs. Проблема в том, что я не знаю, существуют ли такие инструменты.

Как хорошо проиллюстрировал @ sysadmin1138, эта проблема неизбежна при использовании cp/rsync/send-receive через файловые системы; но есть способ избежать этого при определенных обстоятельствах. Если вы используете семенное устройство, добавьте новое устройство (как raid1), а затем удалите семя, вы получите дублированный том, который по сути совпадает с исходным. (Хотя UUID изменится.)

Как указано в списке разработчиков, «... дублированный том по сути совпадает с источником (процесс копирует фрагменты), что означает, что профиль фрагментов также сохраняется».

В качестве примечания относительно моего конкретного варианта использования я мог бы использовать этот метод для копирования, выполнить установку моего сервера в подобтоме, а затем просто mvфайлы закончились. Это сэкономило бы значительный объем работы.