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

Я копирую большое количество файлов между двумя сжатыми lzo файловыми системами BtrFS на разных дисках, смонтированных на одной машине. Похоже, что файлы де / повторно сжаты. Есть ли способ избежать этого?

Источник

2 ответа

Решение

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

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

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

Источник

Не совсем, и это сводится к системным вызовам. Есть пример:

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

(Это обычные данные, немного очищенные для ясности, сделанные при копировании файла.)

Чтобы скопировать файл из точки A в точку B, особенно через точки монтирования, Linux будет вызывать read на файл, который будет скопирован, а затем позвоните write на новый. Вы можете видеть это в приведенном выше следе.

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

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

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

Источник
Другие вопросы по тегам