Существуют ли сценарии дедупликации, которые используют btrfs CoW для дедупликации?

В Linux существует множество инструментов для дедупликации, см., Например, эту вики-страницу .

Практически все сценарии выполняют только обнаружение, распечатку дубликатов имен файлов или удаление дубликатов файлов путем привязки их к одной копии.

С появлением btrfs появится еще один вариант: создание копии файла (например, копирование при записи) в формате CoW cp reflink=always. Я не нашел никакого инструмента, который делает это, кто-нибудь знает инструмент, который делает это?

Я написал постель для этой цели. Он сочетает в себе пошаговое сканирование дерева с дедупликацией CoW. Лучше всего использовать с Linux 3.6, где вы можете запустить:

sudo bedup dedup

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

Что мучительно медленно.

Другие программы, такие как rdfind и rmlint, сканируют по-разному.

В rdfind есть «экспериментальная» функция для использования btrfs reflink. (И «твердые» варианты для жестких ссылок, символических ссылок и т. Д.)

У rmlint есть «твердые» опции для клонирования btrfs, reflink, обычных жестких ссылок, символических ссылок, delete и ваших собственных пользовательских команд.

Но что более важно, rdfind и rmlint значительно быстрее. Как и на порядки. Вместо того, чтобы проверять все целевые файлы на наличие контрольных сумм, он делает это примерно:

• Сканирование всей целевой файловой системы, собирая только пути и размеры файлов.
• Удалить из рассмотрения файлы с уникальными размерами файлов. Это само по себе, сэкономить время и дисковую активность. («Scads» - это некоторая обратная экспоненциальная функция или что-то в этом роде.)
• Из оставшихся кандидатов просканируйте первые N байтов. Удалить из рассмотрения те, которые имеют одинаковые размеры файлов, но разные первые N байтов.
• Сделайте то же самое для последних N байтов.
• Осталось только то, что осталось (обычно крошечная доля), поиск контрольных сумм.

Другие преимущества rmlint, о которых я знаю:

• Вы можете указать контрольную сумму. мд5 тоже страшно? Попробуйте sha256. Или 512. Или побитовое сравнение. Или ваша собственная функция хеширования.
• Это дает вам возможность Btrfs "clone" и "reflink", а не просто reflink. "cp --reflink = всегда" просто немного рискованно, потому что это не атомарно, оно не знает, что еще происходит с этим файлом в ядре, и не всегда сохраняет метаданные. «Клон», OTOH (это сокращенное обозначение ... я отказываюсь от официального имени, связанного с API), является вызовом уровня ядра, который является атомарным и сохраняет метаданные. Почти всегда приводит к одному и тому же, но чуть более надежно и безопасно. (Хотя большинство программ достаточно умны, чтобы не удалять дубликат файла, если он не может сначала сделать временную ссылку на другой файл.)
• Он имеет множество вариантов для многих вариантов использования (что также является недостатком).

Я сравнил rmlint с deduperemove - который также вслепую сканирует все контрольные файлы на предмет контрольных сумм. Duperemove занял несколько дней на моем томе, чтобы завершить (4, я думаю), идя полный наклон. fmlint потребовалось несколько часов для выявления дубликатов, а затем менее одного дня для их дедупликации с помощью клона Btrfs.

(Тем не менее, каждый, кто прилагает усилия для написания и поддержки качественного, надежного программного обеспечения и раздает его бесплатно, заслуживает большой похвалы!)

Кстати: вы должны избегать дедупликации, используя обычные жесткие ссылки в качестве «общего» решения для дедупликации, любой ценой.

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

Например, многие программы генерируют шаблоны и / или скрытые файлы настроек (иногда в каждой видимой папке), которые изначально идентичны - и большинство остается таковым, пока вы, пользователь, не нуждаетесь в них.

В качестве конкретной иллюстрации: файлы кэша миниатюр фотографий, которые генерируются бесчисленными программами в папке, содержащей фотографии (и по веской причине - переносимость), могут занять часы или дни, но затем сделать приложение для фотографий быстрым. Если все эти исходные файлы кэша жестко связаны друг с другом, то позже вы откроете приложение в каталоге, и оно создаст большой кэш ... а затем догадайтесь, что: теперь КАЖДАЯ папка с ранее жестко связанным кешем теперь имеет неправильный кеш. Потенциально, с катастрофическими результатами, которые могут привести к случайному уничтожению данных. А также потенциально может взорвать решение для резервного копирования, которое не поддерживает жесткие ссылки.

Кроме того, он может испортить целые снимки. Смысл моментальных снимков в том, что «живая» версия может продолжать меняться с возможностью отката к предыдущему состоянию. Если все жестко связаны между собой ... вы "откатываетесь" на одно и то же.

Хорошая новость заключается в том, что дедупликация с помощью Btrfs clone / reflink может отменить это повреждение (я думаю - поскольку во время сканирования он должен видеть жестко связанные файлы как идентичные ... если у него нет логики, чтобы не учитывать жесткие ссылки. Это, вероятно, зависит от конкретная утилита, делающая дедупликацию.)