Какие существуют решения для дедупликации на уровне блоков или более детальной?
Существуют файловые решения с подходом «Копирование при записи».
Я ищу "копирование при записи" на уровне блоков, чтобы я мог периодически искать общие блоки или, что предпочтительнее, части файлов, объединять их и отмечать для использования способом CoW. Есть ли что-то подобное, или его все равно нужно создать? Я не уверен, является ли дедупликация Btrfs уровнем блока/файла/подчасти? Есть LessFS, но я не уверен, какой уровень дедупликации он обеспечивает? Может быть, есть другое решение?
решение1
Что касается дедупликации на уровне блоков, я думаю, что ZFS — это неоспоримая лучшая реализация на данный момент. Она действительно не предназначена для оптимизации постфактум, поскольку ее дедупликация (если она включена) встроена непосредственно в функции чтения/записи. Из-за этого она может быть немного затратной по памяти под нагрузкой, пытаясь сохранить в памяти наиболее важные части таблицы дедупликации, но ZFS хорошо ограничивает себя потреблением не более 50% памяти, что в зависимости от количества установленной памяти может показаться довольно произвольным (50% от 2 ГБ против 50% от 64 ГБ, особенно если мало или вообще нет пользовательских задач, требующих памяти).
В зависимости от того, где вы собираетесь его использовать, у вас есть несколько вариантов:
ОткрытьИндианапохоже, есть несколько хороших вариантов для настольных ПК и серверов на базе Solaris
FreeBSD (начиная с 9.0) имеет довольно продвинутую версию ZFS (включая дедупликацию), встроенную в нее. Один из известных дистрибутивов, производных от FreeBSD (тогда MonoWall), этоNAS4Free, что значительно упрощает создание NAS.
Linux имеет несколько вариантов, некоторые с дедупликацией, другие без. Поскольку вы ищете дедупликацию, наиболее примечательным из тех, что я видел, являетсяzfsonlinux. Я не уверен, каков их прогресс и насколько стабилен их проект, но он определенно выглядит многообещающим.
Что касается частичной дедупликации блоков, то я пока не видел НИЧЕГО, что сообщало бы о возможности сделать это.
решение2
Ваш вопрос немного сбивает с толку из-за термина «блоки», который является очень перегруженным словом, когда речь идет о дисках и файловых системах. (Но ваш окружающий контекст помогает прояснить ситуацию.) Btrfs не имеет дела с «блоками» файловой системы фиксированного размера, она имеет дело с «экстентами» переменного размера. (Хотя, что сбивает с толку, также определяет зоны блоков переменного размера.) ZFS имеет дело с «блоками» файловой системы, отчасти или в первую очередь потому, что это представляет значительно более простые для решения проблемы. И Btrfs, и ZFS знают о «блоках» на уровне дисков, которые сами по себе являются абстракциями. (Затем у нас также есть «хранилище на уровне блоков», которое может иметь семантически разное значение.) Я могу немного ошибаться в этих описаниях, быть недостаточно ясными или не на 100% точными. (Если вам нужна ясность и 100% точность по теме блоков, сделайте вид, что вы этого не читали. Если вам нужно просто общее понимание, чтобы продолжить, то вы можете продолжать.) Основная цель этого ответа — не в том, чтобы идеально определить «блоки», а в обсуждении ниже, которое гораздо больше относится к моей компетенции.
Как написал @killermist, ZFS изначально поддерживает дедупликацию на уровне блоков [ZFS].
По умолчанию в ZFS он не включен. Включение его без достаточного объема памяти приводит к значительному снижению производительности. Кроме того, по некоторым данным, ZFS требуется значительно больше, чем рекомендуемое правило "1 ГБ ОЗУ на 1 ТБ хранилища", чтобы уместить всю хеш-таблицу в ОЗУ. Но даже в этом случае, в зависимости от оборудования, вы все равно можете получить скорость записи свыше 40 МБ/с. Я получаю это на технологиях 2008 года, работающих на дисках ~2015 года. Для меня это вполне приемлемо для в основном архивных данных. Самый большой недостаток дедупликации ZFS заключается в том, что пока нет элегантного способа сделать это в "пакетном/автономном" (или, точнее, "внеполосном") режиме, кроме включения дедупликации, копирования всего в новый временный каталог в той же файловой системе, удаления оригиналов, а затем перемещения (теперь уже дедуплицированного) временного содержимого обратно. (За исключением того, что удаление старых файлов может занять больше времени, чем первоначальная операция копирования/дедупликации.) Обычно я жду, пока мне в любом случае придется периодически перестраивать архитектуру массива, чтобы изменить его базовую структуру, и копирую данные из старого массива в новый с включенной дедупликацией.
Дедупликация Btrfs, возможно, немного более поверхностна, и в настоящее время доступны только сторонние утилиты для выполнения этой работы. (Но которые используют либо хорошо поддерживаемые API ядра, и/или хорошо поддерживаемую опцию cp; и в любом случае требуют собственной логики для определения дубликатов, что, как можно надеяться, абсолютно точно.) Однако одно потенциальное преимущество заключается в том, что эти утилиты «внеполосные». Однако цена большинства утилит заключается в том, что они убивают производительность, работая вхолостую — на что могут уйти часы, дни, даже недели. (Лично я бы предпочел иметь дело с постоянно более медленной скоростью записи внутриполосной дедупликации ZFS, чем работать с моими жесткими дисками в течение нескольких дней, скажем, один раз в год.)
Я знаю два решения Btrfs, которые работают с «блоками» (но в другом определении), а не с файлами:пчелы, иддупер.
Например, Bees произвольно определяет для себя размер «блока» при первом запуске, основываясь на доступной памяти и, возможно, других факторах. (Хотя я, вероятно, неверно представляю его цель, возможности, механизм и плюсы/минусы, поскольку я им не пользуюсь, а только недавно оценил его как вариант.)
Bees, возможно, немного гибридный, так как он разработан для непрерывной работы и не так сильно долбит диски, хотя технически он все еще не "внутриполосный", как дедупликация ZFS. Он просто подбирает дубликаты постфактум и пытается дедуплицировать их легким прикосновением. Работа с произвольно определенным размером блока означает, что по замыслу он будет соответствовать хеш-таблице в оперативной памяти. Недостаток (предположительно) заключается в том, что в "блоке" могут быть одинаковые экстенты, но Bees может не выполнять дедупликацию, потому что "блоки", в которых они находятся, в остальном различны.
Имейте в виду, что даже утилиты, которые специально выполняют дедупликацию Btrfs на уровне «файлов» (например,постель вверх,duperemove,рмлинт, и другие), все еще могут удовлетворить ваши требования. Я не уверен, но похоже, что они удовлетворят. Это потому, что даже команда "cp --reflink=always" на самом деле не дедуплицирует "файлы". Она дедуплицирует Btrfsэкстенты. Когда перелинкованный "файл" изменяется, Btrfs только отменяет дедупликацию измененных экстентов, до их собственных уникальных экстентов. Остальная часть файла остается дедуплицированной. Вот как большие дедуплицированные файлы могут по-прежнему расходиться, как будто это их собственные уникальные файлы, но при этом быть в основном дедуплицированными.
(Вот почему так сложно определить, ссылается ли «файл» на что-то повторно или нет, потому что эта концепция на самом деле не имеет смысла. Все файлыэкстенты(Сами по себе могут быть повторно связаны с другими теми же экстентами, концепция, которая имеет смысл, но это, по совпадению, особенно сложный вопрос для ответа. Вот почему, если только утилита дедупликации Btrfs не отслеживает то, что она уже дедуплицировала, не стоит усилий, чтобы попытаться «обнаружить», был ли файл уже дедуплицирован. Нет такого атрибута, как refcount, который можно было бы проверить. В любом случае проще просто дедуплицировать его снова. Напротив, определение того, связан ли весь файл жесткой ссылкой старомодным способом, тривиально. Просто проверьте счетчик st_nlink для данного inode.)
Отсутствие "целостного клона файла" на самом деле является неотъемлемой чертой всех файловых систем CoW, которые поддерживают "свободные" снимки и/или дедупликацию, и это справедливо независимо от того, идет ли речь о Btrfs-экстентах, блоках ZFS или чем-то еще. Вот почему любой из них, вероятно, может быть ответом на ваш вопрос. (Существует по крайней мере три других файловых системы CoW, которые могут или планируются иметь возможность делать все это, насколько мне известно: nilfs2, bcachefs и xfs.)
Хотя вы об этом не упомянули, насколько мне известно, ни одна технология дедупликации не учитывает типы файлов. Другими словами, ни один дедупликатор не умеет пропускать метаданные *.jpg и учитывать только сжатые данные изображения для дедупликации. Точно так же ни один из них не учитывает магические числа файлов (по крайней мере, для определения того, что следует учитывать для дедупликации). Это может быть убийственной функцией, хотя, безусловно, требует постоянных, текущих обновлений определений. И может быть действительно сложным в проектировании, при этом рассматривая файлы как абстрактную коллекцию экстентов, блоков и т. д. M:M.