Дедупликация на уровне раздела
Можно совместно использовать весь из /usr пока все виртуальные машины работают идентичный (или почти идентичные) версии того же распределения Unix на той же архитектуре процессора (если у Вас есть различная архитектура, можно совместно использовать /usr/share, но это, вероятно, не стоит того). Вы можете или не можете хотеть совместно использовать /usr/local. Если Вы не делаете, сделайте это отдельной точкой монтирования в каждом VM или сделайте это символьной ссылкой на что-то как ../opt/local внутри /usr.
Необходимо заботиться это /usr смонтирован только для чтения в каждом VM, или что Вы используете файловую систему, которая позволяет совместно использовать. Отметьте это если /usr смонтирован как только для чтения в любом VM, даже тот, который в спящем режиме, Вы не можете записать в /usr всегда. Таким образом, вероятно, было бы намного более удобно (но возможно немного медленнее) смонтироваться /usr через удаленную файловую систему, а не от образа диска в каждом VM. Если Вы используете единственную технологию виртуальной машины, используете ее функцию совместно используемой папки при наличии (так /usr смонтирован в некотором месте на хосте). Иначе используйте NFS с хостом, экспортирующим каталог (снова, хосту смонтировали каталог где-нибудь).
Для установки большинство установщиков должно позволить Вам монтироваться /usr как NFS в “опытном режиме”. Доступ к совместно используемой папке, вероятно, будет более трудным на данном этапе. Если Вы не можете сделать его, сделать /usr отдельная файловая система на отдельном виртуальном диске, затем скопируйте содержание и избавьтесь от виртуального диска.
Когда дедупликация блочного уровня идет, я думаю, что ZFS является неоспоримой лучшей реализацией в настоящее время. Это действительно не разработано для после совершения оптимизации, потому что ее дедупликация (если включено) создается непосредственно в функции чтения-записи. Из-за этого это может быть немного памяти, дорогой при загрузке в попытке сохранить самые соответствующие части таблицы дедупликации в памяти, но ZFS способен ограничивать себя потреблением не намного больше чем 50% памяти, которая в зависимости от количества установленной памяти, мог казаться довольно произвольным (50% 2 ГБ по сравнению с 50% 64 ГБ, особенно если few-if-any пользовательские задачи, бывшие нужные в памяти).
В зависимости от того, в чем Вы надеетесь использовать его, у Вас есть некоторые опции:
OpenIndiana, кажется, имеет некоторые хорошие Настольные и Параметры сервера, на основе Соляриса
FreeBSD (начиная с 9.0) имеет довольно усовершенствованную версию ZFS (который включает дедупликацию), встроил к нему. Один известный FreeBSD (затем MonoWall) полученное распределение является NAS4Free, который делает создание NAS довольно легким.
Linux имеет несколько опций, некоторых с dedup, другими без. Так как Вы ищете dedup, самым известным, который я видел, является zfsonlinux. Я не уверен, что их прогресс, или насколько стабильный их проект, но это определенно выглядит многообещающим.
Относительно чего-либо с частичной дедупликацией блока, я не видел НИЧЕГО до сих пор, которое сообщает о способности сделать это.
Ваш вопрос немного сбивает с толку из-за термина «блоки», который является очень перегруженным словом, когда речь идет о дисках и файловых системах. (Но окружающий контекст помогает внести ясность. )Btrfs работает не с «блоками» файловой системы фиксированного -размера, а с «экстентами» переменного -размера. (Хотя, что сбивает с толку, также определяет зоны блоков переменного -размера. )ZFS работает с «блоками» файловой системы частично или в основном потому, что это значительно упрощает решение проблем. И Btrfs, и ZFS знают о «блоках» уровня диска -, которые сами по себе являются абстракциями. (Тогда у нас также есть «блок хранения уровня -», который может иметь семантически другое значение. )Возможно, эти описания немного неверны, недостаточно ясны или не на 100% точны. (Если вам нужна ясность и 100% точность по теме блоков, сделайте вид, что не читали. Если вам просто нужно приблизительное понимание, чтобы продолжить, тогда вы должны идти. )Суть этого ответа не в том, чтобы точно определить «блоки», а в приведенном ниже обсуждении, которое гораздо больше в моей рулевой рубке.
Как писал @killermist, ZFS изначально поддерживает дедупликацию [ZFS] на уровне блока -.
По умолчанию эта функция не включена в ZFS. Включение без достаточного количества памяти приводит к сильному снижению производительности. Кроме того, как ни странно, ZFS требуется значительно больше, чем рекомендованное правило «1 ГБ ОЗУ на 1 ТБ хранилища» -из -, чтобы уместить всю хеш-таблицу в ОЗУ. Но даже в этом случае, в зависимости от аппаратного обеспечения, вы все равно можете получить скорость записи до 40 МБ/с. Я получаю это на технологии эры 2008 -, работающей на дисках эры ~2015 -. Вполне приемлемо для меня в основном архивные данные. Самый большой недостаток дедупликации ZFS заключается в том, что еще не существует элегантного способа сделать это в режиме «пакетный/автономный» (или, точнее, «вне -диапазона -» ), кроме включение дедупликации, копирование всего в новый временный каталог в той же файловой системе,удаление оригиналов, затем перемещение (теперь -дедуплицированного )временного содержимого обратно. (За исключением того, что удаление старых файлов может занять больше времени, чем первоначальная операция копирования/дедупликации. )Что я обычно делаю, так это жду, пока мне все равно придется периодически перестраивать массив, чтобы изменить базовую структуру и копировать из старого массива в новый с включенной дедупликацией.
Дедупликация Btrfs, возможно, немного сложнее, и в настоящее время доступны только сторонние -утилиты для выполнения этой работы. (Но которые используют либо хорошо -поддерживаемые API ядра, и/или хорошо поддерживаемую опцию cp; и в любом случае требуется их собственная логика для определения дубликатов, которые, как можно надеяться, не соответствуют -точности. )Тем не менее, одним из потенциальных преимуществ является то, что коммунальные услуги находятся «вне -диапазона -». Однако цена большинства утилит заключается в том, что они убивают производительность, работая --, что может занять часы, дни и даже недели. (Лично я предпочел бы иметь дело с всегда более медленной производительностью записи в -полосе дедупликации ZFS, чем забивать свои жесткие диски целыми днями, скажем, раз в год.)
Я знаю два решения Btrfs, которые имеют дело с «блоками» (, но в еще одном определении ), а не с файлами, это пчелы и dduper .
Bees, например, произвольно определяет размер «блока» для себя при первом запуске, основываясь на доступной памяти и, возможно, других факторах. (Хотя я, вероятно, искажаю его назначение, функции, механизм и плюсы/минусы, поскольку я им не пользуюсь, я только недавно оценил его как вариант.)
Bees, возможно, немного гибридный -, так как он предназначен для непрерывной работы, а не так сильно ударяет по дискам --, хотя технически все еще не находится в -диапазоне, как дедупликация ZFS. Он просто подбирает дубликаты после -факта -и пытается их дедуплицировать легким прикосновением.Работа с произвольно -определенным размером блока означает, что по замыслу он будет соответствовать хеш-таблице в ОЗУ. Недостаток (предположительно )заключается в том, что в «блоке» могут быть одинаковые экстенты, но пчелы не могут выполнять дедупликацию, потому что «блоки», в которых они находятся, в остальном разные.
Имейте в виду, что даже утилиты, специально выполняющие дедупликацию Btrfs на «файловом» -уровне (, такие как bedup , duperemove , rmlint и другие ), могут по-прежнему удовлетворять вашим требованиям. Я не могу быть уверен, но кажется, что они будут. Это потому, что даже команда «cp --reflink=always» на самом деле не выполняет дедупликацию «файлов». Он выполняет дедупликацию экстентов Btrfs . Когда пересвязанный «файл» изменяется, Btrfs только un -дедуплицирует измененные экстенты до их собственных уникальных экстентов. Остальная часть файла остается дедуплицированной. Вот как большие дедуплицированные файлы могут по-прежнему расходиться, как если бы это были их собственные уникальные файлы, но при этом быть в основном дедуплицированными.
(По этой же причине так сложно определить, перелинкован ли «файл» или нет, потому что эта концепция даже не имеет смысла. Все экстенты файла сами по себе могут быть связаны с другими такими же -экстентами, концепция, которая имеет смысл, но по совпадению это особенно сложный вопрос для ответа. Вот почему, если утилита дедупликации Btrfs не отслеживает то, что она уже дедуплицировала, не стоит пытаться «обнаружить», если файл уже дедуплицирован. Нет такого атрибута, как refcount для проверки. В любом случае проще снова дедуплицировать его. Напротив, определение того, является ли весь файл жестко связанным старым -способом, тривиально. Просто проверьте количество st _nlink для данного inode.)
Отсутствие «клонирования всего файла» на самом деле является неотъемлемой чертой всех файловых систем CoW, поддерживающих «бесплатные» моментальные снимки и/или дедупликацию.и это правда, независимо от того, имеете ли вы дело с экстентами Btrfs, блоками ZFS или чем-то еще. Вот почему любой из них, вероятно, может быть ответом на ваш вопрос. (Есть по крайней мере три другие файловые системы CoW, которые могут или планируют сделать все это, что мне известно о :nilfs2, bcachefs и xfs.)
Хотя вы не упомянули об этом, насколько мне известно, ни одна технология дедупликации не поддерживает тип файла -. Другими словами, ни один дедупликатор не может пропустить метаданные *.jpg и рассматривать для дедупликации только данные сжатого изображения. Точно так же ни один из них не учитывает магические номера файлов (, по крайней мере, для определения того, что следует учитывать при дедупликации ). Это может быть убийственной функцией --, хотя, безусловно, требует постоянных непрерывных обновлений определений. И это может быть очень сложно спроектировать, при этом рассматривая файлы как абстрактный M :M набор экстентов, блоков и т. д.