The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Доступны два режима работы форума: "Раскрыть нити" и "Свернуть нити".
. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +1 +/
Сообщение от Аноним (-), 30-Май-23, 01:42 
>> не знают какая копия верная.
> Это как ? Я не беру в качестве примера ниже 5 рэйд.

Ну вот так. RAID1: читаем обе копии по одному смещению. Опа, они разные! И чего теперь? Мы знаем что в этом месте проблема, но понятия не имеем какая из копий правильная. В случае чексум данных все упрощается: если есть копия с неверной и копия с верной чексумой, ок, вычислили гонщика. Так можно определить проблемный накопитель/контроллер/канал/провод...

> Там же Рида-Соломона коды корректировки,

В именно RAID 5 так то всего лишь XOR. Если взять 3 девайса, и 2 блока, b1 и b2, это пишется как b1, b2, b1^b2 (XOR b1 с b2). XOR интересен тем что при вылете b1 или b2 он восстанавливается всего лишь XOR второго блока с parity. Это просто, быстро, оверхед 1/3 при 3 девайсах, меньше если девайсов больше, но - переживает только отказ 1 девайса. Если нужно больше, это уже RAID6 и вот там дополнительный parity уже будет рид соломоном. Это позволяет починить вылет и 2 устройств за раз.

> если код не совпадает значит диск дегрейд...

Для RAID5 это не сработает: мы видим что b1 ^ b2 != parity но понятия не имеем который из них неверен. Для RAID6 это уже можно попробовать. Но это ценой 2 полноразмерных блоков четности. Т.е. минимум 4 стоража, при этом оверхед 50%. Как RAID1 только тормознее и хуже. В случае например btrfs на RAID1 (и даже DUP на 1 стораже) видит какая из копий неверная и фиксит из правильной. Для большего числа дисков RAID6 может уже иметь смысл а RAID5 становится опаснее т.к. за время ребилда не должен скончаться ни 1 стораж.

У btrfs там кстати плюс есть: знает что аллоцировано а что нет. И на полупустом пуле оно ребилдить будет сильно меньше - только реально занятые блоки, сколько уж их там на проблемном девайсе было. В зависимости от - так ребилд может быть сильно резвее.

Это же касается изъятия/замены девайсов, scrub, смены схемы хранения, уменьшения ФС и т.п.. Это и есть смысл терпеть те неудобства. Безгеморное управление, можно решения переиграть, они не высечены в камне. Не нравится тот уровень RAID - конвертим в другой, лишь бы места в новом фоормате хватало для фактически записанных данных. Можно даже "мягкую" конверсию: старые блоки останутся как есть, а новые с новой схемой. Вполне валидно для той механики. А на обычном RAID такие вещи лучше даже не пытаться... как угодно но это next gen технологий хранения.

> Так уже есть рэйды где 3 диска может развалиться и данные не потеряться.

Ну да. Triple parity raid. Правда, взамен придется хранить ТРИ набора блоков parity и это не менее чем 5 девайсов, иначе бессмысленно. В принципе соотношение DATA/FEC ничем таким не ограничено, даже в RAID1 если сделать 10 копий блока то до 9 можно потерять. Проблема только в том что эффективность схемы == 1/10. Нужно ли оно такое? Врядли. Потому что не спасает от сбоев проца, рам и проч например, все 10 могут оказаться испорченными и оверхед того не стоил.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews, 26-Май-23, 23:36  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру