ZFS vs mdadm

Нельзя решейпить, ни добавить диски в пул (или убрать), ни перестроить, скажем, RAID0 (как оно называется) в RaidZ.

Зато с ZFS'овскими RAID можно делать что угодно, и оно не рассыпется в процессе.

Всякие снапшоты, сжатие и прочее ненужно

Снапшоты не нужны? Из них можно сделать dump, будет бэкап.

Сжатие — фича сомнительная в половине юзкейсов, но и его можно применить с умом.

производительность, при прочих равных.

ZFS жрёт больше памяти, но это относительно тюнится. Не знаю, сколько жрёт mdadm, не замерял.

И процессор что больше жрёт, и насколько?

В зависимости от конфигурации, но подозреваю, что ZFS будет жрать больше в любом случае, пусть и немного. Во время чека на слабой железке наверняка будет ощутимо.

Зато с ZFS'овскими RAID можно делать что угодно, и оно не рассыпется в процессе.

Это что имеется в виду, в сравнении с mdadm?

Это что имеется в виду

Добавлять, заменять, убирать диски. Впрочем, сам я не пробовал, у меня нет столько дисков, чтобы юзать дома RAID(Z).

Были истории успеха, что часть дисков в RAID при загрузке не поднимались, но ZFS продолжало работать без них. С хардварным RAID это бы убило все данные.

С хардварным RAID это бы убило все данные

Это с чего? Если избыточность достаточная, любой RAID же должен подниматься и работать

Это с чего? Если избыточность достаточная, любой RAID же должен подниматься и работать

зависит от настроек того, чем ты этот рейд собираешь (mdadm/lvm)
может быть настроено так, что degraded raid по умолчанию не будет использован при загрузке

вот пример для lvm

        # Configuration option activation/activation_mode.
        # How LVs with missing devices are activated.
        # The --activationmode option overrides this setting.
        # 
        # Accepted values:
        #   complete
        #     Only allow activation of an LV if all of the Physical Volumes it
        #     uses are present. Other PVs in the Volume Group may be missing.
        #   degraded
        #     Like complete, but additionally RAID LVs of segment type raid1,
        #     raid4, raid5, radid6 and raid10 will be activated if there is no
        #     data loss, i.e. they have sufficient redundancy to present the
        #     entire addressable range of the Logical Volume.
        #   partial
        #     Allows the activation of any LV even if a missing or failed PV
        #     could cause data loss with a portion of the LV inaccessible.
        #     This setting should not normally be used, but may sometimes
        #     assist with data recovery.

так как mdadm и lvm софтрейд собирают одним и тем же модулем, наверняка такое же есть и для mdadm

Сжатие — фича сомнительная в половине юзкейсов

сжатие у zfs — самая простая фича, даже думать нечего. она должна быть и всё, минусов нет, одни плюсы.

Традиционный RAID защитит тебя только от вылета диска целиком. RAIDZ или любой другой RAID с чексуммами — защитит в т. ч. от тихих ошибок. Вот и решай. А ещё zfs-RAID или btrfs-RAID будет пересобирать только то, что используется, что в случае с RAID5/6 вполне может изменить шансы на успех пересборки.

Просто ссылка: Существенный прогресс в проекте ZFS для FreeBSD (комментарий)

сжатие у zfs — самая простая фича, даже думать нечего. она должна быть и всё, минусов нет, одни плюсы.

Хранить /var в сжатом виде? Лол.

Не везде оно нужно, но да, жрать не просит.

Ну это понятно, хэши же, зато постоянные накладные расходы

Ты лучше расскажи, как там с фрагментацией? Постоянный copy-on-write это конечно хорошо, атомарность, но всё-таки? А дефрагментаторов то нет в принципе.
Вот например, файл 100 ГБ, допустим образ жесткого диска. Что произойдёт при перезаписи участка где-нибудь в середине, выделятся новые блоки где-нибудь фиг знает где, где есть свободное место, и файл останется фрагментированным? Или это как-то разруливается?

Ты лучше расскажи, как там с фрагментацией?

Даже не задумывался по этому поводу - у меня SSD под систему и программы и RAID-Z под файлы пользователей.

файл останется фрагментированным? Или это как-то разруливается?

Всё разруливается самой файловой системой. Зачем что-то делать самому специально?

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

В зависимости от конфигурации, но подозреваю, что ZFS будет жрать больше в любом случае, пусть и немного. Во время чека на слабой железке наверняка будет ощутимо.

Во время scrub на скай селероне отьедает от 5% до 20% (среднее 12-15) по двум ядрам одновременно, после проверки около 5-7% держиться нагрузка на моём NAS и это с учётом того, что параллельно идёт синк Soumi Music Player по WebDAV через NextCloud что отжирает 5-10% CPU. Минут через 50 могу сказать сколько будет загрузка CPU в простое.

0,7% с apache, mysql, ftp, samba и что-то там ещё без нагрузок

Если нужна производительность то однозначно mdadm. Но лучше raid 10 собирать. Ну или смотри в сторону Btrfs.

ZFS думаю будет быстрее т.к. юзает много оперативы и позволяет юзать кэш не только в ОЗУ, ну и на отдельном SSD

Никогда не видел как логи засирают все место? Вон недавно у почты РФ сайт слетел из-за подобного. А если логи вынести на раздел со сжатием, про них вообще можно забыть.

RAIDZ или любой другой RAID с чексуммами — защитит в т. ч. от тихих ошибок

scrub repaired 1.62M in 18h18m with 0 errors on Sun Oct 1 19:18:29 2017

вот за это я и люблю zfs, солдат спит - служба идет

Это какого размера пул, что scrub идёт 18 часов? Или ты ограничивал скорость проверки?

как часто рекомендуют запускать скраб ?

Я бы рекомендовал обязательно запускать скраб перед перезагрузкой иначе можно не загрузиться =)

36 Тб

как угодно, я раз в квартал запускаю

Это почему это ?

А сколько из них занято?

83%

но вообще скорость сильно гуляет от количества мелких файлов, у меня было до 40 часов

Забавно. У btrfs скраб на порядок медленнее.

Это почему это ?

У меня стоит Ubuntu 17.10 и Root on ZFS. ОЗУ без ECC. И если возникают ошибки, которые не связаны с HDD, то после перезагрузки grub пишет error check summ и отказывается грузить ОС. Лечиться скрабом из Live CD Ubuntu 17.10 Desktop, правда нужен интернет чтобы докачать пакеты для zfs.

Думаю, если бы была конфигурация с ECC, то такой бы проблемы не было.

ZFS думаю будет быстрее т.к. юзает много оперативы

Вот с таким подходом как раз будет все тормозить К ТС: Протестировать 3 конфигурации на реальном железе где будешь использовать(mdadm vs zfs vs btrfs), уйдет где-то 3-6 часов, ну или день если ты хочешь заполнить данными, и приблизиться к реальному использованию еще больше. Слушать же советы бесполезно в данном случае, потому-что тут будет каждый хвалить свое, а чужие тесты показывать совершенно другое. А вот в случае если ты просто последуешь совету одной из сторон, ты просто можешь оказаться в ситуации, когда уже все будет тормозить, а на перенос всего этого уйдет гораздо больше времени, плюс если еще и важен аптайм, то во время переноса, ты так просто не отключишь свой RAID, а значит тормозить будет еще больше, или тебе придется переносить данные неделями. Я вот так уже с ZFS напоролся, когда под ZFS у меня было 15 MB/s вместо ~100 в одном случае и 1-12MB/s вместо 40-60 в другом. И пришлось все переносить, когда это уже было в использовании.
Лично по моим наблюдениям ZFS всегда очень сильно тормозит, на любом железе, а там где она не тормозит, просто можно было бы гораздо больше выжать с того же железа если бы использовались ext4/xfs или даже btrfs. И вообще не стоит использовать ZFS или Btrfs, если тебе явно не нужен функционал присутствующий в данных ФС. Тут можно привести аналогию с NoSQL vs реляционными базами данных. Т.е. есть случаи где это явно нужно и необходимо, но для 80% задач это overkill, и только усложнее архитектуры, а если это еще и выбрано просто потому-что это модно, то это еще с большой вероятностью будет слабым местом всей конструкции. И рухнет как карточный домик, как только появится нагрузка.

Как-то слабо верится в то что повреждения данных случаются так часто на исправном оборудовании.

У меня стоит Ubuntu 17.10 и Root on ZFS.

И если возникают ошибки, которые не связаны с HDD, то после перезагрузки grub пишет error check summ и отказывается грузить ОС.

Похоже на проблемы с ядром, а не с ZFS. Они вообще совместимы (ядро и модуль ZoL) или только частично?

Лично по моим наблюдениям ZFS всегда очень сильно тормозит, на любом железе, а там где она не тормозит, просто можно было бы гораздо больше выжать с того же железа если бы использовались ext4/xfs или даже btrfs. И вообще не стоит использовать ZFS или Btrfs, если тебе явно не нужен функционал присутствующий в данных ФС.

Так ненужный функционал в ZFS отключается на уровне свойств.

А если логи вынести на раздел со сжатием, про них вообще можно забыть.

Причём здесь логи? В /var помимо /var/log есть ещё интенсивно переписываемые /var/db, /var/cache. И малейший факап сломает весь твой линукс к чертям.

Но, если уж ты заговорил о логах, то не забыл ли ты, что у systemd они бинарные?

Ну да реальных тестов не хватает, но в остальном не согласен. Ибо по замерам скорости один диск у меня читает/пишет 160-180 мб в сек, тогда как в raidz это уже 220-240 мб в сек. А в raid5 на ext4 было внезапно 90 мб в сек.

Ну smart нормальный, без релокаций и ошибок. Что еще может быть?!

Ну думаю, не должно быть, ведь ставил по инструкции с github'a zfs. Попробую написать разработчикам, может что-то подскажут

Причем тут /var, ты ручками отдельно /var/log не можешь смонтировать? Я тебе привел реальный сценарий из прода. А логами гадят в основном всякие php/python/etc от криво написанного кода. Я не знаю что и где бинарного ты видел, у нас они самые обычные, а размер исчисляется гигабайтами. Снапшоты и бекап баз аналогично. И если уж на то пошло, бинарность не отменяет сжатия.

Капееееец! При чем тут смарт? Это просто сигнализация, что винт скоро врежет дуба. Целостность данных никто кроме ZFS не контролирует. Раньше на это можно было забить болт, но размеры выросли настолько, что ошибки стали более чем реальными (см мой пример выше). У самого контроллера винта есть ошибки 3х типов - 1) контроллер видит и исправляет, 2) контроллер видит и не исправляет и 3) контроллер не видит и не исправляет. Ошибки 1 исправляются прозрачно, но вагонами. Ошибки 2 передаются в ОС и она предупреждает, что «что-то пошло не так». Ошибки 3 ты заметишь только когда полимеры будут уже просраны. А 2-3 еще и сами появляются при простом хранении. А уж в контексте темы важнее, что 2-3 могут появиться при ребилде массива. И вот тут то mdadm сосет.

Другими словами, если ты хочешь, чтобы работало быстро, здесь и сейчас - ставь mdadm. Если согласен пожертвовать скоростью ради надежности и целостности данных - твой выбор за zfs.

Я тебе привел реальный сценарий из прода.

Мне? У меня сжатие включено везде, где оно нужно (и отключено там, где в нём нет необходимости). Это ТС задал вопрос, я лишь ответил с минимумом субъективизма.

Я не знаю что и где бинарного ты видел

Ещё раз повторяю: у меня на десктопе — systemd.

у нас они самые обычные

На проде есть logrotate, нефиг проц шатать на сжатие, когда можно отломать от лога кусок и gzip-нуть его (less умеет читать жатые логи, zgrep решает вычленение нужной информации). Но если процессор нормальный, то пофиг, да.

а размер исчисляется гигабайтами

Ну logrotate же.

И если уж на то пошло, бинарность не отменяет сжатия.

Это дополнительные затраты. Я не могу с уверенностью сказать, жмёт ли systemd свои логи (даже не задавался таким вопросом), но лучше перестраховаться.

Другими словами, если ты хочешь, чтобы работало быстро, здесь и сейчас - ставь mdadm. Если согласен пожертвовать скоростью ради надежности и целостности данных - твой выбор за zfs.

Кратко и содержательно. Есть ссылки по теме?

Это дополнительные затраты

Насколько я могу судить, несжимаемые данные не тратят cpu, если включен lz4 (по умолчанию)

Есть ссылки по теме?

Ну оффманы на сайте оракла. Имхо достаточно понимать, что zfs была создана by design такой, чтобы силами cpu+ram+ssd заменить дорогие железные контроллеры и сохранить данные любой ценой. То есть все работает с позиции презумпции виновности железа и любой этап обработки данных страхуется.

Насколько я могу судить, несжимаемые данные не тратят cpu, если включен lz4 (по умолчанию)

lz4 жмёт весьма паршивенько.

Ну оффманы на сайте оракла.

Я не о ZFS (у меня гента с корнем на, мне не надо объяснять, что из себя представляет файловая система), а о сравнениях (в цифрах, естественно) оной с mdadm, бенчах, техническом сравнении.

А в raid5 на ext4 было внезапно 90 мб в сек.

stripe_cache_size увеличь, будет скорость.

Протестировать 3 конфигурации на реальном железе где будешь использовать(mdadm vs zfs vs btrfs), уйдет где-то 3-6 часов

Плохая идея. Лучше сначала 3-6 часов почитать доки, а потом вдумчиво приступать к тестированию. mdadm raid 5(6) будет дико тормозить на запись без тюнинга параметров, в случае zfs так вообще надо четко понимать с какими данными она будет применяться и тюнить ФСы соответственно задачам. А накатить конфигурации, по умолчанию, протестировать скорость, накатить второе(третье и т.п.) померить скорости - путь в никуда.

lz4 жмёт весьма паршивенько

Зато систему не сношает. Весь смысл то в этом. А такого сжатия как 7zip/rar и не будет.

Зато систему не сношает. Весь смысл то в этом.

Это имеет смысл с каким-нибудь плейнтекстом, но почти бессмысленно с бинарями, и уж тем более не имеет смысла с медией.

А такого сжатия как 7zip/rar и не будет.

Есть zlib, и процессор шатает оно весьма ощутимо. Сжатие лучше lz4.

Протестировать 3 конфигурации на реальном железе где будешь использовать(mdadm vs zfs vs btrfs), уйдет где-то 3-6 часов

Это если винты пустые, а когда надо переносить данные, так не получится.
Кстати, здесь и всплывает недостаток в отсутствии возможности решейпа. Если mdadm можно сделать raid5 из двух дисков (или даже одного как degraded), и потом постепенно расширять, то zfs надо сразу создавать нужную геометрию.
Хотя можно извернуться, создать на одном винте нужное количество разделов, потом постепенно переносить разделы на освобождающиеся винты, одновременно расширяя.
Вот неужели так сложно было бы сделать утилиты для этого, хотя бы в режиме оффлайн (при размонтированных разделах)?

Алсо, постоянный CoW будет вести к фрагментации (если винты постоянно не свободны на половину), а дефрагментатора нет вообще.

И само устройство ZFS, вот эти контрольные суммы. Вроде хорошая идея, но что-то многие пишут про ошибки чексумм с не-ECC памятью. Очевидно, они могут случиться на любых ФС, только вот я не помню подобного, например, как-то после переписывания теребайта данных с торрентами, все хэши проверились успешно.
Так вот вопрос такой, а не сама ли ZFS провоцирует эти ошибки, когда сжирает тонны памяти под свои нужны?

С другой стороны, ресинк RaidZ сделан более вкусно (что неудивительно, mdadm работает уровнем ниже и ничего не знает про файлы и ФС).

А какой был порядок количества мелких файлов? 10^5, 10^6, 10^7?
Вообще, как работает ZFS переваривает много мелких файлов, относительно той же ext4?

Ну или смотри в сторону Btrfs

А оно не RIP?
Вообще да, оказывается, они тоже похожую вещь делают (ну или делали), но не готово
https://btrfs.wiki.kernel.org/index.php/RAID56

Это сколько винтов, и какого уровня рейд?