Верно, в OpenZFS теперь у пула всегда версия 5000 и набор флагов. Если хотя бы один флаг пула не поддерживается конкретной реализацией — он не импортируется (но есть и read-only флаги, то есть с ними пул можно примонтировать, но только в режиме чтения). Флаги можно активировать выборочно.
Всё даже хуже бывает — просто попробовав обновить (рассчитать ещё раз) маршрут, с каждым разом цена гарантированно становится больше. Что интересно, такое поведение и на убере, и на я.такси.
А уехать из Шереметьево вообще может не получиться, отображается баснословная цена, НО такси не находится. Что самое интересное — там есть стойка Яндекс.такси, которая работает по другому принципу, и у них стоят машины в ожидании и с другими ценами (но через приложение их не заказать). Очень забавно в 5 утра было пытаться уехать домой.
По городу спасает только UberStart с ещё адекватными ценами, но не везде они приедут.
А наработки Oracle реверсить и не надо, плюс некоторые из них не оптимально реализованы. К примеру, анализ реализации шифрования github.com/zfsonlinux/zfs/issues/494#issuecomment-178853634. Что позволило сделать шикарную реализацию шифрования в OpenZFS, она уже в мастер ветке.
А вообще прогресс идёт, скоро накопится на ещё одну обзорную статью по новым фичам в ZoL.
Отмечу, что этот список не является истиной в последней инстанции (т.к. некоторые производители, к примеру Samsung, так и не дали официальной информации по определённым моделям). Для удобства добавлю ссылку в статью.
Как я писал выше, виртуальный машины лежат в raw файлах поверх ext4
Извиняюсь, опечатался, не vdev а volume. Для zfs это бессмысленно, у него для этих целей есть volume, proxmox их поддерживает. Моё личное мнение — тестировать надо весь стек, включая виртуализацию, то есть ставить vm с драйверами и внутри гонять fio. Для raw файла должны быть дополнительные накладные расходы.
почему? какой оптимальный и почему?
Выше уже давали ссылку на размеры ashift для ssd, чаще всего они 8к и более. Также бывает, что быстрее работает 512б (особенности конкретного ssd).
Потому что в конце статьи ваше решение о выборе исходит только из полученных вами цифр (перечитал, всё равно складывается именно такое ощущение), не упоминаются ни контрольные суммы, ни снапшоты. Именно снапшоты дадут вам выигрыш во многих моментах с виртуализацией.
Также про сравнение «zraid/2 или 0+1» — у raidz будет всегда хуже iops, везде об этом говорится (подтверждаю личным опытом), raidz ограничен iops самого медленного диска в массиве. То есть raid 10 из 4 дисков должен быть при правильных настройках быстрее по iops, чем raidz1 на этих же дисках. Ваши цифры говорят именно о проблемах с настройкой zfs.
Извините, так вы что тестируете, работу с файлами, или гипервизор? Для бенчмарка гипервизора (к примеру, на kvm) нужен совсем другой подход, где как раз mdadm + ext4 даст просадку.
Многие комментаторы выше уже указали на явные вопросы в тесте.
Касаемо zfs — вы собрали большинство worst practices:
проигнорирован recordsize (что больше всего проблем вам и даёт)
тестируется dataset, когда в гипервизоре будет применяться vdev
забыли о xattr=sa (иначе на каждую операцию с метаданными на линуксе вы прибавляете по несколько io)
не оптимальный ashift
raid контроллер (даже в режиме it mode это не лучший вариант), тем более для ssd
игнорируете cow природу zfs, на гипервизоре её возможности вам очень понадобятся, при использовании снапшотов ощутите отсутствие нагрузки, которая раньше была при создании бекапов
Не всё так однозначно. Естественно, что zfs будет медленнее на многих кейсах, но у неё куча killer фич, а в некоторых случаях (к примеру, случайная запись — превращается в последовательную) она всегда будет рвать другие ФС.
У каждой ФС своё применение, не судите так однозначно.
Если вам интересно — я полгода назад писал статью о zfs и её подводных камнях https://m.habrahabr.ru/post/314506/, состою в проекте ZFSonLinux. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.
Если хотите использовать дедупликацию, то рекомендую изучить требования к ОЗУ более подробно, там нет стандартного размера на 1тб, там есть примерно 320 байт ОЗУ на каждый блок (для dataset это recordsize).
Рекомендую прочитать этот комментарий, давал в нём методы точного расчёта требований.
Также добавлю, что ОЗУ требуется для записи, на чтение дедупликация не влияет (только если вы записываете параллельно с чтением, и при этом у вас кончилась ОЗУ, тогда для каждой операции записи будет много случайных IO чтения на диск).
Перед использованием дедупликации стоит понять, сколько же ОЗУ она потребует и насколько она применима к вашим данным, в этом комментарии про это писал, рекомендую ознакомиться. Также zdb вам в помощь, смотрите ключ -D и -S.
Если ОЗУ хватает, то стоит смотреть, в какой момент именно возникает проблема, что съелось и др., в части arc может помочь
cat /proc/spl/kstat/zfs/arcstats
Кстати, вам точно нужен relatime?
Чуть не забыл, срочно включите xattr=sa, на большом количестве мелких файлов иначе будет сильное просаживание производительности, об этом упоминал в статье.
Не касаемо обсуждаемой проблемы, вы не совсем верно поняли значение quota и refquota, они в данном случае ничем не помогут, а ваши команды выполняют дословно:
Самые актуальные новости — в описании релизов ZFSonLinux github.com/zfsonlinux/zfs/releases. Описания флагов —
man zpool-features
Эта функция будет в версии 0.8 (она уже в кодовой базе master ветки, в статусе rc).
Даже кот доволен!
А уехать из Шереметьево вообще может не получиться, отображается баснословная цена, НО такси не находится. Что самое интересное — там есть стойка Яндекс.такси, которая работает по другому принципу, и у них стоят машины в ожидании и с другими ценами (но через приложение их не заказать). Очень забавно в 5 утра было пытаться уехать домой.
По городу спасает только UberStart с ещё адекватными ценами, но не везде они приедут.
— github.com/zfsonlinux/zfs/issues/3779 отдельное хранение DDT/metadata на SSD, уже в виде патча, будет включён в 0.8
— open-zfs.org/w/images/8/8d/ZFS_dedup.pdf предложение по улучшению скорости DDT в ~1000 раз
А наработки Oracle реверсить и не надо, плюс некоторые из них не оптимально реализованы. К примеру, анализ реализации шифрования github.com/zfsonlinux/zfs/issues/494#issuecomment-178853634. Что позволило сделать шикарную реализацию шифрования в OpenZFS, она уже в мастер ветке.
А вообще прогресс идёт, скоро накопится на ещё одну обзорную статью по новым фичам в ZoL.
Извиняюсь, опечатался, не vdev а volume. Для zfs это бессмысленно, у него для этих целей есть volume, proxmox их поддерживает. Моё личное мнение — тестировать надо весь стек, включая виртуализацию, то есть ставить vm с драйверами и внутри гонять fio. Для raw файла должны быть дополнительные накладные расходы.
Выше уже давали ссылку на размеры ashift для ssd, чаще всего они 8к и более. Также бывает, что быстрее работает 512б (особенности конкретного ssd).
По raid контроллеру всё просто — даже в режиме it mode он работает через свой ограниченный процессор, тогда как настоящий hba контроллер намного эффективнее. Вот вам ссылка со списком по скоростям blog.zorinaq.com/from-32-to-2-ports-ideal-satasas-controllers-for-zfs-linux-md-ra
Потому что в конце статьи ваше решение о выборе исходит только из полученных вами цифр (перечитал, всё равно складывается именно такое ощущение), не упоминаются ни контрольные суммы, ни снапшоты. Именно снапшоты дадут вам выигрыш во многих моментах с виртуализацией.
Также про сравнение «zraid/2 или 0+1» — у raidz будет всегда хуже iops, везде об этом говорится (подтверждаю личным опытом), raidz ограничен iops самого медленного диска в массиве. То есть raid 10 из 4 дисков должен быть при правильных настройках быстрее по iops, чем raidz1 на этих же дисках. Ваши цифры говорят именно о проблемах с настройкой zfs.
3) по умолчанию prefetch включён https://github.com/zfsonlinux/zfs/blob/master/man/man5/zfs-module-parameters.5#L1625
Извините, так вы что тестируете, работу с файлами, или гипервизор? Для бенчмарка гипервизора (к примеру, на kvm) нужен совсем другой подход, где как раз mdadm + ext4 даст просадку.
Многие комментаторы выше уже указали на явные вопросы в тесте.
Касаемо zfs — вы собрали большинство worst practices:
Не всё так однозначно. Естественно, что zfs будет медленнее на многих кейсах, но у неё куча killer фич, а в некоторых случаях (к примеру, случайная запись — превращается в последовательную) она всегда будет рвать другие ФС.
У каждой ФС своё применение, не судите так однозначно.
Если вам интересно — я полгода назад писал статью о zfs и её подводных камнях https://m.habrahabr.ru/post/314506/, состою в проекте ZFSonLinux. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.
Я правильно понял, что в качестве интерфейса выступает Intel Manager for Lustre?
Спасибо!
Рекомендую прочитать этот комментарий, давал в нём методы точного расчёта требований.
Также добавлю, что ОЗУ требуется для записи, на чтение дедупликация не влияет (только если вы записываете параллельно с чтением, и при этом у вас кончилась ОЗУ, тогда для каждой операции записи будет много случайных IO чтения на диск).
Если ОЗУ хватает, то стоит смотреть, в какой момент именно возникает проблема, что съелось и др., в части arc может помочь
Кстати, вам точно нужен relatime?
Чуть не забыл, срочно включите xattr=sa, на большом количестве мелких файлов иначе будет сильное просаживание производительности, об этом упоминал в статье.
tank/rc-544 — quota — лимит на размер датасета, включая его дочерние датасеты
tank/rc-544 — refquota- лимит на размер датасета, исключая дочерние датасеты.
То есть никакого запаса нет, вы съели всё разрешённое место (упёршись в наименьшую квоту).
Рекомендую следить за местом и увеличивать его заранее, а не руками по факту. К сожалению, в ближайшее время это поведение точно не будет изменено.
В рамках ZFS — да, но у вас дополнительно есть EXT4. Это, кстати, ухудшит дедупликацию, т.к. она проводится на уровне блоков.
Эх, вам бы от ext4 отказаться бы. На чистом ZFS случай битрикса можно очень классно настроить.
А вам точно нужна дедупликация ради ядра битрикса? Оно весит не так много и отлично сжимается. Или в планах ещё что-то?