19 июня в 11:13

ZFS on Linux: вести с полей 2017 tutorial

ZFS является одной из самых нафаршированных файловых систем (ФС), а главное — она заботится о сохранности нашей информации. Да, она не является «серебряной пулей», но в своей области показывает прекрасные результаты.
ZFS

Проект ZFS on Linux изначально был создан для портирования существующего кода из Solaris. После закрытия его исходного кода совместно с сообществом OpenZFS проект продолжил разработку ZFS для Linux. Код может быть собран как в составе ядра, так и в виде модуля.
image
Сейчас пользователь может создать пул с последней совместимой с Solaris версией 28, а также с приоритетной для OpenZFS версией 5000, после которого началось применение feature flags (функциональные флаги). Они позволяют создавать пулы, которые будут поддерживаться в FreeBSD, пост-Sun Solaris ОС, Linux и OSX вне зависимости от различий реализаций.

В 2016 году был преодолён последний рубеж, сдерживавший ZFS на Linux — многие дистрибутивы включили его в штатные репозитории, а проект Proxmox уже включает его в базовую поставку. Ура, товарищи!

Рассмотрим как наиболее важные отличия, так и подводные камни, которые есть в настоящее время в версии ZFS on Linux 0.6.5.10.

Начинать знакомство с ZFS стоит с изучения особенностей CopyOnWrite (CoW) файловых систем — при изменении блока данных старый блок не изменяется, а создается новый. Переводя на русский — происходит копирование при записи. Данный подход накладывает отпечаток на производительности, зато даёт возможность хранить всю историю изменения данных.

image

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

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

Кратко о главных преимуществах ZFS для вашей системы.


Защита данных:

  1. контрольные суммы — гарантия корректности данных;
  2. возможность резервирования как на уровне создания зеркал и аналогов RAID массивов, так и на уровне отдельного диска (параметр copies);
  3. в отличие от многих файловых систем с их fsck на уровне журнала, ZFS проверяет все данные по контрольным суммам и умеет проводить их автоматическое восстановление по команде scrub (если в пуле есть живая копия битых данных);
  4. первая ФС, разработчики которой честно признались во всех возможных рисках при хранении — везде при упоминании ZFS можно встретить требование оперативной памяти с поддержкой ECC (любая ФС имеет риск повреждения при отсутствии ECC памяти, просто все, кроме ZFS, предпочитают не задумываться об этом);
  5. ZFS создавалась с учетом ненадёжности дисков, просто помните это и перестаньте волноваться о вашем WD Green Seagate etc (только, если рядом трудится ещё один выживший диск).

Максимальная гибкость вашего хранилища:

  1. закончилось место? Замените диск на более объёмный, и ваш покорный ZFS сам займёт новоотведённое ему место (по параметру autoexpand);
  2. лучшая реализация снапшотов среди файловых систем для Linux. На это подсаживаешься. Инкрементально по сети, в архив, /dev/null, да хоть раздвойте личность вашего дорогого Linux в реальном времени (clone);
  3. нужно больше золота места? 256 зебибайт хватит всем!

Структура.


В ZFS структура хранилища выглядит следующим образом:

- pool
-- vdev (virtual device) - объединяет носители (в mirror, stripe и др.)
--- block device - диск, массив, файл

В пуле может быть неограниченное количество vdev, что позволяет создать пул из двух и более mirror, RAID-Z или других сочетаний. Также доступны классические RAID10 и т.д.

Типы массивов:


Stripe — обычный RAID0.

Mirror — RAID1 на манер ZFS — реплицируются только занятые блоки, забудьте о синхронизации пустого места.

RAID-Z — создавался как замена RAID5-6, но имеет большие отличия:

— каждый блок данных — аналог отдельного массива (с динамической длинной);
— отсутствует проблема write hole;
— при ребилде создаются только данные (т.е. риск сбоя в этот момент уменьшается). Также в тестовой ветке уже находятся улучшения, которые дополнительно ускорят этот процесс.

Рекомендуется использовать RAID-Z2 (аналог RAID6). При создании RAID-Z стоит обязательно изучить эту статью, основные нюансы:

— IOPS равен самому медленному диску (создавайте RAID-Z с наименьшим количеством дисков);
— эффективность утилизации места увеличивается при бОльшем количестве дисков в массиве (требуется задать корректный recordsize, см. ссылку выше);
— в существующий массив RAID-Z нельзя добавить ещё один диск (пока), но можно заменить диски на более ёмкие. Эта проблема решается созданием нескольких массивов в рамках одного vdev.

dRAID (в разработке) — базируется на наработках RAID-Z, но при сбое позволяет задействовать на чтение-запись все диски массива.

ARC — умное кеширование в ZFS.


CoW ухудшает производительность. Для сглаживания ситуации был создан adaptive replacement cache (ARC). Его основная особенность в проработанных эвристиках для исключения вымывания кеша, в то время как обычный page cache в Linux к этому очень чувствителен.

Бонусом к ARC существует возможность создать быстрый носитель со следующим уровнем кеша — L2ARC. При необходимости он подключается на быстрые SSD и позволяет заметно улучшить IOPS HDD дисков. L2ARC является аналогом bcache со своими особенностями.

L2ARC стоит использовать только после увеличения ОЗУ на максимально возможный объём.

Также существует возможность вынести запись журнала — ZIL, что позволит значительно ускорить операции записи.

Дополнительные возможности.


Компрессия — с появлением LZ4 позволяет увеличить скорость IO за счёт небольшой нагрузки на процессор. Нагрузка настолько мала, что включение данной опции уже является повсеместной рекомендацией. Также есть возможность воспользоваться другими алгоритмами (для бекапов прекрасно подходит gzip).

Дедупликация — особенности: процесс дедупликации производится синхронно при записи, не требует дополнительной нагрузки, основное требование — ~ 320 байт ОЗУ на каждый блок данных (Используйте команду zdb -S название_пула для симуляции на существующем пуле) или ~ 5гб на каждый 1 тб. В ОЗУ хранится т.н. Dedup table (DDT), при недостатке ОЗУ каждая операция записи будет упираться в IO носителя (DDT будет читаться каждый раз с него).
Рекомендуется использовать только на часто повторяющихся данных. В большинстве случаев накладные расходы не оправданы, лучше включить LZ4 компрессию.

Снапшоты — в силу архитектуры ZFS абсолютно не влияют на производительность, в рамках данной статьи на них останавливаться не будем. Отмечу только прекрасную утилиту zfs-auto-snapshot, которая создаёт их автоматически в заданные интервалы времени. На производительности не отражается.

Шифрование (в разработке) — будет встроенным, разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/receive и scrub отправлять и проверять данные на целостность без ключа.

Основные рекомендации (TL;DR):


— Заранее продумайте геометрию массива, в настоящий момент ZFS не умеет уменьшаться, а также расширять существующие массивы (можно добавлять новые или менять диски на более объёмные);
— используйте сжатие:

compression=lz4

— храните расширенные атрибуты правильно, по умолчанию хранятся в виде скрытых файлов (только для Linux):

xattr=sa

— отключайте atime:

atime=off

— выставляйте нужный размер блока (recordsize), файлы меньше recordsize будут записываться в уменьшенный блок, файлы больше recordsize будут записывать конец файла в блок с размером recordsize (при recordsize=1M файл размером 1.5мб будет записан как 2 блока по 1мб, в то время как файл 0.5мб будет записан в блок размером 0.5мб). Больше — лучше для компрессии:

recordsize=128K

— ограничьте максимальный размер ARC (для исключения проблем с количеством ОЗУ):

echo "options zfs zfs_arc_max=половина_ОЗУ_в_байтах" >> /etc/modprobe.d/zfs.conf
echo половина_ОЗУ_в_байтах >> /sys/module/zfs/parameters/zfs_arc_max


— дедупликацию используйте только по явной необходимости;
— по возможности используйте ECC память;
— настройте zfs-auto-snapshot.

Важные моменты:


— многие свойства действуют только на новые данные, к примеру при включении сжатия оно не применится к уже существующим данным. В дальнейшем возможно создание программы, применяющей свойства автоматически. Обходится простым копированием.
— консольные команды ZFS не запрашивают подтверждение, при выполнении destroy будьте бдительны!
— ZFS не любит заполнение пула на 100%, как и все другие CoW ФС, после 80% возможно замедление работы без должной настройки.
— требуется правильно выставлять размер блока, иначе производительность приложений может быть неоптимальна (примеры — Mysql, PostrgeSQL, torrents).
делайте бекапы на любой ФС!

В настоящий момент ZFS on Linux уже является стабильным продуктом, но плотная интеграция в существующие дистрибутивы будет проходить ещё некоторое время.

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

Я, gmelikov, состою в проекте ZFS on Linux и готов с радостью ответить на любые вопросы!
Отдельно хочу пригласить к участию, всегда рады issues и PR, а также готовы помочь вам в наших mailing lists.

Полезные ссылки:

ZFS on Linux github page
FAQ
ZFS Performance tuning
Георгий Меликов @gmelikov
карма
19,2
рейтинг 40,8
Webdev
Самое читаемое Администрирование

Комментарии (96)

  • 0
    Дополнительно стоит добавить, что на подходе версия 0.7, в которую включено огромное количество изменений, проведена работа по синхронизации кодовой базы с OpenZFS, а также внесены значительные изменения во взаимодействие с памятью.
    • 0
      Подскажите пожалуйста, OpenZFS может выступить iscsi initiator? сможет ли с таким томом работать windows? возможна ли загрузка с такого тома. Для меня вообще стало новостью что iscsi может расшарить не блочное устройство.
      • 0

        iSCSI может, но не своими средствами. Сначала нужно сделать zvol — вид датасета, предоставляющий интерфейс блочного устройства.
        Делается легко, например:


        zfs create -V 30G PoolName/volume_name

        Где 30G — объем.
        Затем такое блочное устройство нужно "расшарить" с помощью isci-tartet.


        Снэпшоты и прочие радости ZFS доступны и для zvol.

  • 0
    Интересно было бы прямое глобальное сравнение скоростей (чтения/записи) для текущих файловых систем и новых… а так же о недостатках каждой.
    • 0
      Согласен, такое сравнение всегда интересно, но очень важно подходить к нему с учётом всех особенностей каждой ФС, на примере ZFS требуется внимательно изучить особенности Copy-on-Write.
      • +1
        Ага, например, ужасную деградацию скорости записи после заполнения >80%. Особо доставляет, когда массив под 100ТБ. Хоп! А 20Тб, извините, будем писать со скоростью черепахи.
        Снапшоты — отлично, да, быстро. Только надо помнить, что если данные меняются быстро, то скорость заполнения раздела при наличии снапшотов шустро увеличивается.
        COW очень не бесплатный, увы.
        • 0
          Согласен, COW никогда не будет бесплатной по сравнению с классическими ФС, у них разные области.

          В вашем примере могла сказаться фрагментация, ZFS по объективным причинам любит большое наличие свободного места.
          • 0
            Нет, фрагментации там практически нет, т.к хранилище использовалось практически только в режиме добавления новых файлов. Возможно, поэтому дикие тормоза случились не совсем на 80%, а чуть позже. Сейчас точно не помню, с тех пор было собрано несколько новых массивов с XFS.

            ZFS по объективным причинам любит большое наличие свободного места.

            Так добавьте это в статью. Узнать об этом, заполнив 100Тб — крайне неприятно, правда?
            • 0
              Спасибо, добавил.

              К сожалению, серебряной пули в этом вопросе не существует, и ZFS требует подготовки перед использованием в продакшене (как, собственно, и любая другая ФС).
        • +2
          Ага, например, ужасную деградацию скорости записи после заполнения >80%. Особо доставляет, когда массив под 100ТБ.


          Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.
          Так же можно отключить/включить prefetch, nocacheflush (смотря что там происходит). Если данные не сильно важны, можно выключить sync, увеличить время сброса кеша да диск (по дефолту раз в 5 секунд).
          В целом, да, zfs немного медленнее, но это не значит, что её нельзя подтюнить для более быстрой работы.

          Насчёт снепшотов (из практики cиспользования zfs). Если diff между снепшототами (или снепшотом и текущим состоянием) достаточно большой (гигабайты, десятки/сотни гигабайт), то разницу начинаешь замечать: нагрузка на диски при таком же количестве iosp'ов значительно выше (логично почему). Так что, снепшоты не полностью бесплатны и это нужно учитывать.
          • +1
            Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.

            Возможно, но возникают вопросы:
            1) Инженеры Sun не понимали, что делали, что выбрали это значение на несколько порядков больше, чем «надо»?
            2) Допустим, они ошиблись. Вы более-менее внятно понимаете — на что повлияет изменение этого параметра, где аукнется?
            3) «будет быстрее» — насколько быстрее? Кто-то проводил тесты?

            Это я всё к тому, что с ZFS обычно речь идет не о домашней файлопомойке, а о корпоративном хранилище, большом и ценном.
            Я понимаю, что любая система требует настройки под конкретные задачи, но наобум крутить крутилки стораджа — это опасный путь. Он имеет право на жизнь, «безумству храбрых...» как говорится, но, согласитесь, не стоит рекомендовать его как серебряную пулю.

            • +1
              1) Точно так же как и остальные инженеры и разработчики ОС не всегда ставят некоторые параметры оптимальные и SUN здесь не исключение. Можно так же придраться к тому, почему бы по умолчанию не включать LZ4, раз оно сжимает «сжимаемые» данные и не трогает «несжимаемые».
              2) Данный параметр может «аукнуться», только если у вас опять станет много свободного места (50% и более) и тогда возможно снижение скорости записи по сравнению с дефектными значениями.
              3) тесты я не проводил, так как они будут очень хосто-зависимы, но из практики скажу следующее: есть у меня несколько одинаковых по железу серверов и так же однотипными данными. Так вот, падение скорости на запись наблюдается только у одного из них, и то, при достижении планки в 95%.

              А насчёт серебряной пули — она действительно, если таковой не является, то явно стремиться к ней и ближе, чем любая мне известная ФС (суммарное количество преимуществ действительно намного больше, чем у других). Другое дело, что работает она как пуля только в Solaris (ни во FreeBSD, ни в Linux она не является достаточно стабильной).

              Я думал точно так же как и вы и ко всему скептически относился, пока не поработал с ней плотно несколько лет. И вот тогда понимаешь, что её можно приспособить, практически под любые условия:
              — нужна стабильность? пожалуйста, есть
              — нужна супер скорость? да, тоже есть (подтюнил и вперёд)
              — нужно что-то среднее, да тоже не вопрос.

              Как уже перечисляли в статье, основные её преимущества это:
              — неубиваемость. Действительно, её практически невозможно разрушить в виду особенностей строения (при каждой транзакции на диск пишутся 2 метки в начале, 2 в конце, при этом пишутся по диагонали)
              — простота снепшотов (никакой lvm или btrfs не будет удобным настолько, насколько это делается в zfs)
              — autoexpand — это действительно вещь и в zfs это очень просто и безболезненно.
              — множество фич, которые можно тюнить.

              Так же забыл добавить, что можно налету изменять размер блоков, которыми ФС пишет на диск. К примеру, если у вас на zfs postgresql (а по дефолту она пишет 8кб блоками), то нужно выставить в этой zfs тоже 8кб, тогда скорость записи значительно будет эффективнее, чем дефолтными 128кб. А если этого не знать, то можно сказать, ооо, как медленно пишет (фу, какая плохая ФС), у меня на линуксе писало быстрее.

              Точно так, если вы не являетесь DBA, то вы не сможете выжать из БД максимум, и будете говорить, почему медленно работает.
              • 0
                — простота снепшотов (никакой lvm или btrfs не будет удобным настолько, насколько это делается в zfs)

                Можете описать разницу с вашей точки зрения, пожалуйста?
                • 0
                  С lvm всё просто — они там не «бесплатные», накладывают большой отпечаток по производительности, сама ФС о снапшотах ничего не знает.
                  С btrfs — можете почитать официальную страницу btrfs gotchas, плюс в нём нет поддержки блочных устройств (в ZFS это ZVOL).
                  • 0
                    Извините, я по недомыслию не сократил упоминание об LVM, когда цитировал вас.Специфику создания снапшотов в LVM я представляю. Меня интересует, скорее, не разница фич (может/не может создаватьснапшот подлежащего блочного устройства), а скорее то, что вы назвали отличием снапшотов. Если сравнить снапшот субтома в btrfs и аналогичный снапшот дерева/части дерева ФС в zfs — вот, я дал команду и получил снапшот подтома — есть ли какие-то коренные отличия? То есть в данной конкретной ситуации есть, по вашему мнению, какая-либо большая удобность zfs в сравнении с btrfs?
                    • 0
                      Сама специфика создания снепшота — общая и одинаковая. Реализация у всех разная. К примеру, можно провести такой тест: сделать снепшот ФС, потом создать и удалить большой файл, и так проделать несколько раз. На сколько будет отличаться снепшот в разных ФС? Вот это и будет коренным отличием (если конечно отличия будут).

                      А что насчёт удобства, то для это наличии многих фич + простота использования.
                • 0
                  Как минимум то, что в zfs это делается одной командой, а не как в lvm — lvcreate / lvremove. В btrfs видимо это учли, и поэтому там делается одной командой, но с добавлением subvolume.

                  btrfs subvolume [params]

                  в отличии от zfs:

                  zfs [params]

                  Мне удобнее писать меньше текста, выполняя команды. Если кому-то нравится набирать команды из 20-30 символов + иерархические ключи — можете портировать powershell.
  • 0

    А что там с лицензией? Получилось втащить zfs в ядро Linux? А то я давно не слежу за темой.

    • 0
      Технически всё уже реализовано, а вопрос лицензии без проблем обходится сборкой модуля DKMS. За несколько лет ни разу проблем с ним не было.

      К сожалению, интеграция в кодовую базу ядра в ближайшее время точно не произойдёт.
  • 0
    2.возможность резервирования как на уровне создания зеркал и аналогов RAID массивов

    А аналог RAID-6 в ней есть (т.е. сохранность целостности при выходе из строя 2 физических дисков)?
    • 0
      Конечно, RAID-Z1, 2 и 3 допускают отказ 1, 2 и 3 дисков соответственно.
  • 0
    в существующий массив RAID-Z нельзя добавить ещё один диск (пока)

    уже запланировано? для домашнего использования очень не хватает
    • +1
      К сожалению, пока планов на эту задачу нет.

      Но вопрос удобства всё же поднимается — в OpenZFS уже появилась возможность исключать диски.
  • 0
    >лучше включить LZ4 шифрование.
    ухты… новый алгоритм шифрования… ;)))
    компрессия это а не шифрование
    • 0
      Упс, спасибо! Видимо наболевшее ожидание встроенного шифрования сказалось.
    • –3

      А про шифрование можно найти здесь!!

  • 0

    А рассматривается ли возможность ручного прогона дедубликации в отведённый даунтайм без необходимости включать его напостоянно? Есть один юзкейс (CI/DI сервера) когда происходит сильное дублирование данных и можно было бы по выходным прогонять дедубликатор (когда всё стоит и можно испоьзовать хоть всю память для этого). Но постоянно гонять никак т.к. память для работы нужна.

    • 0
      У нас был плохой опыт использования дедупликации на ZFS в SDS NexentaStor — хранилище было заполнено от силы на 50%, но в какой-то момент времени производительность катастрофически упала, до десятков кБайт/сек.
      Миграция в течение нескольких часов одной виртуалки, потом еще нескольких, ребут жесткий хранилища со включенными виртуалками под ESXi — ожила хранилка, отключение дедупликации, миграция части виртуалок на другой СХД, потом обратно — старые остались дедуплицированными, а новые уже нет.
      Общее решение — пересоздание массива с нуля только.
      • +1
        Возможно в оперативку не влезли служебные данные нужные для дедупликации. Тогда системе пришлось сбросить это на диск, а к этой таблице нужно обращаться при каждой операции чтения и записи. Там расход примерно 8гб ОЗУ на 1 тб данных
        • 0
          Причины как бы понятны, но крайне неприятны.
        • 0
          Всё верно, правда DDT требуется только для записи, что в случае Daimos и произошло.
      • +1

        Ну вот в том-то и вопрос, что активация на постоянной основе спотыкается об требование памяти. Но одноразовые прогоны дедубликации по уже записанным данным может решить большинство ситуаций. Но этого как раз и не предусмотрено. Увы...

    • 0
      Кейс понимаю, но сейчас таких планов нет.

      Сейчас требуется около 5гб ОЗУ на 1 тб данных, они требуются только в момент записи.
  • +1
    Тема весьма интересна.
    Хотелось бы сравнить скорость работы текущей реализации ZFS в Linux (Debian 9.0) и Solaris (OpenIndiana Hipster).
  • 0
    Подскажите возможно ли после уничтожения датасета заставить ZFS вернуться к старому состоянию базы данных, где этот датасет будет еще живой чтобы спасти данные? Вроде бы есть «мифический» способ сделать это использую флаг -T и указав id транзакции до дестроя при импорте, но как бы я не старался, у меня не вышло.
    Команда выглядит примерно так:
    zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id>
    • +1
      A deferred free means that a block has been freed but cannot be used by the pool until TXG_DEFER_SIZE transactions groups later. For example, a block that is freed in txg 50 will not be available for reallocation until txg 52 (50 + TXG_DEFER_SIZE). This provides a safety net for uberblock rollback. A pool could be safely rolled back TXG_DEFERS_SIZE transactions groups and ensure that no block has been reallocated.


      TXG_DEFER_SIZE = 2. Поэтому со 100% вероятностью можно восстановить только то, что было 2 транзакции назад. А если пул заполнен, то шансов ещё меньше.
      • 0
        Это понятно. К примеру мы случайно сделали destroy, затем сразу zpool export и пытаемся подключить пул со старой TXG. Проблема именно подключить… Драйвер ZFS не дает использовать старую TXG запись насколько я понял. Если есть специалисты, которые смогли найти решение данной проблемы, заклинаю, напишите как это сделать!
        • +1
          Технически, существует возможность откатиться на более ранние транзакции, которые могут быть уже повреждены — вам поможет вот этот патч. К сожалению, это не гарантированный вариант. Удачи вам!

          Рекомендую все действия производить над копией массива.
  • 0

    Какие сейчас минимальные адекватные требования к оперативной памяти? Мне снапшоты zfs нравятся больше чем btrfs, но память на домашней машинке ограничена (8гб, 5 постоянно занято kvm-ками). Стоит пробовать?

    • +1

      У меня в таких условиях полёт нормальный. Только надо учитывать, что ARC кеш выглядит так, как будто какое-то приложение сожрало всю память. Хотя реально эта память свободно перераспределяется под нужды приложений по требованию. Короче в моём случае работает, хоть и выглядит странно.


      Использую для тестирования приложений на больших БД, которые надо долго готовить для каждого прогона. А так пересоздал снапшот и готово. Очень доволен.

    • 0
      Согласен с vektory79, жить можно, однако учитывайте, что ОЗУ нужно для кеширования, вы можете сказать ZFS кешировать хоть не более мегабайта (параметр zfs_arc_max), но при этом производительность на чтение будет ожидаемо ниже.
      • 0

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


        Или я где-то не прав?

        • 0
          Всё верно, я хотел просто указать на конкретный параметр.
  • 0
    Не увидел в статье, а Linux умеет загружаться с ZFS, как та же самая FreeBSD?
    • 0
      Да, прекрасно загружается, на 2 машинах у меня нет никаких проблем. Из минусов — установка не двумя кликами.
    • 0
      Да умеет. GRUB2 поддерживает /boot без отдельного раздела, прямо на ФС.

      # zpool get bootfs
      NAME PROPERTY VALUE SOURCE
      zboot bootfs zboot/ROOT local

      # zfs list
      NAME USED AVAIL REFER MOUNTPOINT
      zboot 621G 2,03T 136K legacy
      zboot/ROOT 621G 2,03T 8,98G legacy

      # mount | grep boot
      zboot/ROOT on / type zfs (rw,relatime,xattr,posixacl)

      Кто-то спрашивал про прозводительность (всё от IOPS дисков зависит, конфигурации RAID и кол-ва шпинделей). Вот на домашней системе

      Сначала смешное:

      # dd if=/dev/zero of=./zerodump.useless bs=128k count=102400
      102400+0 records in
      102400+0 records out
      13421772800 bytes (13 GB, 12 GiB) copied, 1.9465 s, 6.9 GB/s

      Т.е. это на самом деле данных было записано в X раз меньше — сжатие на лету.

      # zfs get all zboot/ROOT | grep compress
      zboot/ROOT compressratio 1.27x — zboot/ROOT compression lz4 inherited from zboot
      zboot/ROOT refcompressratio 1.55x — -------

      # time cp -r American\ Gods Dark\ Matter SG-1 tmp/

      real 0m34.449s
      user 0m0.016s
      sys 0m1.524s

      # du -hs tmp
      5,3G tmp

      5,3G/34.449s = .1538GB/s на копирование файлов с компрессией на одной и той-же FS.

      T.e. это и чтение и запись одновременно. Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.

      Скорость чтения и валидации данных на диске (zpool scrub zboot/ROOT):

      ссылка на скрин nmon: http://imgur.com/oNXmm3H

      image

      Диски SATA III Seagate Barracuda 1TB в конфигурации RAID-10

      config:

      NAME STATE READ WRITE CKSUM
      zboot ONLINE 0 0 0
      mirror-0 ONLINE 0 0 0
      sda2 ONLINE 0 0 0
      sdb2 ONLINE 0 0 0
      mirror-1 ONLINE 0 0 0
      sdc1 ONLINE 0 0 0
      sdd1 ONLINE 0 0 0
      mirror-2 ONLINE 0 0 0
      sde1 ONLINE 0 0 0
      sdf1 ONLINE 0 0 0

      Как-то так.
      • 0
        Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.

        В случае несжимаемых данный ZFS не проводит сжатие, можете об этом не волноваться.
  • 0
    сильно не хватает аналога reorgvg
  • –1
    давно интересовал вопрос: возможна ли установка linux на raw zfs?
    на freebsd работает добавлением загрузчика:
    dd if=/boot/zfsboot of=/dev/ada0 count=1 && dd if=/boot/zfsboot of=/dev/ada0  skip=1 seek=1024
    
    • 0
      Да, прекрасно работает, выше уже ответили.
      • 0
        Boot vdev может быть RAID-Z'ом?
        • 0
          Да, никаких проблем.
  • +4

    Использую zfs как NAS хранилку, впринципе очень доволен. LZ4 сжатие вообще огонь, на датасторах виртуалки жмутся в среднем в 2.4 раза. Прогретый ARC от 94 — 98% чтения отдает с RAM, остальное забирает L2ARC и совсем немного приходится на hdd. Не используем дедубликацию, т.к. она имеет смысл быть при блоках 4к, а для этого требуется очень много памяти.


    Пробывал варианты с


    • centos7 + openzfs
    • illumous — дистрибутив omnios
    • solaris 11.2/11.3

    В итоге остановился на конаничном — Solaris.


    типовая конфигурация у нас это:


    • Cisco UCS 240m4 ( cpu: 2 x E5-2699A v4, ram: 768gb, 2 x dual intel x520 10gbe, 2 x lsi sas 9200-8e )
    • 216BE2C-R741JBOD / SC847E2C-R1K28JBOD
    • SLOG: PX04SHB020 — очень рекомендую
    • L2ARC: HUSMM1640ASS204

    Тестировал fio как локально, так и экспортируюмую шару по NFSv4, так и iSCSI волум.


    Linux

    Плюсы:


    • Нет проблем с железом / дровами
    • Легко найти человека который знаком с linux
    • Имеется поддержка nfsv 4.1

    на этом пожалуй плюсы закончены


    Минусы:


    • производительность zfs меньше на процентов 15 по сравнению с тем же OmniOS, на локальных тестах + тестах по iscsi (использовал targetd lio) и на процентов 20% по сравнению с тестами по nfs.
    • autoreplace для пула, т.к. каждый диск у нас видится по четырем путям, нам необходимо сконфигурировать multipathd таким образом, чтобы в названии он отоброжал физическое расположение диска — в идиале полка/слот. чтобы после замены диска он автоматически выполнял реплейс.
    • т.к. я тестировал на centos7 при проблемах с производительностью мы имеет только счетчики из proc и стандартные утилиты типа iostat (в systemtap я не селен), что как мне кажется делает анализ производительности более сложным чем в случае с solaris base дистрибутивами.
    • Кластер на базе Pacemaker + Corosync. Умные проверки придется пилить руками.

    OmniOS

    плюсы:


    • Хорошая производительность как при локальных теста, так и при использовании nfs
    • Имеется платный кластер — RSF-1 заточенный под кустарные схд
    • Dtrace который облегчает поиск проблемных мест + множество готовых скриптов под него.
    • Comstar уже интегрирован с zfs (ISCSI)
    • Нет проблем с мультипазингом, MPxIO работает на ура.
    • Отличное сообщество.
    • FMD (fault managment daemon) — этот парень всегда пришлет письмо,
      если у вас, что то сломалось (если конечно сервер и fmd еще живы). Расширяется за счет плагинов.

    Минусы:


    • Не на всем железе взлетит + проблема с драйверами, для современных 40гбе карточек.
    • до недавнего времени была проблема с UEFI
    • Админов знакомых с solaris в разы меньше.

    Solaris 11.3

    все плюсы из OmniOS, а так-же:


    • Производительность раза в полтара выше чем у OmniOS и тем более Linux,
      как я понимаю это связанно с фитчей efficiency block allocation
      котарая появилас в 36-ой версии, пула если не изменяет память.
    • L2ARC остается горячим при переключении кластер (активной ноды) или перезагрузки
    • в FMD
      появились плагины io retired && zfs retired, которые отслеживают
      события с I/O на диске и в случае например "дребезка" диска, помечают его
      как failed и убирает из системы до выяснения обстоятельств
    • Sun Cluster — это парень имеет багатую историю и тесно интегрирован с
      Solaris. Отлично работает, прост в использовании, вообщем нареканий нет.

    Минусы:


    • Сообщество на металинки достаточно "тухлое"
    • Не на всем железе взлетит + проблема с драйверами, хотя дела обстоят не так
      остро как с OmniOS, а если брать сервера от Oracle так проблем вообще нет.
    • Нет фитчи с асинхронным удалением датасетов, например датасеты размером в
      50тб удаляются сутки или двое, но зато это операция не просаживает CPU как в случае с OpenZFS.
    • Админов знакомых с solaris в разы меньше.
    • Comstar не кластирезуется из коробки, нужно допиливать.

    Десклеймер: По поводу производительности, настройки openzfs на linux и
    illumous я старался сделать как можно более одинаковыми. У Oracle ZFS естественно они отличались. Ну и естественно это мой личный опыт, ваше мнение/опыт могут отличаться.


    По поводу использования zfs в качестве бэка для систем виртуализации, аля Linux KVM + ZFS — посмотрите проект SmartOS, он достаточно интересный и активно развивается компанией Joyent.

    • –1
      Как давно тестировали? В будущем релизе ZoL 0.7 включено множество оптимизаций производительности, которые, кстати, сразу портируются в OpenZFS (то есть проблемы уже не в реализации на Linux, основную проблему взаимодействия с ОЗУ уже решили в 0.7).

      Эх, вот бы усилия Oracle да объединить с OpenZFS…
      • +1

        В начале 2016 года. Я вкратце описал почему выбор пал на Солярис, также я убежден в том, что на "родной" системе zfs работает стабильнее + fmd очень удобен в части проблем с дребезгом дисков, а также автоматического создания инцидентов о возникших проблемах. Обязательно затестирую релиз 0.7 на нотнике ))

        • 0
          Спасибо, была интересна актуальность.

          Если я правильно понял, в ZoL есть аналог fmd — ZED.

          на «родной» системе zfs работает стабильнее

          Не спорю, интерес именно в накладных расходах разных реализаций.
  • +1

    Рекомендую к просмотру, хоть материал и старенький, но концепция изложена полностью:
    ZFS: The Last Word in File Systems — Part 1
    ZFS: The Last Word in File Systems — Part 2

  • 0
    Для больших инсталляций хочу сравнение производительности с ceph'ом. Да, я знаю, что они не полностью пересекаются, но в условиях «локальное всё» их вполне можно пытаться сравнивать.
    • 0

      Я думаю сложно будет подобрать сопостовимые конфигурации, сравнивать по price/performance?

      • 0
        Почему? Берём то железо, какое есть. В тесте один — zfs, в тесте два — ceph. У ceph'а можно с лёгкостью сконфигрировать вариант без избыточности, то есть использовать его просто как «shared volume». И тогда уже можно тестировать производительность cephfs/rbd VS zfs.

        А если же мы говорим про варианты с избыточностью, то тут вообще всё просто — в crush map задаём «использовать osd одного хоста» и смотрим на результат.

        Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону. Хоть вверх, хоть вниз. Плюс возможность работать с ним как blob-хранилищем напрямую, что может быть иногда интереснее, чем fs/блочное устройство.

        Но фичи ладно. Интересно было бы raw-производительность сравнить.
        • 0
          Для больших инсталляций хочу сравнение производительности с ceph'ом

          Ну если на текущем железе, то это не большая инсталяция ))


          Без избыточности тестировать как мне кажется смысла тоже нет, т.к. тогда и
          zfs можно собрать как raid0.


          Если интересно, то в середине июля должнен получить очередное оборудование под NAS
          ( 2 сервера + 4-ре полки на 24-ре диска) можно попробывать на них.


          По Объему схожая конфигурация это:


          zfs pool (Solaris):
            40 x mirror - hdd 10krpm
            8 x slog    - ssd
            4 x l2arc   - ssd

          ceph (Linux 4.X)
            replicated pool == 2 copies
              node1:
                20 x osd  - hdd
                4 x ssd == 20 journal partitions
              node2:
                20 x osd  - hdd
                4 x sdd == 20 journal partitions

          Берем примерно 10% от общего полезного объема


          fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=write --blocksize=4k --group_reporting
          fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randwrite --blocksize=4k --group_reporting
          fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=read --blocksize=4k --group_reporting
          fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randread --blocksize=4k --group_reporting
          fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=readwrite --blocksize=4k --group_reporting

          так?


          Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону

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


          PS: за терминологию касательно цефа заранее извиняюсь + если тестировать будем, возможно будет полезно узнать какой то бест практис по тонкой настроки ceph.

          • 0
            Почти. Я бы использовал librados напрямую: --ioengine=rbd, плюс, если мы говорим про трушный бенчмарк, то --fsync=1. Я наблюдал как добавление fsync'а многие хранилки убивало к чертям в район сотен иопсов (с десятков тысяч).

            Плюс на ceph'е лучше всё-таки blustore использовать, они его объявили production-ready этой весной.
  • +4
    Большое спасибо за статью!

    Вставлю свои 5 копеек: Использую ZFS в связке с OwnCloud-сервером (как средство сихронизации пользовательских данных с Windows-машин на сервер через OwnCloud-клиент) + Samba + снапшоты.
    Для себя, как администратора, сделал доступ к папке с данными через скрытый ресурс.
    И через настройки Samba объяснил, как интерпретировать снапшоты ZFS:
    [USERDATA$]
    comment =
    path = /owncloud/
    public = yes
    writable = no
    guest ok = yes
    guest only = yes
    read only = yes
    hosts allow = 192.168.0.2
    create mask = 0777
    directory mask = 0777
    vfs objects = shadow_copy2
    shadow: format = auto-%Y-%m-%d_%H.%M
    shadow: sort = desc
    shadow: snapdir = .zfs/snapshot
    shadow: localtime = yes


    Что мне это дало — на любом каталоге я могу вызвать в Explorer контекстное меню и выбрать пункт: Предыдущие версии. Вижу все предыдущие версии (zfs-auto-snap то работает), могу тут же их открыть и найти нужный файл нужной версии.
    В добавок к этому в самом OwnCloud есть версионность и корзина.

    В общем вариант, неубиваемый вирусами шифровальщиками — как бы на машине они не поработали (клиенткой) — на сервере все равно исходный вариант останется. Либо в OwnCloud, либо в ZFS.
    • +1
      Пилите полноценную статью, будет очень интересно.
    • 0
      О да!!! очень интересно!!! Я тоже хочу поднять OwnCloud. Сделайте статью с нуля по использованию ZFS+OwnCloud+Samba+снапшоты.Буду ждать!!!
  • +1
    А ту замечательную «особенность», когда при заполнении диска на 100% становится невозможно удалять файлы, в новой версии пофиксили? ;) Это такой знатный троллинг.
    А вообще это единственная ФС, которая позволила мне стабильно зашарить раздел между Linux и OSX.
    • 0
      Вроде и тогда были методы почистить диск, сейчас уже не воспроизводится. Вообще CoW имеет свои особенности, это да =)
      • 0
        Обновил zfs до 0.6.5.9-5 на debian jessie

        tank/rc-544 50G 50G 0 100% /var/www/rc-544/data

        При 100% забитом разделе при попытке удалить файл получаю ошибку:
        rm: cannot remove ‘backupland.com.log’: Disk quota exceeded

        Проблема обходится
        cat /dev/null > backupland.com.log
        после чего появляется чутка места и после можно уже удалить файл

        Но мне кажется это какой-то мегакостыль, есть нормальное решение проблемы?
        • 0
          Давайте вспомним, что это CoW, да, ей даже при удалении надо сначала записать.

          Плюс добавлю, что не рекомендуется заполнять пул больше, чем на 80%, дальше начнутся проблемы с фрагментированием. Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
          • 0
            На основном пуле место свободно с большим запасом:
            NAME USED AVAIL REFER MOUNTPOINT
            tank 17.6T 7.81T 1.48T /home

            создаю я подпул так:
            /sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=51200M

            50 гиг это же не размер раздела, а квота по сути.

            Или нужно делать quota+20%, а ограничивать через refquota?
            • 0
              Нашёл тикет, касающийся данного вопроса. Проблема квалифицирована не как баг, соответственно у неё нулевой приоритет.

              К сожалению, ZFSonLinux развивается в основном за счёт энтузиастов с упором на продакшн, удобства для десктопов только начинают получать какое-то внимание. Всегда рады пулл реквестам!
          • 0
            Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.

            Иногда события развиваются очень стремительно. Например чекаут корневой дериктории svn, с разворотом 1500 тегов, сделаных CI.

    • 0
      хм а как такую ситуацию разрулили? кроме backup-format-restore?
      • 0
        Разруливалось через усечение файла.
        dd if=/dev/null of=bigfile.mkv
        rm bigfile.mkv
  • 0

    Домашний NAS стал на шаг ближе, немогу не нарадоваться!

  • 0
    gmelikov, насколько я понимаю, четверть из ARC отводится под метаданные для L2ARC. Я хотел бы использовать как можно больше l2arc, и как можно меньше отводить под ARC.

    Насколько оправдано на сервере виртуализации, использовать 2gb ARC (с настройками по-умолчанию) + 80GB l2arc? Каким образом в подобной ситуации (с минимальным размером ARC) достигнуть максимума использования l2arc?

    Спасибо!

    • 0
      Вот пример расчёта количества ОЗУ, требуемого для L2ARC.

      Я бы советовал потратить деньги на ОЗУ, L2ARC на малых конфигурациях не особо вам поможет. Также стоит учесть, что пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
      • 0
        пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
        Вы уверены? Насколько я понял что это уже исправлено. Мои беглые тесты, показали, что l2arc — используется после перезагрузки. Вроде на баг треккере уже закрыты тикеты которые вопрошали об этом.
        • 0
          Был бы рад ошибиться, но эта возможность ещё не опубликована. В ZFSonLinux появится только после публикации патча Nexenta.
          • 0
            Кажется, да, Вы не ошибаетесь. :( В общем, zfs on linux по-прежнему расстраивает (патч был представлен ещё в 2015 году).

            По калькулятору совсем не понял схему рассчётов, что-то зависит от размера блока записи, от типа записи. Но, я если честно (в силу отсутствия опыта и понимания всей картины в целом), не могу правильно аплицировать это на виртуализаию (в моём случае proxmox). Как будет вести запись вирт. машина — не знаю. Да и машины — разные.

            Пока хочу попробовать под ARC отвести 2-3 гб., после чего смотреть процент попадания в l2arc. К сожалению, сервера не имеют физической возможности расширения ОЗУ.

            Как Вы считаете, подобный подход имеет право на жизнь?
            • 0
              патч был представлен ещё в 2015 году

              Стоит уточнить, что стабильный патч Nexenta ещё не выпущен.

              Расчёт простой — на каждый блок в L2ARC нужно ~200байт ОЗУ, для виртуализации скорее всего вы будете использовать zvol с volblocksize=8kb, соответственно на 100гб L2ARC потребуется около 2.5гб ОЗУ, на практике будет меньше.

              Если у вас уже есть ssd, то проведите бенчмарк, иначе для начала просто настройте ограничение на ARC и попробуйте. Главное правильно настроить proxmox, volblocksize должен соответствовать блоку гостевой системы.

              Производительность будет зависеть от особенностей ваших данных, если горячие данные поместятся в ваши 3гб ОЗУ, то это лучше, чем L2ARC.
              • 0
                Огромная благодарность за развернутый ответ. Осталось развеять только один вопрос. Что конкретно означает фраза:

                на 100гб L2ARC потребуется около 2.5гб ОЗУ

                Эта область ОЗУ сама будет забираться из ARC? Или максимально отводимая область под l2arc, будет регулироваться параметром: vfs.zfs.arc_meta_limit?

                • 0
                  https://github.com/zfsonlinux/zfs/issues/1420#issuecomment-16831663

                  Да.

                  Вот интересная информация по этой теме.

                  Добавлю, что в релизе 0.7 требования к ОЗУ сильно оптимизированы, и в вашем случае может помочь (но он ещё в стадии тестирования, без бекапов ставить не рекомендую).
                  • 0
                    Добрый день, огромная благодарность за уделенное внимание! Крайне приятно общаться с разработчиком напрямую.

                    Если я верно понял, то у товарища из треда не удалялся mirror устройство, после чего, он получил объяснение, что это может происходить из-за не достатка памяти в ARC и слишком большого l2arc.

                    В следствии чего, он получил рекомендацию или увеличить ОЗУ для arc, или уменьшить разделы l2arc.

                    Если я Вас понял верно, то для 4GB RAM отведенного под ARC, мне следует ограничить l2arc размером в 60GB, тогда, в среднем, у меня будет уходить для l2arc не более 2gb RAM + 1 GB будет оставаться для собственно ARC и 1 GB под vfs.zfs.arc_meta_limit. При этом, vfs.zfs.arc_meta_limit мне не следует трогать.

                    Все ли верно понимаю?

                    Релиз 0.7, пока мне рановато применять, так-как планирую zfs в продуктивную установку.
                    • 0
                      не удалялся mirror устройство

                      Я дал ссылку на комментарий основного контрибьютора Brian Behlendorf, в котором он разъяснял требования к ОЗУ, касающиеся первого поста в тикете (проблема с производительностью при увеличении L2ARC). Проблема с mirror не касается обсуждаемого нами.

                      Все ли верно понимаю?

                      Всё верно, l2arc можете увеличивать по надобности без даунтайма, если ssd позволяет. arc_meta_limit стоит трогать только если выделенный объём l2arc не заполнится.

                      • 0
                        Благодарю! Последнее что мне не до конца ясно, это от чего я должен отталкиваться при расчетах размера l2arc устройства. От размера ARC, или от размера arc_meta_limit?

                        Если от arc_meta_limit, выходит:

                        ARC = 4GB
                        arc_meta_limit (25% от 4GB) = 1GB
                        volblocksize = 8kb


                        По формуле выходит 40GB — максимальный размер l2arc, если отталкиваюсь от arc_meta_limit.

                        Как понять сколько у меня реально испольузется l2arc? Всё же, arc_meta_used, насколько я понял, косвенный параметр.

                        За сим откланяюсь, больше не буду приставать с вопросами. Ответы на эти вопросы ищу с 2013 года, но так внятности не получил. По этому очень рад возможности спросить у компетентного разработчика!

                        Вообще, это тянет на отдельную статью на Хабре.
                        Ведь есть ещё вопрос по размеру zlog, там я понял чуть проще, размер должен быть таков, чтобы максимум за 5-10 секунд туда успела влезть вся запись с режимом sync.

                        Спасибо!

                        • 0
                          Да, arc_meta_limit ограничивает максимальное количество метаданных в кеше, а записи о l2arc являются метаданными.

                          Статистика по заполнению l2arc есть, к примеру в Linux можно посмотреть
                          cat /proc/spl/kstat/zfs/arcstats
                          


                          Рекомендую без донастроек проверить заполняемость, и только после этого по надобности тюнить arc_meta_limit, т.к. 200 байт ОЗУ на 1 блок l2arc — максимальный расчёт, а не фактический.
  • 0
    А что касаемо установки from scratch для новых систем? С какими дистрибами оно уже в поставке?
    • 0
      https://github.com/zfsonlinux/zfs/wiki/Debian-Jessie-Root-on-ZFS
    • 0
      Если вы имеете в виду установку root раздела системы на ZFS, то пока она включена только в инсталлятор Proxmox. При этом сам пакет с ZFS уже есть во многих репозиториях (Debian, Ubuntu, Arch, Gentoo, Fedora, Centos), ручками ставится без проблем.
  • 0
    В ZFS новичок, рискнул попробовать на паре серверов, когда оно стало наконец «искаропки» в Proxmox.

    На ZFS-зеркало из пары шпиндельных HDD 500GB максимально дефолтно накатил под i5/16GB для экспериментов.
    А в Hetzner сложнее — нет у них автоматизированной процедуры и возможности поставить Proxmox корнем на ZFS без заказа консолей и прочих извратов. В итоге хост поставил на BTRFS-зеркало небольшое, а 200GB под виртуалки разбил вручную, сверяясь с дефолтными параметрами экспериментальной машинки. Вроде конфиги не отличаются. Но Хетцнер — это пара Xeon-ов и Интеловские SSD.

    И вот вопрос. Почему оно выдаёт такие низкие значения IO?
    i5/16GB/2xHDD:
    CPU BOGOMIPS:      23947.04
    REGEX/SECOND:      1604707
    HD SIZE:           300.58 GB (rpool/ROOT/pve-1)
    FSYNCS/SECOND:     83.9

    2xXeon/32GB/2xSSD
    CPU BOGOMIPS:      54394.40
    REGEX/SECOND:      2948181
    HD SIZE:           68.60 GB (rpool/data)
    FSYNCS/SECOND:     36.28

    Это включенная компрессия LZ4 так влияет или CoW или что-то ещё? Без ZFS вроде (на старом Promox) сотни FSYNCS выдавало… но в целом серверу скорости хватает, а плюшки (снапшоты для бэкапов, сжатие) наверное перевешивают.

    Может, не стоит заморачиваться? Или всё же что-то неверно настроено, и даже не руками, а дефолты Proxmox?
    • 0
      Вот тред на форуме Proxmox, в котором есть отзывы о том, что эти измерения не сходятся с фактической производительностью.

      Если вам не критично потерять информацию за последние 5-10 секунд, то вы можете выставить настройку пула sync=disabled, в таком случае ZFS не будет сбрасывать информацию на диск по команде программ, а делать это с определённой периодичностью. Но это повышает производительность за счёт риска потерять записанную информацию за последние 30 секунд (при этом сама ФС на диске битой не будет, можете не переживать).
  • 0
    Eсть отличная статья — перенос корневой ФС на ZFS с шифрованием и созданием RAIDZ.
    Разбираемся в ZFS
    • 0
      Пролистал, в этой статье есть злые советы, которые хотят съесть ваши данные:
      — RAID-Z1 не рекомендуется к использованию, лучше использовать RAID-Z2, который выдержит отказ 2 дисков;
      — параметр copies=3 никак не спасает от выхода из строя 2х дисков из 3х в RAID-Z1.

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