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