|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 06 Mar 2004 17:36:58
To : Valentin Nechayev
Subject : Re: Пpо пpогpаммный RAID
--------------------------------------------------------------------------------
Valentin Nechayev wrote:
> Ой. Версия?
> Я вижу только conf->working_disks (обратите внимание на последнюю 's'),
Моя описка. Конечно же disks. В этом то и суть. Т.е. не каждом из зеркал
есть полная структура описания массива и всех его элементов. Это и
позволяет затем его восстанавливать автоматически.
> который счётчик, судя по комментариям, инкрементам и декрементам.
> У меня сырцы 2.4.20. Более свежих пока не тянул.
2.4.21-166
> AB> Поэтому если
> AB> массив неожиданно разбить только один диск будет иметь такую метку.
>
> _метку_?? Hепохоже на метку.
> Если предположить следующую логику: диск 1 будет иметь этот самый
> working_disks равным 1, а диск 2 - 2, то это значит, что диск 1 свежее?
> Да, логика какая-то в этом действительно есть, и я даже предполагаю,
> что она правильна.
> Впрочем, raid1_error() _ничем_ не помогает в такой логике,
> всё, что в ней есть, это проверка того, что закончились все физические
> диски, и mark_disk_bad() если это так.
Именно здесь диск метится как нерабочий путем operational = 0. Т.е. для
выхода на причины надо проследить цепочку вызова. А она такова 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о никак не по каждой записи на диск...
Это верно видимо. Hо искать надо не в разделе md*, а в специфичных для raid1
текстах, imho. А потом, чексуммы подтверждают интегрити содержимого блока,
а не интерпретируют его значение.
Хотя там же далее есть более близкие фрагменты. Тем более что это блок
импортирующий символы, а значит скорее всего из raid1 вызываются именно его
элементы.
> Если драйвер детектирует (по обвалу операции чтения или записи) проблему
> с одним из дисков, он это фиксирует обновлением конфигурации, и тогда
Hе делает он этого. В этом и беда. В случае выхода из строя одного диска
очень редко происходит успешное маркирование этого диска как нерабочего.
Такое чаще происходит из-за временных отказов.
Если диск просто работал, работал и вдруг отказал, я получаю письмо с
репортом об отказе и сообщением о попытке его подключить. Если это
происходит (а такое у меня было) то как правило система все решила
автоматически.
Если же отказ фатален. И драйвер диска начинает гнать логи, то md этого уже
не может адекватно почуствовать. Система начинает безбожно тормозится из-за
того, что _никто_ и _ничто_ не имеет возможности заглянуть _ниже_ уровня
md. В таком случае происходит даже не кернел паник, а просто смерть ядра.
REM: Мне даже кажется что иногда следует /var держать не рейде, т.к. это
позволит продлить осмысленную агонию рейдовой системы и получить хоть
какие-то автономные репорты о проблеме.
Самое плохое, когда md вообще не может понять неисправность диска. Система
ребутится и зеркало из-за неадекватно работающего диска просто тормозит всю
систему. В таком случае выручает просто мануальное выключение одной части
массива. Иначе никак.
> по инкременту счётчика это можно будет опознать. Если же произошёл разрыв
> между записями на диски, или после сбоя чтения/записи драйвер не успел
> записать на оставшиеся диски так называемые суперблоки дисков,
> в которых отражено изменение конфигурации - то правильного результата
> не будет: будет считаться, что оба правильны.
Hу где-то так. Только надо мне кажется обсуждать не какой-то абстрактный
счетчик специально для этого организованный, а ту схему балансинга
операций, которая лежит в основе raid1. Т.е. главным является то что
операции записи на каждую половинку зеркала происходят последовательно, а
не одновременно.
> Сделайте слёт системы между записью на физические диски в зеркале.
Я по всякому делал. И был у меня такой случай когда система не захотела
синхронизировать зеркала. Как я предполагаю произошло повреждение того
саомго sb. Пришлось размиррорить и заново замиррорить раздел (естественно,
данные не потерялись).
> В том и проблема, что лучше бы там был бинарный шум. Потому что это
> лечится тем же fsck - ну потеряется часть данных.
> А вот если восстановление не детектирует, что данные на дисках различны,
> а они оба считаются правильными - случится то, что значительно хуже
> бинарного шума: якобы правильный блок, но при чтении которого начинается
> чёрт-те что. Как один из вариантов - распостраняющееся, как опухоль,
> нарушение структур и на диске и в памяти. Kernel panic - один из лучших
> выходов из этого, но может быть и хуже.
>
> И журналируемая FS сама по себе тут ничего не даст, если её восстановитель
> не будет содержать логику, заточенную под восстановление зеркала:
Вот тут опять же : ФС это другой уровень. Md дает блок. А fs не может видеть
ничего ниже блока выданного md.
Я понимаю, что возможно цепь фатальных совпадений. В том случае когда
произошло повреждение sb причина была именно в софтверном характере raid.
Машинка подгнила. Самба ее поднапрегла. Кернелспейс удох. И кнопку ресет
умудрились нажать не в тот момент. Следствием было повреждение самого md.
Hо обратите внимание. Повредился md, а данные вследствие атомарности
операций были уже записаны или еще не писались, с чем справилась уже ext3.
Поэтому проблема была решена переложением зеркала.
> все блоки данных, которые согласно журналу должны были изменяться, должны
> быть перезаписаны на подложку (raid1 массив в нашем случае) независимо
> от того, что с них прочлось.
> (Кстати, это полезно не только для raid1. Если физический диск не успеет
> записать полный блок, получится нечитаемый блок, который элементарно
> исправляется записью, но скорее всего будет давать проблемы чтения пока
> не будет перемаплен.)
Вот снова. Так нельзя рассуждать. Для получения вравильных выводов надо
ограничивать глубину индуктивной рекурсии. А то получается та самая
черепаха, которая бежит быстрее Геркулеса (см. апории). Md работает поверх
драйвера девайса. И проблемы работы девайса никак не регулирует и не
ощущуает. Т.е. все операции нижнего уровня для md атомарны и прозрачны.
>
> P.S. А к raid1 не прилагается метода фоновой сверки физических дисков?
Это не нужно. Т.к. система может пребывать в двух состояниях или диски
синхронны, или тот что слэйв записывается по мастеру. Это по дизайну. Или
рэйд синхронен или нет.
С другой стороны, если md# остановить, то два отдельно смонтированных диска
должны пофайлово совпадать. Hичего не мешает вставить такую проверку в
initrd.
Hо если что-то не делалось, значит не было тому оснований. Я не уверен, что
мы здесь просто так просмотрев исходники все правильно поймем. Hо я уже
несколько лет экспуатирую зеркала на линуксе и _очень_ доволен. Хотя и было
всякое.
--
Bye.
Aleksey Barabanov <alekseybb at mail.ru>
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
