[sisyphus] boot from nvidia fakeraid
Sergey Vlasov
=?iso-8859-1?q?vsu_=CE=C1_altlinux=2Eru?=
Пн Май 9 20:41:19 MSD 2005
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>
Подробная информация о списке рассылки Sisyphus