[sisyphus] boot from nvidia fakeraid

[Sergey Vlasov]

On Mon, May 09, 2005 at 07:05:25PM +0400, Alexander Kubatkin wrote:
> Вобщем суть вопроса... когда ожидать обновленный mknitrd? :):)

Ну раз есть на чём тестировать - собирайте, шлите _проверенные_ патчи.
Пока что все известные мне попытки использовать dmraid сопровождались
борьбой с разнообразными глюками (в том числе и в самом dmraid -
сейчас, правда, их вроде бы починили, но одно время с поддержкой
формата promise было плохо).

> я узнал, что dmraid это не хорошо (нет проблем.. допускаю), ввиду закрытых 
> спецификаций(? не смотря на то, что dmraid идет в исходниках и по ним видно 
> чем он занимается...

Дело не в том, что видно, чем он занимается.  Дело в том, что не
видно, чем занимается BIOS и родные драйверы этого FakeRAID -
следовательно, непонятно, что делать с массивом при сбоях.

Т.е., сам по себе dmraid может делать всё совершенно правильно, но
этого мало - необходимо ещё, чтобы то, что он делает, соответствовало
тому, что делает BIOS контроллера.

> да еще тот факт, что он построен на ataraid, который уже 
> пожил и показал, что он работоспособен.....)

Именно что неработоспособен.  Как раз в случае RAID1 при возникновении
проблем с одним из дисков.  И об этом в рассылках неоднократно писали.

Основная проблема с поддержкой подобных RAID1 состоит в том, что для
действительно надёжной работы RAID1 требуется уметь при необходимости
_модифицировать_ метаданные массива.  В случае RAID0 такой
необходимости нет, поскольку там не стоит вопрос об обработке сбоев
дисков и поддержании синхронизации.

Хотя есть вероятность, что разработчики этого FakeRAID просто забили
на надёжность в подобных случаях.  Можно попробовать провести такой
тест: в Windows запустить запись на диск большого файла, и в процессе
этой записи нажать Reset.  Правильно сделанный RAID1 после этого
должен пересинхронизироваться (возможно, это будет делаться в фоновом
режиме, но всё равно будет заметно по загрузке дисков), поскольку в
такой ситуации вполне возможно, что какие-то сектора успели записаться
только на один диск, а на другом остались старые данные.  Если
пересинхронизации не будет, в дальнейшем возможны загадочные глюки
(поскольку при чтении таких секторов, пока они не будут перезаписаны,
будут возвращаться то одни, то другие данные, в зависимости от того,
какой из дисков был в этот момент свободен).

Драйвер md в ядрах 2.6.x обрабатывает подобную ситуацию следующим
образом: в суперблоке есть флаг in_sync; перед первой записью на
"чистый" массив сначала записываются суперблоки со сброшенным флагом
in_sync; если в течение 20 мс не было записей, записываются суперблоки
с установленным флагом in_sync.  В 2.4.x драйвер md несколько похуже -
там нет такого таймера, поэтому пересинхронизация после сбоя
запускается в любом случае, даже если на самом деле в ней нет
необходимости.

> и ведь никого же не смущает использование закрытых nvidia драйверов для 
> видеокарт? не... пусть смущает, но ведь пользуются все? ... уже слышу 
> возражения - "так то производитель клепает, а тут сторонняя поделка, от 
> которой не знаешь чего ожидать"  ... а не все ли равно, если оно работает?

Последствия рухнувшего RAID всё-таки несколько другие (хотя, с другой
стороны, кривой драйвер в ядре может тоже испортить всё так, что потом
концов не найдёшь - именно поэтому багрепорты с Tainted: P быстро
отправляются в /dev/null).

> мы в сизифе или где?

Сизиф в конце концов превращается в дистрибутивы...

> я могу быть тестером этой поделки, типа если рухнет, то сообщу, что
> рухнуло, как и предполагали :)

...хотя в contrib и не такое клали ;)
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20050509/b5cf1284/attachment-0003.bin>