raid5/raid6 на дисках современных объёмов

На диски такого размера ставим Ceph или zfs, всё равно их либо под виртуалки, либо под хранение тонны снапшотов.

И… сталкиваемся с той же проблемой. Backfill/resilvering никуда не девались

1. " Как перестать бояться и попробовать lvm raid и zfs raid "

Для домашнего компа этого хватит. На СХД применяются те же принципы (в зеркале только то, что реально аллоцировано), но более удачно реализовано (у них trim/discard сразу позволяет контроллеру выбросить экстент из списка аллоцированных

Но если до сих пор страшно, можешь разбить диск на партиции меньшего размера, объединять в несколько разных рейдов, а ребилдить строго по очереди

2. ну и бекапы никто не отменял

О каком количестве дисков идёт речь?

С моими условными «до 4 на массив» я вполне успешно за ~10 лет переползал несколько раз raid1 -> raid5 -> raid6 -> raid1 и lvm поверх. В том числе с множественной пересинхронизацией в виду нехватки дисков. и особых проблем не видел.

lvm raid и zfs raid

Речь была не про движок рейда, а про его тип. Рейд6 всегда будет рейдом6, хоть mdadm, хоть zfs, хоть аппаратный рейд. И сказанное в теме одинаково актуально для любых его реализаций.

С моими условными «до 4 на массив»

С таким условием raid6 смысла не имеет и никогда не имел, лучше зеркала делать. Более-менее целесообразность raid6 начинается с конфигурации 4 данных + 2 избыточные т.е. 6 дисков. raid5 от 2+1 до 4+1.

В том числе с множественной пересинхронизацией в виду нехватки дисков. и особых проблем не видел.

Это были 20тб диски с постоянной нагрузкой?

Для SOHO синхронная репликация на таких объёмах не оправдана и не нужна. Для дома и семьи: снапшот, send, receive. RTO = время раскатывания снапшота, но данные доступны сразу.

При этом, с типовым MTBF приличного диска ~ 10^6, даже в массиве из 5 дисков вероятность одновременного отказа в пределах часа двух дисков из них составляет 10^−11.

Масштаб проблемы под стать автору.

Рейд6 всегда будет рейдом6, хоть mdadm, хоть zfs, хоть аппаратный рейд

Только в части распределения данных по дисками и расчета контрольных сумм. У тебя и uefi до сих пор bios. В твоей криокамере есть режим разморозки? :)

Подними тестовую ВМ и пощупай разные варианты

• rhel 10: lvm
• rhel 10: вся документация по storage
• arch wiki: zfs

LVM применяется в unix почти всю жизнь unix. И на linux уже больше 20 лет точно

С таким условием raid6 смысла не имеет

верно, поэтому я и откатился на 2 raid1

Это были 20тб диски с постоянной нагрузкой?

Это были 2x12Tb + 2x18Tb. с «небольшой нагрузкой» в виде фоновой записи 2 камер, остальная нагрузка была специально выключена.

Вообще при пересборках raid всегда стараюсь максимально понизить нагрузку на диски

Только в части распределения данных по дисками и расчета контрольных сумм.

Ну и? Что ещё то надо? После замены диска его точно так же надо пересобирать в течение больше суток и точно так же в ходе этой пересборки может случиться/обнаружиться поломка ещё где-то, нет?

А, и еще. Если ты смотришь диски большого объема, то они скорее всего будут SMR («черепичная запись»)

Когда я последний раз на них смотрел, они в принципе не годились для raid из-за непредсказуемого времени записи (запись в занятую область превращается в чтение и несколько записей). Для mdadm это аномалия, из-за чего он принимает диск за сбойный и выбрасывает из рейда

Не знаю, сделали ли какой-то workaround для SMR, или они до сих пор остались декоративными

После замены диска его точно так же надо пересобирать в течение больше суток

Нет :) Только аллоцированные экстенты. Если у тебя занято 50%, то ребилд будет только для этих 50%. Пустые сектора нет смысла синхронизировать

Не, про SMR все давно в курсе и ни для чего существенного их не берут. Не-SMR диски всё ещё производят, и даже много.

Если аллоцировано 50% то зачем было тратиться на такие большие диски, да ещё и с доп. рисками? Разве что занятый объём растёт с заметной скоростью и недавно был плановый апгрейд массива до х2 объёма.

Если ты смотришь диски большого объема, то они скорее всего будут SMR («черепичная запись»)

Не будет. Скорее всего, ТС будет смотреть на ентерпрайзные винты, а не консьюмерские.

Не-SMR диски всё ещё производят, и даже много.

Почти весь аля ентерпрайзный сектор.

Для малых дисков до 1 TB raid-5 (zraid) нормально (критичный для перехода размер вроде был где-то на ~1.4 TB, ЕМНИП).
Для средних дисков до 12 TB raid-6 (zraid2) нормально.
Для больших дисков от 12 TB raid-7 (zraid3) нормально.

Можно, конечно, найти более точные данные по накоплению ошибок, но принципиально это ничего не изменит.

PS:
Вспоминаю каждый раз про недельный ресильверинг 900 GB диска в raid-5 под нагрузкой, очень неприятно было…

А тут 20 TB, да он под нагрузкой может и месяц, а то и 2 ресильвериться… поседеешь на raid-5 и raid-6…
Может всё же zfs draid3 тут лучше? и пусть хоть полгода ресильвериться :)

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html

Это если поднимать там raid6. А если не поднимать?

Поинт был в том, что всё зависит от характера нагрузки. И бюджета.

Насколько мне известно SMR только до 8Т делали, всё что больше CMR. У меня 18Т WD по спекам CMR, по поведению на SMR тоже не похож.

Зависит от того, что там лежит

Если все 40 Tb занято тем, что нажито непосильным трудом, и все нужное, и ничего не смей трогать и выбрасывать, это печально

А если на те же 40 Тб живет десяток-другой ВМ или временные артефакты сборки, это уже совсем другое. То, что нужно - хранить с заданным уровнем raid’а. То, что не важно - держать в одной копии. и LVM, и вроде бы zfs это позволяют совмещать на одних и тех же дисках

Например, своп резервировать нет смысла. Диски с ОСью тоже. Данные - резервировать. Файлы контейнеров (кроме данных) - одна копия. volume’ы с данными - резервировать

Речь не про свапы и не про разное tmp, разумеется.

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

Это если поднимать там raid6. А если не поднимать?

Собственно об этом и тема - допустимо ли raid6 на таких дисках, или требуется бОльшая избыточность.

Короче, мы raid6 избегаем, можем себе позволить.

Хоть что там поднимай. Что raid, что zfs, что ceph это способ создания избыточности хранения для сохранения доступности при выходе из строя дисков. При выходе из строя диска избыточность деградирует. При замене диска исправным избыточность надо восстановить, что подразумевает чтения всего объема утраченной информации с других дисков. Что в свою очередь создаёт дополнительную нагрузку на эти самые другие диски. Остаётся только повышать избыточность увеличивая стоимость хранения

Разница есть и она заметная. Дело в том, что если у тебя raid6, пересинхронизация потребует пересчёта контрольных сумм, причём эти суммы потребуются как для обеспечения пересинхронизации, так и для обеспечения собственно процесса работы. Это куда больше нагрузка на диски, чем просто взять готовое с зеркала. Именно поэтому падает производительность массива при деградации.

Если этих данных нет в кэше

Не знаю как у mdadm, а для lvm сделать кэш на ssd/nvme - вообще не проблема

Хватит ли этого кэша - уже зависит от типа нагрузки

Хватит ли этого кэша - уже зависит от типа нагрузки

20 Тб данных. Конечно, не хватит :-)

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

Разница то есть, потому что подходы разные. Если вы решили вспомнить про cpu-интенсивные операции, то давайте вспомним про scrub у цеф и zfs