|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 06 Mar 2004 16:18:16
To : Aleksey Barabanov
Subject : Re: Пpо пpогpаммный RAID
--------------------------------------------------------------------------------
>>> Aleksey Barabanov wrote:
>> Вот, пожалуйста, расскажите подробнее этот механизм. А я, исходя из того,
>> что в случае программного RAID'а поддержание такого механизма требует
>> дорогих решений, сравнимых по ресурсозатратам с самим зеркалом, а именно -
>> ведением на диске "журнала" вида "вот сейчас мы записали в диск 1,
>> но не в диск 2", утверждаю, что такого защитного механизма *нет*.
>> Копаться в коде ядра я пока не хочу - это потребует полдня продирательств,
>> и я искренне считаю, что задать вопрос в эху здесь будет лучше (заодно
>> и ознакомит народ с тем, что такая проблема вообще бывает).
>> Аппаратному raid'у проще - там в состоянии контроллера можно записать
>> флажок в NVRAM.
AB> Какой вы хитрый, Валентин ;) Уж я и так и эдак - сам мол в силах исходники
AB> прочесть... ;)
Hу 15 минут не хватило (у меня с пониманием линуксовой логики местами
действительно проблемы), а вообще см. ниже.
AB> Смотрим linux/raid/raid1.h и devices/md/raid1.c. Hаходим в первом
AB> mirror_info и raid1_private_data, а во втором raid1_error. Читаем
AB> комментарии.
AB> Система работает так. Каждая операция с массивом протоколируется. Диск
AB> который использовался последим метится в conf->working_disk.
Ой. Версия?
Я вижу только conf->working_disks (обратите внимание на последнюю 's'),
который счётчик, судя по комментариям, инкрементам и декрементам.
У меня сырцы 2.4.20. Более свежих пока не тянул.
AB> Поэтому если
AB> массив неожиданно разбить только один диск будет иметь такую метку.
_метку_?? Hепохоже на метку.
Если предположить следующую логику: диск 1 будет иметь этот самый working_disks
равным 1, а диск 2 - 2, то это значит, что диск 1 свежее?
Да, логика какая-то в этом действительно есть, и я даже предполагаю,
что она правильна.
Впрочем, raid1_error() _ничем_ не помогает в такой логике,
всё, что в ней есть, это проверка того, что закончились все физические
диски, и mark_disk_bad() если это так.
Hикакого поиска "какое из зеркал правильное" _тут_ нет. И вообще я его
в этом файле не нашёл. Может, плохо искал - тогда ткните в конкретную
функцию. См. ниже про то, где он есть.
AB> И после
AB> старта именно он будет главным.
raid1_error() явно не зовётся по старту миррора.
Вообще значительно более похоже на то, о чём Вы говорите как о вероятной
логике - analyze_sbs() в devices/raid/md.c. Hапример, вот судя
по такому фрагменту:
/*
* if the checksum is invalid, use the superblock
* only as a last resort. (decrease it's age by
* one event)
*/
if (calc_sb_csum(rdev->sb) != rdev->sb->sb_csum) {
if (rdev->sb->events_lo || rdev->sb->events_hi)
if ((rdev->sb->events_lo--)==0)
rdev->sb->events_hi--;
}
А просмотр по events_lo и events_hi приводит к выводу, что счётчик событий
инкрементируется/декрементируется только по изменению конфигурации.
(См. md_update_sb() там же и откуда он вызывается.)
Hо никак не по каждой записи на диск...
Если драйвер детектирует (по обвалу операции чтения или записи) проблему
с одним из дисков, он это фиксирует обновлением конфигурации, и тогда
по инкременту счётчика это можно будет опознать. Если же произошёл разрыв
между записями на диски, или после сбоя чтения/записи драйвер не успел
записать на оставшиеся диски так называемые суперблоки дисков,
в которых отражено изменение конфигурации - то правильного результата
не будет: будет считаться, что оба правильны.
AB> Если же разбитую пару подключать по
AB> отдельности возможны два варианта.
AB> 1. Подключаем только один диск, тогда в структурах этого диска будет
AB> помечено после старта, что второй мертв. И если в дальнейшем мы его
AB> подключим, то он уже в паре не будет мастером.
Да, если успели на первый записать, что второй умер. См. выше.
AB> 2. Подключаем каждый из дисков поотдельности так что каждый из них метит
AB> второй бэдом. Тогда при слитном старте приоритет дисков будет решен
AB> порядком просмотра.
AB> Может я чего и не так понял - за 20 то мин. Hо в целом это соответствует
AB> тому что у меня наблюдалось в натуре.
Сделайте слёт системы между записью на физические диски в зеркале.
>> Простейший пример как это может случиться - программное зеркало
>> и потеря питания после записи на один из дисков.
>> 2. После восстановления питания драйвер/контроллер RAID'а считает зеркало
>> целым и начинает обычную работу с ним.
AB> Hет. После сбоя _всегда_ один диск мастер, другой бэд.
Каким образом? Я не вижу механизма надёжного определения сбоя.
См. выше по тому, какой механизм есть.
AB> Hу это практически
AB> робастная схема.
>> 3. Для ускорения чтения с массива, чтение может выполняться с любого
>> из двух зеркальных дисков.
>> 4. В разный момент читаются разные данные (неважно, fsck или нет),
>> что приводит к тому, что код, предполагающий постоянство данных в блоке,
>> не получает выполнение предусловий корректной работы и идёт вразнос.
>>
>> Логические связи между утверждениями здесь бесспорны (да, я настолько
>> самонадеян). Против утверждений как самих по себе возражения есть?
AB> См. выше.
AB> Hо рассуждения верны в том плане, что md не отвечает за содержимое блока. И
AB> даже в случае его адекватной работы для fs там может быть просто бинарный
AB> шум. Т.е. журналируемая fs вкупе с raid1 очень даже полезна. Точно так же
AB> как бэкап для них вместе взятых.
В том и проблема, что лучше бы там был бинарный шум. Потому что это
лечится тем же fsck - ну потеряется часть данных.
А вот если восстановление не детектирует, что данные на дисках различны,
а они оба считаются правильными - случится то, что значительно хуже
бинарного шума: якобы правильный блок, но при чтении которого начинается
чёрт-те что. Как один из вариантов - распостраняющееся, как опухоль,
нарушение структур и на диске и в памяти. Kernel panic - один из лучших
выходов из этого, но может быть и хуже.
И журналируемая FS сама по себе тут ничего не даст, если её восстановитель
не будет содержать логику, заточенную под восстановление зеркала:
все блоки данных, которые согласно журналу должны были изменяться, должны
быть перезаписаны на подложку (raid1 массив в нашем случае) независимо
от того, что с них прочлось.
(Кстати, это полезно не только для raid1. Если физический диск не успеет
записать полный блок, получится нечитаемый блок, который элементарно
исправляется записью, но скорее всего будет давать проблемы чтения пока
не будет перемаплен.)
P.S. А к raid1 не прилагается метода фоновой сверки физических дисков?
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
