From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux Sisyphus discussion list <sisyphus@altlinux.ru> Subject: Re: [sisyphus] boot from nvidia fakeraid Date: Mon, 9 May 2005 20:41:19 +0400 Message-ID: <20050509164119.GB2659@procyon.home> (raw) In-Reply-To: <200505091905.31759._kaa_@mail.ru> [-- Attachment #1: Type: text/plain, Size: 3635 bytes --] 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 и не такое клали ;) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-05-09 16:41 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-05-08 14:27 Alexander Kubatkin 2005-05-08 15:43 ` Mikhail Yakshin 2005-05-08 16:13 ` Alexander Kubatkin 2005-05-08 17:06 ` Sergey Vlasov 2005-05-08 17:33 ` Metalking 2005-05-08 18:22 ` Alexander Kubatkin 2005-05-09 9:45 ` [JT] " Mikhail Yakshin 2005-05-09 15:05 ` Alexander Kubatkin 2005-05-09 16:41 ` Sergey Vlasov [this message] 2005-05-09 20:34 ` [sisyphus] [JT] " Metalking 2005-05-10 9:03 ` [sisyphus] " Michael Shigorin 2005-05-14 19:52 ` [sisyphus] " Sergey Vlasov 2005-05-14 20:48 ` [sisyphus] [faq] dmraid vs md (was: boot from nvidia fakeraid) Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050509164119.GB2659@procyon.home \ --to=vsu@altlinux.ru \ --cc=sisyphus@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Sisyphus discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \ sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru public-inbox-index sisyphus Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sisyphus AGPL code for this site: git clone https://public-inbox.org/public-inbox.git