Буквально на днях релизнули свежую stable версию ZFSonLinux, проекта, который теперь является центральным в мире разработки OpenZFS. Прощай, OpenSolaris, здравствуй свирепый GPL-CDDL несовместимый мир Linux.
Под катом обзор самых интересных вещей (ещё бы, 2200 коммитов!), а на десерт — немного интриг.
Конечно же, самая ожидаемая — нативное шифрование. Теперь можно зашифровать только нужные датасеты встроенным в ZFS шифрованием, и (по моему — главное) — вы можете отправлять зашифрованные данные через zfs send и БЕЗ расшифровки проверять целостность данных встроенными средствами, все возможности по сохранению целостности данных ZFS будут при вас!
Далее по важности стоит упомянуть давно ожидаемый TRIM. Да, он очень долго добирался до продакшена. Отчасти потому, что для CoW файловых систем не так критична проблема с износом SSD. Но теперь мы все спокойны - zpool trim спасёт наши нежные флешки.
Теперь можно удалять случайно добавленные vdev массивы из пула (но только, если это sparse или mirror). Полезная мелочь.
Далее в нашем хит-параде — pool checkpoints. Кратко — снапшоты для всего состояния пула, НО дающие возможность откатить изменения не только данных, но и включенных на пуле features и изменений в структуре. Ещё одна возможность обезопаситься.
Pool initialization — заполнение нижележащего хранилища нулями. Полезно для работы в средах с thin provisioned дисками для явного выделения пространства и исключения неожиданных просадок по производительности в дальнейшем.
Project accounting and quota — в уже имеющемся механизме квот теперь возможно использовать разделение на проекты.
Channel programs — возможность выполнять административные задачи атомарно с помощью Lua скриптов. Есть лимиты на время выполнения и память. Если вы занимаетесь автоматизацией — то это для вас.
Direct IO — для простоты прокинули работу Direct IO, внутри ничего не поменялось (просто вызовы идут максимально мимо кеша), зато теперь желающее работать в данном режиме ПО не будет горевать.
Проект Pyzfs влит в основной репозиторий и взят под крыло проекта ZFSonLinux. Теперь есть больше средств для управления из питона (ну и будет спокойнее за поддержку модуля). Также многие python скрипты адаптированы под python3.
Теперь при scrub и resilver операциях сначала вычитываются метаданные, и только потом в максимально последовательном виде — данные. Тем самым восстановление массива и проверка целостности проходят на максимальной скорости.
Allocation classes — у vdev массивов появился тип носителей, теперь можно вынести хранение метаданных/таблиц дедупликации(DDT)/блоков данных менее Х Кбайт на отдельный vdev массив из более производительных дисков. Больше скорости богу скорости! (а по делу — эта возможность очень пригодится в грядущем DRAID).
Многие административные команды теперь работают быстрее за счёт точечного кеширования метаданных (к примеру, zfs list, zfs get).
Процесс аллокации данных параллелизован, теперь для каждого раздела свободного пространства (metaslab) создаётся несколько аллокаторов. С NVME конечно всё не выжмется, но станет лучше.
Отложенное восстановление целостности массива позволит не нагружать массив одновременной пересборкой нескольких дисков, а будет делать это последовательно. Тем самым уменьшится и влияние на производительность, и время пересборки.
При импорте пулов с большим количеством volumes увеличена скорость их регистрации в системе.
Также QAT теперь позволяет выгрузить на него расчёт шифрования и контрольных сумм.
Плюс куча мелких изменений (всё таки 2000+ коммитов в релизе!).
Хотя ZFSonLinux оперативно добавляет поддержку свежих ядер Linux (сейчас поддерживаются версии 2.6.32 — 5.1*), мейнтейнеры ядра проявляют явную незаинтересованность в помощи сторонним модулям ("...we do not care at all about
external kernel modules... — greg k-h"). Так, требуемые для эффективной работы вызовы ядра в ветке 5.0 были изменены на GPL-only . В ядрах с этим патчем производительность ZFS будет значительно хуже. Спасает то, что данную функциональность можно реализовать на стороне модуля, что скорее всего и будет сделано. А пока можете брать пример с NixOS — они просто откатили патч в ядре :)
Также у проекта тоже появился Code of Conduct, что породило волну холиваров. Но мы устояли :)
Всем рабочих бекапов и стабильных релизов!
Полезные ссылки:
— релиз на Github
— моя вводная в ZFS
Под катом обзор самых интересных вещей (ещё бы, 2200 коммитов!), а на десерт — немного интриг.
Новые фишки
Конечно же, самая ожидаемая — нативное шифрование. Теперь можно зашифровать только нужные датасеты встроенным в ZFS шифрованием, и (по моему — главное) — вы можете отправлять зашифрованные данные через zfs send и БЕЗ расшифровки проверять целостность данных встроенными средствами, все возможности по сохранению целостности данных ZFS будут при вас!
Далее по важности стоит упомянуть давно ожидаемый TRIM. Да, он очень долго добирался до продакшена. Отчасти потому, что для CoW файловых систем не так критична проблема с износом SSD. Но теперь мы все спокойны - zpool trim спасёт наши нежные флешки.
Теперь можно удалять случайно добавленные vdev массивы из пула (но только, если это sparse или mirror). Полезная мелочь.
Далее в нашем хит-параде — pool checkpoints. Кратко — снапшоты для всего состояния пула, НО дающие возможность откатить изменения не только данных, но и включенных на пуле features и изменений в структуре. Ещё одна возможность обезопаситься.
Pool initialization — заполнение нижележащего хранилища нулями. Полезно для работы в средах с thin provisioned дисками для явного выделения пространства и исключения неожиданных просадок по производительности в дальнейшем.
Project accounting and quota — в уже имеющемся механизме квот теперь возможно использовать разделение на проекты.
Channel programs — возможность выполнять административные задачи атомарно с помощью Lua скриптов. Есть лимиты на время выполнения и память. Если вы занимаетесь автоматизацией — то это для вас.
Direct IO — для простоты прокинули работу Direct IO, внутри ничего не поменялось (просто вызовы идут максимально мимо кеша), зато теперь желающее работать в данном режиме ПО не будет горевать.
Проект Pyzfs влит в основной репозиторий и взят под крыло проекта ZFSonLinux. Теперь есть больше средств для управления из питона (ну и будет спокойнее за поддержку модуля). Также многие python скрипты адаптированы под python3.
А теперь вкусное — производительность
Теперь при scrub и resilver операциях сначала вычитываются метаданные, и только потом в максимально последовательном виде — данные. Тем самым восстановление массива и проверка целостности проходят на максимальной скорости.
Allocation classes — у vdev массивов появился тип носителей, теперь можно вынести хранение метаданных/таблиц дедупликации(DDT)/блоков данных менее Х Кбайт на отдельный vdev массив из более производительных дисков. Больше скорости богу скорости! (а по делу — эта возможность очень пригодится в грядущем DRAID).
Многие административные команды теперь работают быстрее за счёт точечного кеширования метаданных (к примеру, zfs list, zfs get).
Процесс аллокации данных параллелизован, теперь для каждого раздела свободного пространства (metaslab) создаётся несколько аллокаторов. С NVME конечно всё не выжмется, но станет лучше.
Отложенное восстановление целостности массива позволит не нагружать массив одновременной пересборкой нескольких дисков, а будет делать это последовательно. Тем самым уменьшится и влияние на производительность, и время пересборки.
При импорте пулов с большим количеством volumes увеличена скорость их регистрации в системе.
Также QAT теперь позволяет выгрузить на него расчёт шифрования и контрольных сумм.
Плюс куча мелких изменений (всё таки 2000+ коммитов в релизе!).
Ну и на десерт — интриги
Хотя ZFSonLinux оперативно добавляет поддержку свежих ядер Linux (сейчас поддерживаются версии 2.6.32 — 5.1*), мейнтейнеры ядра проявляют явную незаинтересованность в помощи сторонним модулям ("...we do not care at all about
external kernel modules... — greg k-h"). Так, требуемые для эффективной работы вызовы ядра в ветке 5.0 были изменены на GPL-only . В ядрах с этим патчем производительность ZFS будет значительно хуже. Спасает то, что данную функциональность можно реализовать на стороне модуля, что скорее всего и будет сделано. А пока можете брать пример с NixOS — они просто откатили патч в ядре :)
Также у проекта тоже появился Code of Conduct, что породило волну холиваров. Но мы устояли :)
Всем рабочих бекапов и стабильных релизов!
Полезные ссылки:
— релиз на Github
— моя вводная в ZFS
Комментарии (7)
bormental
31.05.2019 12:43мейнтейнеры ядра проявляют явную незаинтересованность в помощи сторонним модулям
Это ещё мягко сказано. Вот такое вот — это просто мелкое вредительство.
> -EXPORT_SYMBOL_GPL(kernel_fpu_begin); > +EXPORT_SYMBOL(kernel_fpu_begin); ... > -EXPORT_SYMBOL_GPL(kernel_fpu_end); > +EXPORT_SYMBOL(kernel_fpu_end);
Ладно бы, если бы эти функции содержали какое-то know how или реализацию чего-то хоть немного сложного, а не банальное сохранение состояния FPU в согласованном для ядра состоянии. А так это огораживание и просто мелкая палка в колеса.
Они б ещё запретили стороннему коду работать на более чем одном ядре CPU для полного "счастья".
При этом одним из аргументов было "мы не хотим себе дополнительных трудозатрат для не GPL кода". Ага, вот эти 8 символов "лишних" — огромные затраты :)
amarao
Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.
Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.
gmelikov Автор
Я уточню — оно (якобы) не интересуется ВООБЩЕ всеми сторонними модулями, не зависимо от их лицензий.
Скажите это Ораклу :) Всё, что не связано со старым кодом времён Sun — уже GPL-совместимо. Да и в апстрим вливаться — не самоцель. Просто зачем специально портить жизнь другой части opensource коммьюнити такими шагами?
amarao
Ну, к модулям, которые планируют попасть в апстрим, отношение более мягкое. Тот же wireguard вполне себе zink уже считай, влил, хотя сам ещё не в апстриме.