А что я Вам скажу? У Вас личный опыт >>>> рекомендаций от разраба

Если Вы считаете, что знаете zfs лучше него - ну велп, помните про бэкапы

Еще раз. Рекомендации давать ZFS устройство - не является ЗАПРЕЩЕНИЕМ использовать что-то другое. И к надежности это НЕ имеет отношения.

Когда придёте с вопросом "А что делать у меня отключилось питание и zfs import говорит no pools available" тогда мы вспомним этот разговор

Опять вранье

общение тут не предполагает токсичности, даже завуалированной

One might be inclined to try using single-drive RAID 0 arrays to try to use a RAID controller like a HBA, but this is not recommended for many of the reasons listed for other hardware RAID types. It is best to use a HBA instead of a RAID controller, for both performance and reliability. reliability - надежность поэтому кто тут врёт надо еще подумать

Еще раз. Рекомендации давать ZFS устройство - не является ЗАПРЕЩЕНИЕМ использовать что-то другое. И к надежности это НЕ имеет отношения.

Весело однако, поинты от @pan5a Слушать рекомендации разраба? Нет, у меня и так все работает Читать документацию? Хуйня, у меня на файлах уже 5 лет все работает Reliability != Надёжность #лучшие_моменты_этого_чата

про железоRAIDы можно свести к 2 пунктам: 1. если железо заглючит то превед данным и гарантии ZFS не помогут 2. если RAID5/6 уже сделан на железном, то с т.з. автозафиксивания данных это хуже чем если бы был raidz1/z2 ни один из этих пунктов не вижу как может быть актуальным для device mapperа и dm_crypt

ZFS поверх Raid - это однозначно плохо: и по скорости и по надежности (в целом, за счет усложнения)

А вот например как может быть плох raid0 уже не очень понятно. НЯЗ ZFS сама raid0-like разгон блоков 1 файла по девайсам не делает, и с другой стороны raid0 никак не завязан на дублировании инфы и хитрых write hole'ах и подобном

а вот хранилки, собранные "по книжке" на фряхе , с HBA - работают годами, вообще без проблем. Ток сбойные диски меняй. В сумме уже за петабайт перевалило

У нас тоже есть хранилки, и несколько, но и года не прошло, чтоб без проблем. Хотя потерь данных, никогда не было.

Это глубокая тема, но да - все (ок, которые я лично знаю) качественные источники категорически не рекомендуют raid перез zfs. Максимум - это режим pass thru (по разному у разных вендоров) - т.е когда контроллер условно как сокет для подключения диска, и не вмешивается

У нас тоже есть хранилки, и несколько, но и года не прошло, чтоб без проблем. Хотя потерь данных, никогда не было.

Чисто по личным оценкам, у нас процентов 80 железных проблем связаны с железными рейдам. Пофиг какой вендор - адаптек, lsi, всё говно

Интересно. А можете рассказать на чем собрано?

ОК, с контроллерами конечно дело такое, и я готов согласиться. Но просто raid0 при помощи mdraid чем может быть плох?

А какой % адаптека у тебя? :)

Особенно поймали на 2.1.(3-5) с дедупликацией кучу проблем

ну блин. не надо включать дедупликацию. =)

Как минимум, лишняя прослойка. ZFS работает с диском, подразумевая, что имеет прямой (ну, насколько это сейчас можно назвать прямым) доступ к железке. =)

Ну вообще "подразумевать" такое странно. В виртуалке например будет точно прослойка, а то и не одна.

Ну вообще "подразумевать" такое странно. В виртуалке например будет точно прослойка, а то и не одна.

В виртуалку можно сделать pcie passtrought у адаптера, по крайней мере у Вари это достаточно прямая операция с точки зрения дополнительных прослоек

Срочно нужно было несколько сотен тер места освободить ))) Понятно, что не надо. "Но ведь она-же есть"

И раз в квартал-два, что-то да произойдет, обязательно ))

С ней жопа, что вход рубль - а выход 10. А на выход сильно хочешь, когда всё начинает вставать колом. Плавали =(

Закончилось тем, что на хостах внезапно оказалось по 1TB памяти, но и это не помогло. Мрак короче. Я бы определил в zfs часть функционала в (experiment only) и включал бы только по особому ключу.

так а происходит с железом или... ?

1тб RAM? :))

Да

Закончилось тем, что на хостах внезапно оказалось по 1TB памяти, но и это не помогло. Мрак короче. Я бы определил в zfs часть функционала в (experiment only) и включал бы только по особому ключу.

Рядом развернули на весь объем ceph в марте 2023, дублируем данные в двух местах. Кроме того, что ceph удобнее мониторить и нужно сильно больше дисков, оно еще и быстрее в разы оказалось. А т к от полок отказались, на часть аппаратных проблем стало меньше.

Это серьезно. Ну а размер пула тогда каков был?

Рядом развернули на весь объем ceph в марте 2023, дублируем данные в двух местах. Кроме того, что ceph удобнее мониторить и нужно сильно больше дисков, оно еще и быстрее в разы оказалось. А т к от полок отказались, на часть аппаратных проблем стало меньше.

Там был 1pb тогда, группами из 24 дисков.

пропиши чтоб не сбрасывалось :) https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/ZFS%20on%20Linux%20Module%20Parameters.html#zfs-on-linux-module-parameters

Рядом развернули на весь объем ceph в марте 2023, дублируем данные в двух местах. Кроме того, что ceph удобнее мониторить и нужно сильно больше дисков, оно еще и быстрее в разы оказалось. А т к от полок отказались, на часть аппаратных проблем стало меньше.

если у вас сепх оказался быстрее в разы зфс, мне страшно представить что вы там наконфигурировали в зфс))

хотя в целом это реально замутить Например делать пул не из mirror, а из raidz2 например + включить дедупликацию, ну и как-то позвращаться с сжатием и размером блоков, и всё будет атк тупить что заплачешь

По иопсам конечно zfs сильно быстрее на мелких блоках, тут спорить бесполезно.

По иопсам конечно zfs сильно быстрее на мелких блоках, тут спорить бесполезно.

и по латенси на порядок быстрее))

По иопсам конечно zfs сильно быстрее на мелких блоках, тут спорить бесполезно.

ты скажи хоть один параметр по которому zfs проигрывает)), сепх сильно тупее если готовить зфс нормально, а не как я выше написал)

Ай, как вы сравниваете, цеф же другого поля ягода совсем

Да, все так. Но нам как раз латенси не особенно важны. Это не виртуализация, а контент хранилка.

Я не против zfs, просто для нас эту стало архитектурным тупиком.