LINUX.ORG.RU
ФорумAdmin

ZFS vs mdadm

 , ,


0

3

Хотелось бы прояснить, преимущества, недостатки, если сравнивать софтовый RAID5/6 и RaidZ/Z2

Как я вижу, минусы ZFS:
Нельзя решейпить, ни добавить диски в пул (или убрать), ни перестроить, скажем, RAID0 (как оно называется) в RaidZ. Кстати, чем это обусловлено, принципиально возможно сделать такую утилиту?
Жрёт много памяти, и желательно ECC.
Нужно собирать модули для линукса, а mdadm более-менее из коробки.

Плюсы ZFS:
При ресинке не нужно читать весь диск, только где данные.
После некорректного завершения ресинк не нужен (без костылей в виде intent bitmap)
Всякие снапшоты, сжатие и прочее ненужно

Интересует: производительность, при прочих равных. Допустим, память куры не клюют, что тогда будет быстрее? И процессор что больше жрёт, и насколько? (подозреваю, ZFS, т.к. считает свои хешсуммы)
Насколько для ZFS важна ECC память, относительно других ФС? Понятно, что по-хорошему, она нужна везде, но одно дело побьётся один бит в одном файле за 10 лет, другое дело - постоянные ошибки
Ну и вообще, какие-либо особенности того или другого варианта

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

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

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

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

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

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

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

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

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

TheAnonymous ★★★★★
() автор топика
Ответ на: комментарий от TheAnonymous

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

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

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

TheAnonymous ★★★★★
() автор топика
Ответ на: комментарий от TheAnonymous

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

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

Deleted
()
Ответ на: комментарий от Deleted

вот пример для 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

Deleted
()
Ответ на: комментарий от r3lgar

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

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

system-root ★★★★★
()

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от system-root

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от iZEN

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

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

TheAnonymous ★★★★★
() автор топика
Ответ на: комментарий от TheAnonymous

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

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

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

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

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

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от r3lgar

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

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

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

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

AntonyRF ★★★★
()

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

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

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

AntonyRF ★★★★
()
Ответ на: комментарий от r3lgar

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

Lordwind ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

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

intelfx ★★★★★
()
Ответ на: комментарий от Deleted

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

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

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

AntonyRF ★★★★
()
Последнее исправление: AntonyRF (всего исправлений: 1)
Ответ на: комментарий от AntonyRF

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, и только усложнее архитектуры, а если это еще и выбрано просто потому-что это модно, то это еще с большой вероятностью будет слабым местом всей конструкции. И рухнет как карточный домик, как только появится нагрузка.

anonymous_sama ★★★★★
()
Ответ на: комментарий от AntonyRF

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

Deleted
()
Ответ на: комментарий от AntonyRF

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

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

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

iZEN ★★★★★
()
Ответ на: комментарий от anonymous_sama

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

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

iZEN ★★★★★
()
Ответ на: комментарий от Lordwind

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от anonymous_sama

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

AntonyRF ★★★★
()
Ответ на: комментарий от iZEN

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

AntonyRF ★★★★
()
Последнее исправление: AntonyRF (всего исправлений: 1)
Ответ на: комментарий от r3lgar

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

Lordwind ★★★★★
()
Ответ на: комментарий от AntonyRF

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

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

Lordwind ★★★★★
()
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

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

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

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

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

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

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

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

Ну logrotate же.

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от Lordwind

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

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

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

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

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

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

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

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от AntonyRF

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

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

King_Carlo ★★★★★
()
Ответ на: комментарий от anonymous_sama

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

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

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от r3lgar

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

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

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

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

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

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

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

r3lgar ★★★★★
()
Ответ на: комментарий от anonymous_sama

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

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

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

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

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

TheAnonymous ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

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

TheAnonymous ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

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

TheAnonymous ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.