Вот-вот выйдет релиз OpenZFS 2.3.0 с новой функцией Fast Dedup. Это огромный шаг вперёд по сравнению со старой дедупликацией и отличный фундамент для будущих доработок.

Контрибьютор OpenZFS @gmelikov и команда VK Cloud совместно перевели статью об этом релизе, в которой новая функция сравнивается со старой дедупликацией и описывается максимально подробно с практическими примерами. В 2023–2024 коллеги из Klara много работали над этой функцией, и мы согласны с ними, что она весьма хороша! 

После релиза Fast dedup на многих ресурсах в обсуждениях продолжили писать, что «новый дедуп всё так же плох, он требует столько же ОЗУ и также убивает производительность». Но эта информация лишь отчасти близка к правде и повторяет всё тот же мотив, который когда-то кто-то озвучивал на форумах.

Винить в этом никого не хочется. И не стоит, так как дедупликация в OpenZFS и правда была очень требовательной к правильному применению. Найти качественные гайды тоже не просто, ответ по умолчанию — «не используйте её» — был и (в целом) остаётся правильным. Но, по прошествии почти 20 лет жизни дедупа в OpenZFS, настало время вернуться к этому вопросу.

Посмотрим на свежую информацию об имплементации дедупа в OpenZFS, как он работал до улучшений, в чём была его проблема, что поменяли в fast dedup, и почему же это всё ещё не дефолт.

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.

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

На прошлой неделе один из разработчиков FreeBSD Matt Macy выдвинул предложение об использовании реализации ZFS от проекта ZFSonLinux. Таким образом все требуемые изменения для FreeBSD будут сразу интегрированы в кодовую базу ZFSonLinux. Предложением это не завершилось, уже создан форк, в котором производятся требуемые доработки, а также получено одобрение core разработчиков ZFSonLinux на включение доработок для FreeBSD в единую кодовую базу.

Положительная ли это новость? Конечно же да! Суть в концентрации всех причастных к проекту OpenZFS разработчиков в одном месте, в одной кодовой базе.