ZFSonLinux 0.8: фичи, стабилизация, интриги. Ну и trim

    Буквально на днях релизнули свежую stable версию ZFSonLinux, проекта, который теперь является центральным в мире разработки OpenZFS. Прощай, OpenSolaris, здравствуй свирепый GPL-CDDL несовместимый мир Linux.

    image

    Под катом обзор самых интересных вещей (ещё бы, 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
    Поделиться публикацией

    Комментарии 19

      –1

      Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.


      Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.

        +3
        Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.

        Я уточню — оно (якобы) не интересуется ВООБЩЕ всеми сторонними модулями, не зависимо от их лицензий.
        Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.

        Скажите это Ораклу :) Всё, что не связано со старым кодом времён Sun — уже GPL-совместимо. Да и в апстрим вливаться — не самоцель. Просто зачем специально портить жизнь другой части opensource коммьюнити такими шагами?
          0

          Ну, к модулям, которые планируют попасть в апстрим, отношение более мягкое. Тот же wireguard вполне себе zink уже считай, влил, хотя сам ещё не в апстриме.

        0
        Ничего не понял, но было интересно
          +1
          Конечно же, самая ожидаемая — нативное шифрование.
          Уже существующий пул зашифровать можно?
          +2
          мейнтейнеры ядра проявляют явную незаинтересованность в помощи сторонним модулям

          Это ещё мягко сказано. Вот такое вот — это просто мелкое вредительство.


          > -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 символов "лишних" — огромные затраты :)

            0

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


            Самое больное — это если нужно расширить хранилище (с 2 до 3, с 3 до 4 дисков и т.п.), то это выходит дорого и неудобно, потому что в отличие от mdadm в RAIDZ нельзя добавить новое устройство — надо куда-то слить данные, которые лежат и заново создавать пул. Ещё есть тревожные звоночки от людей, которые заменяли диски в пуле, у которых число секторов было меньше, чем в исходных.


            Судя по тестам (правда, чужие бенчмарки — это бабка надвое сказала), COW довольно сильно просаживает скорость чтения/записи.


            На самом деле (тут конечно наверняка палками побьют любители ZFS), почти всё можно реализовать средствами линуксовых dm/md — это lvm, mdadm, luks, vdo и т.п… Это конечно приведёт к работе на много часов, т.к. утилиты ZFS намного лаконичнее и из-за того, что заточены только для ZFS — проще (LVM при этом может жонглировать чем угодно, что похоже на блочное устройство), но после первого раза будет не так жутко.
            Плюс, безусловно, у ZFS есть довольно неплохие киллерфичи вроде zfs send, снепшоты полегче чем в LVM, сжатие вообще нормально работает.


            Но NAS и другие такие коробочки один раз настроил и забыл, и если что-то сломается, по традиционным для Linux инструментам найти что-то в сети скорее всего будет намного проще.

              +1
              Я сначала тоже так думал после анализа материалов, в которых описываются плюсы ZFS, но когда стал разбираться подробнее, оказалось что всё не так радужно, как кажется.

              Да, серебряной пули нет :)

              Самое больное — это если нужно расширить хранилище (с 2 до 3, с 3 до 4 дисков и т.п.), то это выходит дорого и неудобно, потому что в отличие от mdadm в RAIDZ нельзя добавить новое устройство — надо куда-то слить данные, которые лежат и заново создавать пул.

              Расширение пула — самая что ни на есть штатная операция, наращивается новыми vdev устройствами (mirror, stripe, raidz). Для stripe всё даже круче — можно на лету добавить диск и сделать mirror. Да, сейчас в raidz нельзя просто так добавить диск, но работы в этом направлении ведутся тыц и тыц.

              Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.

              Ещё есть тревожные звоночки от людей, которые заменяли диски в пуле, у которых число секторов было меньше, чем в исходных.

              Ну тут вообще нет претензий к ZFS. Как и в мифе про требование ECC памяти — оно может стрельнуть в ЛЮБОЙ ФС и менеджере дисков. А ZFS, как раз таки, по умолчанию создаёт 8МБ доп. пустой раздел, чтобы иметь манёвр на такой случай.

              Судя по тестам (правда, чужие бенчмарки — это бабка надвое сказала), COW довольно сильно просаживает скорость чтения/записи.

              На самом деле с производительностью всё нормально, если понимать особенности работы ZFS. Она в первую очередь обеспечивает безопасность данных, и вот тут да, мы будем получать накладные расходы в виде случайной записи-доступа и минимум 2 копий метаданных. При должной настройке во многих кейсах ZFS делает других. Во многих он также по умолчанию хуже :)

              Также стоит понимать, что все плюшки ZFS используют ресурсы CPU по умолчанию больше, и при использовании всяких NVME полную скорость дисков выжать очень сложно (банально потому, что можно раньше упереться в CPU). Но это и не был первоначальный кейс ZFS, он затачивался под HDD, где задержки позволяют успеть сделать многое в CPU. Если кому интересно — тут как раз обсуждают и думают, как можно оптимизировать pipeline ZFS для NVME.

              На самом деле (тут конечно наверняка палками побьют любители ZFS), почти всё можно реализовать средствами линуксовых dm/md — это lvm, mdadm, luks, vdo и т.п…

              Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS, ну и аналога ARC кеша в принципе нет. А собрать аналог нельзя, потому что все эти layerы, кроме ext4/xfs/whateverFS не будут знать о данных. А вот здесь ZFS за счёт знания о данных и ARC/ZIL pipeline отлично оптимизирует производительность и даёт не плохие цифры.

              Повторюсь — у разных инструментов разные цели. Брать ZFS и требовать от него только производительности, не изучив а на что он эту производительность тратит — ну, такое.

              Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS :)))) Я готов отдать немного процентов производительности за целостность, атомарность, удобство использования, снапшоты, сжатие на лету, mirror/raidz и многое другое.
                0

                Спасибо за развернутый комментарий.


                Можно собрать только отдалённо похожее

                Безусловно, речи и не шло о том, что можно сделать ZFS, но круче, дешевле и проще. Самая главная проблема, как вы упомянули, это надёжность данных. Не могу сказать, как сейчас обстоит дело, но раньше возникали ситуации, при которых раздел в LVM мог умереть, если в RAM были незаписанные данные и отключилось питание.
                Это конечно в какой-то мере нивелируется установкой ИБП, но звучит довольно дико.


                Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.

                Это довольно дорого, при этом нужно обновить все диски, при этом старые, которые работали 24/7, уже особо некуда деть. В случае с несколькими зеркалами из пар одинаковых дисков это относительно адекватно (если есть лишние интерфейсы для подключения), но если используется RAIDZ1/2/3, там придётся менять всё сразу. А для этого нужно x2 дополнительных портов для подключения помимо самих дисков.


                Если нет необходимости никак расширять пространство — тогда да, ZFS отличная ФС (это не сарказм, для домашнего использования вполне нормальный юзкейс), но в некоторых нюансах слишком дорогая выходит. Правда, надеюсь всё же, что к тому моменту, как лично мне понадобится дополнительное место — в ZFS всё же поддержат расширение RAIDZ (:


                Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS

                Если люди полагаются только на целостность ФС и хранят важные данные в одном экземпляре — их не спасёт ни ZFS, ни магнитная лента, ни запекание лазером в алмазе. В данном случае, если нет другого дубликата данных — это ружьё, которое выстрелит, но когда-то потом. Серебряной пули действительно нет, но приятно что разработчики ZFS хотя бы двигаются в этом направлении.

                  0
                  Если люди полагаются только на целостность ФС и хранят важные данные в одном экземпляре — их не спасёт ни ZFS, ни магнитная лента, ни запекание лазером в алмазе. В данном случае, если нет другого дубликата данных — это ружьё, которое выстрелит, но когда-то потом. Серебряной пули действительно нет, но приятно что разработчики ZFS хотя бы двигаются в этом направлении.


                  Единственно добавлю, что по умолчанию из всех ФС только ZFS сейчас проверяет целостность данных. Никто не говорил, что после этого бекапы не нужны. Но только в этом случае вы хотя бы явно узнаете, что ваши данные в бекапе всё ещё не превратились в кашу.
                +1
                Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS

                Вести с полей: в целом, вы оказались правы. ZFS raidz1 с ashift=12 выдаёт на 40% (!) большую скорость записи на обычных SATA HDD, чем аналогичный RAID5 (mdadm с lvm разделами поверх) на абсолютно идентичной системе.


                Стоит понимать, конечно, что это порядки ~40-50МБ/с и 40% — не прямо-таки гигантские числа, но разница в копировании терабайтов информации исчисляется часами в таком случае.

              0
              Вкусно )
              Вот бы еще ZFS поверх VDO запустить…
                0
                А смысл, он дублирует местами только лишь функционал? Уж лучше в ZFS добавить чего не хватает.
                0
                Смысл в накладных расходах на deduplication (RAM). У VDO они ЗНАЧИТЕЛЬНО ниже.

                Смысл в том, чтобы сжатие и дедупликацию переложить на VDO, а ZFS оставить только вычисление CRC.
                  0
                  Ну у ZFS дедупликация просто онлайн, со всем вытекающим. А так да, вам никто не мешает ZFS пустить поверх VDO, если очень хочется. Только часто достаточно пользоваться сжатием, а дедупликация нужна не всегда.
                  0
                  Или за VDO -dedup, а компрессию и CRC оставить ZFS.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое