Re: md raid1 testing issue
В Пнд, 07/04/2008 в 08:56 +0400, DamirX пишет: В Птн, 04/04/2008 в 15:24 +0300, Покотиленко Костик пишет: В Птн, 04/04/2008 в 13:26 +0700, Andrey Lyubimets пишет: DamirX пишет: В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. Существует мнение, что _одинаковые диски_ умирают в один день. Сам видел. предрассудки! я вот видел, как в один день умирали разные диски. Считаю очень полезным новый диск погонять включённым 1-3 дня (ещё лучше если нагрузить его какой-нибудь тестовой програмкой) Что-то мне подсказывает, что и то и другое частные и редкие случаи, на статистику не влияющие, и, тем самым, в расчёте вероятности выхода из строя принимать участия не должны. Хотя, есть для обоих вариантов 100%-е ситуации. Для первого - бракованная партия, для второго потолок упавший на сервер. Счастье на мою голову, что эти два винта не стояли в одном зеркале. А то б отмазываваться пришлось примерно так-же. пришлось бы вспомнить и про бракованную серию, и про вероятности, и про экономическую ситуацию в корее. А если бы еще и резерные копии лежали на таком-же, вышедшем из строя винте, то ваще звиздец! Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. кем рекомендуется? Вот-вот, кем? теми кто столкнулся с невероятным с точки зрения теории верояности выходом из строя обоих винтов в зеркале в один день. Например мной. С кармой проблемы :) За смартом смотреть полезно, по статистике google, в ~50% случаев внезапную смерть винта можно предвидеть по его параметрам. Я в последнее время, перед установкой винта в сервер, сохраняю параметры смарт, забиваю винт нулями, потом полная проверка, потом сравниваю параметры смарт с сохранёнными. Тут сразу видно насколько винт проблемный будет. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Maxim Kudelya wrote: alex kuklin wrote: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Юный падаван хочет как у настоящих джедаев, а у настояших джедаев на raid-1 из двух дисков приходится четыре одинаковых диска, два в рейде, один в hot spare и один на полочке в солидоле. Особенно это актуально, если собирать raid из дисков, а не разделов. На практике, чаще собирают raid из разделов на двух дисках, потом один диск вылетает, запасного нет, админ быстрым оленем скачет в магазин, покупает диск такого же объема (если еще такие диски выпускают) или больший диск, а так как довольно часто даже у дисков одинакового объема, не говоря уже про большие диски, различается геометрия, то начинается ковыряние fdisk'ом и создание вручную таблицы разделов, потом еще синхронизация. Все это только добавляет удовольствия и скорости в столь нервный процесс. И кому нужны эти все проблемы? Даже без hot-spare, достать диск из шкафа, вставить в сервер и сделать sfdisk -d /dev/sda | sfdisk /dev/sdb куда проще и правильнее на мой взгляд. Все правильно. Лучше держать запасную железку. Но. Если ее нет, то это не катастрофа, т.к. можно купить новую, не меньшего объема. dixi. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
alex kuklin wrote: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Юный падаван хочет как у настоящих джедаев, а у настояших джедаев на raid-1 из двух дисков приходится четыре одинаковых диска, два в рейде, один в hot spare и один на полочке в солидоле. Особенно это актуально, если собирать raid из дисков, а не разделов. На практике, чаще собирают raid из разделов на двух дисках, потом один диск вылетает, запасного нет, админ быстрым оленем скачет в магазин, покупает диск такого же объема (если еще такие диски выпускают) или больший диск, а так как довольно часто даже у дисков одинакового объема, не говоря уже про большие диски, различается геометрия, то начинается ковыряние fdisk'ом и создание вручную таблицы разделов, потом еще синхронизация. Все это только добавляет удовольствия и скорости в столь нервный процесс. И кому нужны эти все проблемы? Даже без hot-spare, достать диск из шкафа, вставить в сервер и сделать sfdisk -d /dev/sda | sfdisk /dev/sdb куда проще и правильнее на мой взгляд. -- maxym -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Maxim Kudelya wrote: alex kuklin wrote: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Юный падаван хочет как у настоящих джедаев, а у настояших джедаев на raid-1 из двух дисков приходится четыре одинаковых диска, два в рейде, один в hot spare и один на полочке в солидоле. Особенно это актуально, если собирать raid из дисков, а не разделов. На практике, чаще собирают raid из разделов на двух дисках, потом один диск вылетает, запасного нет, админ быстрым оленем скачет в магазин, покупает диск такого же объема (если еще такие диски выпускают) или больший диск, а так как довольно часто даже у дисков одинакового объема, не говоря уже про большие диски, различается геометрия, то начинается ковыряние fdisk'ом и создание вручную таблицы разделов, потом еще синхронизация. Все это только добавляет удовольствия и скорости в столь нервный процесс. И кому нужны эти все проблемы? Даже без hot-spare, достать диск из шкафа, вставить в сервер и сделать sfdisk -d /dev/sda | sfdisk /dev/sdb куда проще и правильнее на мой взгляд. Если уж на то пошло, то правильнее иметь кластер (винты в рейде само собой). Также вы бы поставили на свой личный сервер (купленный за свои бабки) три избыточных винта? (два в рейде, хотспаре + солидол) и это все чудо на колокейшн ? Да, а если винты sas\scsi ? не 5копеек поди в солидоле держать ;) Вообщем, все в меру хорошо, и для своих задач. PS. систему, в которой нельзя\очень сложно сделайть рейд1 на разных дисках (новый диск не меньший) я бы назвал не маштабируемой. В крайнем случае, dump\restore -- maxym -- Wbr, SK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Пнд, 07/04/2008 в 11:03 +0300, Покотиленко Костик пишет: С кармой проблемы :) За смартом смотреть полезно, по статистике google, в ~50% случаев внезапную смерть винта можно предвидеть по его параметрам. я вобщем-то не утверждаю, что мод подход единственно правильный. Я всего-лишь хочу предостеречь об одной из возможных проблемм, которую можно достаточно просто обойти не используя идентичных винтов. Этот предрассудок подтверждается жизненным опытом, пусть и небогатым. Да и что тут вообще обсуждать? в любом случает применение одного лишь зеркала - это не способ построения систем высокой степени готовности, это - лишь один из приёмов. ЗЫ: на карму надейся, а сам не плошай -- DamirX [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Пнд, 07/04/2008 в 12:48 +0400, alex kuklin пишет: Maxim Kudelya wrote: alex kuklin wrote: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Юный падаван хочет как у настоящих джедаев, а у настояших джедаев на raid-1 из двух дисков приходится четыре одинаковых диска, два в рейде, один в hot spare и один на полочке в солидоле. Особенно это актуально, если собирать raid из дисков, а не разделов. На практике, чаще собирают raid из разделов на двух дисках, потом один диск вылетает, запасного нет, админ быстрым оленем скачет в магазин, покупает диск такого же объема (если еще такие диски выпускают) или больший диск, а так как довольно часто даже у дисков одинакового объема, не говоря уже про большие диски, различается геометрия, то начинается ковыряние fdisk'ом и создание вручную таблицы разделов, потом еще синхронизация. Все это только добавляет удовольствия и скорости в столь нервный процесс. И кому нужны эти все проблемы? Даже без hot-spare, достать диск из шкафа, вставить в сервер и сделать sfdisk -d /dev/sda | sfdisk /dev/sdb куда проще и правильнее на мой взгляд. Все правильно. Лучше держать запасную железку. Но. Если ее нет, то это не катастрофа, т.к. можно купить новую, не меньшего объема. dixi. Из этого всего самая полезная фича - это hotspare. А винты в серваках в организации где винты хоть изредка покупаются, хотябы для профилактики раз в 3-5 лет желательно менять. Тем самым делая периодическую отсрочку вероятным внештатным ситуациям, ибо чем дольше работает устройство тем выше становится вероятность его выхода из строя. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
DamirX пишет: Да и что тут вообще обсуждать? в любом случает применение одного лишь зеркала - это не способ построения систем высокой степени готовности, это - лишь один из приёмов. ЗЫ: на карму надейся, а сам не плошай (делай вовремя бэкапы) -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
DamirX пишет: Хотя, есть для обоих вариантов 100%-е ситуации. Для первого - бракованная партия, для второго потолок упавший на сервер. плюс проблемы с электропитанием, с выходом из строя железа, которое потянет за собой и винчестеры (тот же блок питания или контроллер) Я к тому, что на самом деле вероятность второго случая много больше первого. Поэтому смысла специально покупать винчестеры разных производителей для зеркала нет. Мне кажется это очевидно. Счастье на мою голову, что эти два винта не стояли в одном зеркале. А то б отмазываваться пришлось примерно так-же. пришлось бы вспомнить и про бракованную серию, и про вероятности, и про экономическую ситуацию в корее. А если бы еще и резерные копии лежали на таком-же, вышедшем из строя винте, то ваще звиздец! Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. А, ты ещё расскажи это IBM-у или, например, HP (не к ночи буде он помянут :-) кем рекомендуется? Вот-вот, кем? теми кто столкнулся с невероятным с точки зрения теории верояности выходом из строя обоих винтов в зеркале в один день. Например мной. а ты уверен, что за день до того один из них не был уже трупом? и почему ты думаешь , что будь у тебя два винчестера разных производителей их не постигла бы подобная участь? -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Sun, 6 Apr 2008 02:53:09 +0400 Pavel Ammosov [EMAIL PROTECTED] wrote: On Fri, Apr 04, 2008 at 03:48:39PM +0400, Alexander GQ Gerasiov wrote: On Thu, Apr 03, 2008 at 05:20:26PM +0400, Alexander GQ Gerasiov wrote: принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно Можно локальные диски внести в блеклист для multipathd. Лучше бы, конечно, у него был whitelist, но и так сносно. А как? По devnode? Некузяво получится: если один из локальных дисков вылетит, то при ребуте диск, доступный через HBA может получить егойное имя. Я делал, но забыл. Надо в multipathd.conf убрать -g из вызова scsi_id, а в /etc/scsi_id.config добавить vendor=DGC, model=RAID 10, options=-g. Тогда multipathd позовет scsi_id для локального диска, тот увидит что это не Сlariion и ничего multipathd не скажет. multipathd не будет делать map. О! До меня дошло, что можно локальные диски по VENDOR=ATA блэклистить. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Пнд, 07/04/2008 в 17:35 +0700, Andrey Lyubimets пишет: DamirX пишет: Хотя, есть для обоих вариантов 100%-е ситуации. Для первого - бракованная партия, для второго потолок упавший на сервер. плюс проблемы с электропитанием, с выходом из строя железа, которое потянет за собой и винчестеры (тот же блок питания или контроллер) Я к тому, что на самом деле вероятность второго случая много больше первого. Поэтому смысла специально покупать винчестеры разных производителей для зеркала нет. Мне кажется это очевидно. Всё это конечно спорно. Хотя одно очевидно - одновременный выход из строя нескольких устройств в пределе нескольких часов - это результат внешнего воздействия с вероятностью очень близкой к 100% (температура, влажность, питание, вибрация, электро-магнитные поля, ...). Счастье на мою голову, что эти два винта не стояли в одном зеркале. А то б отмазываваться пришлось примерно так-же. пришлось бы вспомнить и про бракованную серию, и про вероятности, и про экономическую ситуацию в корее. А если бы еще и резерные копии лежали на таком-же, вышедшем из строя винте, то ваще звиздец! Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. А, ты ещё расскажи это IBM-у или, например, HP (не к ночи буде он помянут :-) кем рекомендуется? Вот-вот, кем? теми кто столкнулся с невероятным с точки зрения теории верояности выходом из строя обоих винтов в зеркале в один день. Например мной. а ты уверен, что за день до того один из них не был уже трупом? и почему ты думаешь , что будь у тебя два винчестера разных производителей их не постигла бы подобная участь? Я так понимаю, что там даже за смартом не наблюдали, так что тут нет материала для анализа, виноват барабашка. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 15:24 +0300, Покотиленко Костик пишет: В Птн, 04/04/2008 в 13:26 +0700, Andrey Lyubimets пишет: DamirX пишет: В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. Существует мнение, что _одинаковые диски_ умирают в один день. Сам видел. предрассудки! я вот видел, как в один день умирали разные диски. Считаю очень полезным новый диск погонять включённым 1-3 дня (ещё лучше если нагрузить его какой-нибудь тестовой програмкой) Что-то мне подсказывает, что и то и другое частные и редкие случаи, на статистику не влияющие, и, тем самым, в расчёте вероятности выхода из строя принимать участия не должны. Хотя, есть для обоих вариантов 100%-е ситуации. Для первого - бракованная партия, для второго потолок упавший на сервер. Счастье на мою голову, что эти два винта не стояли в одном зеркале. А то б отмазываваться пришлось примерно так-же. пришлось бы вспомнить и про бракованную серию, и про вероятности, и про экономическую ситуацию в корее. А если бы еще и резерные копии лежали на таком-же, вышедшем из строя винте, то ваще звиздец! Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. кем рекомендуется? Вот-вот, кем? теми кто столкнулся с невероятным с точки зрения теории верояности выходом из строя обоих винтов в зеркале в один день. Например мной. -- DamirX [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
On Fri, Apr 04, 2008 at 03:48:39PM +0400, Alexander GQ Gerasiov wrote: On Thu, Apr 03, 2008 at 05:20:26PM +0400, Alexander GQ Gerasiov wrote: принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно Можно локальные диски внести в блеклист для multipathd. Лучше бы, конечно, у него был whitelist, но и так сносно. А как? По devnode? Некузяво получится: если один из локальных дисков вылетит, то при ребуте диск, доступный через HBA может получить егойное имя. Я делал, но забыл. Надо в multipathd.conf убрать -g из вызова scsi_id, а в /etc/scsi_id.config добавить vendor=DGC, model=RAID 10, options=-g. Тогда multipathd позовет scsi_id для локального диска, тот увидит что это не Сlariion и ничего multipathd не скажет. multipathd не будет делать map. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
DamirX пишет: В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. Существует мнение, что _одинаковые диски_ умирают в один день. Сам видел. предрассудки! я вот видел, как в один день умирали разные диски. Считаю очень полезным новый диск погонять включённым 1-3 дня (ещё лучше если нагрузить его какой-нибудь тестовой програмкой) Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. кем рекомендуется? -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
alex kuklin пишет: Andrey Lyubimets wrote: Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать Swap на зеркале будет медленнее, чем на разделе. Если нужна сохранность данных, то необязательно. Если нужна стабильность работы - то да, но вообще, при нынешних ценах на память, лучше больше памяти поставить. При нестабильной работе операционки не стоить и мечтать о сохранности данных, не так ли? -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Andrey Lyubimets wrote: alex kuklin пишет: Andrey Lyubimets wrote: Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать Swap на зеркале будет медленнее, чем на разделе. Если нужна сохранность данных, то необязательно. Если нужна стабильность работы - то да, но вообще, при нынешних ценах на память, лучше больше памяти поставить. При нестабильной работе операционки не стоить и мечтать о сохранности данных, не так ли? В случае падения диска, на котором находится swap, будет наблюдаться разовое падение (быстрая смерть) системы, а не нестабильная работа (длительная агония). Это не та ситуация, когда глючит память и в результате ядро может разнести в клочья файловую систему. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
alex kuklin пишет: Andrey Lyubimets wrote: alex kuklin пишет: Andrey Lyubimets wrote: Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать Swap на зеркале будет медленнее, чем на разделе. Если нужна сохранность данных, то необязательно. Если нужна стабильность работы - то да, но вообще, при нынешних ценах на память, лучше больше памяти поставить. При нестабильной работе операционки не стоить и мечтать о сохранности данных, не так ли? В случае падения диска, на котором находится swap, будет наблюдаться разовое падение (быстрая смерть) системы, а не нестабильная работа (длительная агония). Это не та ситуация, когда глючит память и в результате ядро может разнести в клочья файловую систему. Выигрышь в скорости swap-а копеешный (если он есть на самом деле), но в случае своп на зеркале - вылетел диск - система не умирает быстрой смертью, но доживёт до понедельника, дождется замены диска. Для меня это гораздо больший выигрышь. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: Читай внимательно комментарии в этом файле и поймешь, что там безопасно править, а что потеряется при grub-update. А по мимо этого если Вы объясните зачем править menu.lst, возможно Вам расскажут как этого не делать... править, чтобы указать правильный root для кернела. Ключевой момент /dev/md3 Разме можно этого как-то не делать? title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd1) root(hd1,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd0) root(hd0,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault -- Wbr, SK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Sergej Kandyla wrote: Покотиленко Костик wrote: Читай внимательно комментарии в этом файле и поймешь, что там безопасно править, а что потеряется при grub-update. А по мимо этого если Вы объясните зачем править menu.lst, возможно Вам расскажут как этого не делать... править, чтобы указать правильный root для кернела. Ключевой момент /dev/md3 Разме можно этого как-то не делать? title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd1) root(hd1,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd0) root(hd0,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault ## DO NOT UNCOMMENT THEM, Just edit them to your needs ## ## Start Default Options ## ## default kernel options ## default kernel options for automagic boot options ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro # kopt=root=/dev/sda1 ro quiet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В сообщении от 3 апреля 2008 18:50 Покотиленко Костик написал(a): Только mdadm'у надо не забыть сказать - сканируй все винты и ищи свои суперблоки! Да, был(есть?) такой ioctl. А то по умолчанию по моему не так. Правда в initramfs кроется. Кто копал, напишите что его скриптах в плане md. -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Знаешь, когда я первый раз коснулся этого вопроса, мне было непонятно, как на серверной операционке до сих пор нет отлаженного механизма hot-замены, в том числе дисков. Так есть же отлаженный механизм. Только вот выделяется новое устройство, если старое не корректно удалено. А если ты сам хочешь вынуть - отключи устройство сам (отмонтируй, удали из рейда etc) и будет все кошерно, с освобождением буквы. Что-то у меня не вяжется отлаженный механизм с если старое не корректно удалено... Ну почему же? Если не выполнить процедуру корректного удаления устройства из системы, то устройство остаётся включённым во всевозможные структуры данных подсистем, которые его использовали. И это скорее правильно, чем нет - ну хотя бы потому, что упрощает анализ происшедшего. При этом система на всех уровнях готова к отказу устройства - то есть должным образом обрабатывает ситуацию, когда включённое в структуры данных устройство более не способно работать по назначению. В этом смысле механизм действительно отлажен. А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
On Thu, Apr 03, 2008 at 05:20:26PM +0400, Alexander GQ Gerasiov wrote: принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно Можно локальные диски внести в блеклист для multipathd. Лучше бы, конечно, у него был whitelist, но и так сносно. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Fri, 4 Apr 2008 14:41:00 +0400 Pavel Ammosov [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2008 at 05:20:26PM +0400, Alexander GQ Gerasiov wrote: принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно Можно локальные диски внести в блеклист для multipathd. Лучше бы, конечно, у него был whitelist, но и так сносно. А как? По devnode? Некузяво получится: если один из локальных дисков вылетит, то при ребуте диск, доступный через HBA может получить егойное имя. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 11:59 +0400, Nikita V. Youshchenko пишет: Знаешь, когда я первый раз коснулся этого вопроса, мне было непонятно, как на серверной операционке до сих пор нет отлаженного механизма hot-замены, в том числе дисков. Так есть же отлаженный механизм. Только вот выделяется новое устройство, если старое не корректно удалено. А если ты сам хочешь вынуть - отключи устройство сам (отмонтируй, удали из рейда etc) и будет все кошерно, с освобождением буквы. Что-то у меня не вяжется отлаженный механизм с если старое не корректно удалено... Ну почему же? Если не выполнить процедуру корректного удаления устройства из системы, то устройство остаётся включённым во всевозможные структуры данных подсистем, которые его использовали. И это скорее правильно, чем нет - ну хотя бы потому, что упрощает анализ происшедшего. При этом система на всех уровнях готова к отказу устройства - то есть должным образом обрабатывает ситуацию, когда включённое в структуры данных устройство более не способно работать по назначению. В этом смысле механизм действительно отлажен. А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Это всё понятно. Про отлаженный механизм: возьмём CD/DVD приводы, и посмотрим как там сделано: лично у меня: вставляешь диск - он видится, отсоединяешь программно - можешь вытащить физически, хочешь вытащить физически (нажимая на кнопку) - диск при возможности отсоединяется и извлекается. Вот это отлаженный механизм. Я конечно понимаю, что устройство со сменным носителем это не сменное устройство. Но, если контроллер и дрова поддерживают горячую замену, что мешает удалить устройство из системы при его извлечении физически, я никак не пойму. Объяснить это я могу только недоработкой соответствующей подсистемы. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: Это всё понятно. Про отлаженный механизм: возьмём CD/DVD приводы, и посмотрим как там сделано: лично у меня: вставляешь диск - он видится, отсоединяешь программно - можешь вытащить физически, хочешь вытащить физически (нажимая на кнопку) - диск при возможности отсоединяется и извлекается. Вот это отлаженный механизм. Я конечно понимаю, что устройство со сменным носителем это не сменное устройство. Но, если контроллер и дрова поддерживают горячую замену, что мешает удалить устройство из системы при его извлечении физически, я никак не пойму. Объяснить это я могу только недоработкой соответствующей подсистемы. А вот теперь посмотри. При нажатии на eject на cd/dvd - контроллер получает сигнал, который потом ловится HAL-ом, и производится отмонтирование. Если на ходу выдернуть флешку, а файлы на ней будут использоваться не только пользователем, то выгребешь те же радости, на самом деле. Там есть над чем поработать, безусловно, операции по замене дисков можно и нужно заскриптовать. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 11:44 +0400, Andrey Nikitin пишет: В сообщении от 3 апреля 2008 18:50 Покотиленко Костик написал(a): Только mdadm'у надо не забыть сказать - сканируй все винты и ищи свои суперблоки! Да, был(есть?) такой ioctl. При чём тут ioctl? # man 5 mdadm.conf /DEVICE DEVICE /dev/hda* /dev/hdc* DEV/dev/sd* DEVICE /dev/discs/disc*/disc DEVICE partitions А то по умолчанию по моему не так. Правда в initramfs кроется. Кто копал, напишите что его скриптах в плане md. Помню, при настройке пакета mdadm, спрашивается какие массивы требуются для поднятия корня. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В сообщении от 4 апреля 2008 15:57 Покотиленко Костик написал(a): При чём тут ioctl? А как ещё mdadm-у с md kernel module общаться? -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 11:34 +0400, alex kuklin пишет: Sergej Kandyla wrote: Покотиленко Костик wrote: Читай внимательно комментарии в этом файле и поймешь, что там безопасно править, а что потеряется при grub-update. А по мимо этого если Вы объясните зачем править menu.lst, возможно Вам расскажут как этого не делать... править, чтобы указать правильный root для кернела. Ключевой момент /dev/md3 Разме можно этого как-то не делать? title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd1) root(hd1,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault title Debian GNU/Linux, kernel 2.6.18-4-686 RAID (hd0) root(hd0,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro initrd /initrd.img-2.6.18-4-686 savedefault ## DO NOT UNCOMMENT THEM, Just edit them to your needs ## ## Start Default Options ## ## default kernel options ## default kernel options for automagic boot options ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro # kopt=root=/dev/sda1 ro quiet Пальцем в небо, но попал. Видишь, в комментариях сколько опций прячут. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 09:57 +0400, alex kuklin пишет: Andrey Lyubimets wrote: Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать Swap на зеркале будет медленнее, чем на разделе. Если нужна сохранность данных, то необязательно. Если нужна стабильность работы - то да, но вообще, при нынешних ценах на память, лучше больше памяти поставить. Своп нужен, но если он понадобится, значит кто-то где-то просчитался :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 15:57 +0400, alex kuklin пишет: Покотиленко Костик wrote: Это всё понятно. Про отлаженный механизм: возьмём CD/DVD приводы, и посмотрим как там сделано: лично у меня: вставляешь диск - он видится, отсоединяешь программно - можешь вытащить физически, хочешь вытащить физически (нажимая на кнопку) - диск при возможности отсоединяется и извлекается. Вот это отлаженный механизм. Я конечно понимаю, что устройство со сменным носителем это не сменное устройство. Но, если контроллер и дрова поддерживают горячую замену, что мешает удалить устройство из системы при его извлечении физически, я никак не пойму. Объяснить это я могу только недоработкой соответствующей подсистемы. А вот теперь посмотри. При нажатии на eject на cd/dvd - контроллер получает сигнал, который потом ловится HAL-ом, и производится отмонтирование. Если на ходу выдернуть флешку, а файлы на ней будут использоваться не только пользователем, то выгребешь те же радости, на самом деле. Там есть над чем поработать, безусловно, операции по замене дисков можно и нужно заскриптовать. Это да, но если диск уже вытащили, зачем устройство в системе держать? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 16:01 +0400, Andrey Nikitin пишет: В сообщении от 4 апреля 2008 15:57 Покотиленко Костик написал(a): При чём тут ioctl? А как ещё mdadm-у с md kernel module общаться? Ааа, ты про это :). Я про опции говорил :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: В Птн, 04/04/2008 в 15:57 +0400, alex kuklin пишет: Покотиленко Костик wrote: Это всё понятно. Про отлаженный механизм: возьмём CD/DVD приводы, и посмотрим как там сделано: лично у меня: вставляешь диск - он видится, отсоединяешь программно - можешь вытащить физически, хочешь вытащить физически (нажимая на кнопку) - диск при возможности отсоединяется и извлекается. Вот это отлаженный механизм. Я конечно понимаю, что устройство со сменным носителем это не сменное устройство. Но, если контроллер и дрова поддерживают горячую замену, что мешает удалить устройство из системы при его извлечении физически, я никак не пойму. Объяснить это я могу только недоработкой соответствующей подсистемы. А вот теперь посмотри. При нажатии на eject на cd/dvd - контроллер получает сигнал, который потом ловится HAL-ом, и производится отмонтирование. Если на ходу выдернуть флешку, а файлы на ней будут использоваться не только пользователем, то выгребешь те же радости, на самом деле. Там есть над чем поработать, безусловно, операции по замене дисков можно и нужно заскриптовать. Это да, но если диск уже вытащили, зачем устройство в системе держать? Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если освободить устройство не удалось, выброса не происходит. Попробуй открыть файл на cd из консоли и потом его вынуть. -- Alex Kuklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 13:26 +0700, Andrey Lyubimets пишет: DamirX пишет: В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. Существует мнение, что _одинаковые диски_ умирают в один день. Сам видел. предрассудки! я вот видел, как в один день умирали разные диски. Считаю очень полезным новый диск погонять включённым 1-3 дня (ещё лучше если нагрузить его какой-нибудь тестовой програмкой) Что-то мне подсказывает, что и то и другое частные и редкие случаи, на статистику не влияющие, и, тем самым, в расчёте вероятности выхода из строя принимать участия не должны. Хотя, есть для обоих вариантов 100%-е ситуации. Для первого - бракованная партия, для второго потолок упавший на сервер. Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. кем рекомендуется? Вот-вот, кем? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 16:22 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 15:57 +0400, alex kuklin пишет: Покотиленко Костик wrote: Это всё понятно. Про отлаженный механизм: возьмём CD/DVD приводы, и посмотрим как там сделано: лично у меня: вставляешь диск - он видится, отсоединяешь программно - можешь вытащить физически, хочешь вытащить физически (нажимая на кнопку) - диск при возможности отсоединяется и извлекается. Вот это отлаженный механизм. Я конечно понимаю, что устройство со сменным носителем это не сменное устройство. Но, если контроллер и дрова поддерживают горячую замену, что мешает удалить устройство из системы при его извлечении физически, я никак не пойму. Объяснить это я могу только недоработкой соответствующей подсистемы. А вот теперь посмотри. При нажатии на eject на cd/dvd - контроллер получает сигнал, который потом ловится HAL-ом, и производится отмонтирование. Если на ходу выдернуть флешку, а файлы на ней будут использоваться не только пользователем, то выгребешь те же радости, на самом деле. Там есть над чем поработать, безусловно, операции по замене дисков можно и нужно заскриптовать. Это да, но если диск уже вытащили, зачем устройство в системе держать? Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если освободить устройство не удалось, выброса не происходит. Попробуй открыть файл на cd из консоли и потом его вынуть. Это ты говорить о причинах, которые мешают отсоединить том программно. А вот если устройства уже нет, а в системе оно есть, значит, либо система не узнала о его извлечении (нет поддержки контроллера и дров), либо она вообще не умеет отлавливать такие события. Кстати, это очень интересный вопрос. Может ли ядро отлавливать извлечение устройства и что для этого надо? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. Наклейки с серийным номером винта - решают, однозначно. Кстати, на 24-винтовой банке имени etegro, которая сделана на контроллере areca, идентификация дисков производится именно синтетической нагрузкой на винты. Отдельно замечу, что этот метод не очень помогает, кстати, в случае тупой корзины, без лампочки. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 17:56 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. Наклейки с серийным номером винта - решают, однозначно. Кстати, на 24-винтовой банке имени etegro, которая сделана на контроллере areca, идентификация дисков производится именно синтетической нагрузкой на винты. Отдельно замечу, что этот метод не очень помогает, кстати, в случае тупой корзины, без лампочки. И тут получается замкнутый круг: Чтобы вытащить винт надо узнать его серийник, а чтобы узнать серийник надо вытащить винт :). Добавим сюда случаи, где винты стоят не в корзинах и лампочка одна на всех :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 17:14 +0300, Покотиленко Костик пишет: В Птн, 04/04/2008 в 17:56 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. Наклейки с серийным номером винта - решают, однозначно. Кстати, на 24-винтовой банке имени etegro, которая сделана на контроллере areca, идентификация дисков производится именно синтетической нагрузкой на винты. Отдельно замечу, что этот метод не очень помогает, кстати, в случае тупой корзины, без лампочки. И тут получается замкнутый круг: Чтобы вытащить винт надо узнать его серийник, а чтобы узнать серийник надо вытащить винт :). Добавим сюда случаи, где винты стоят не в корзинах и лампочка одна на всех :) Кстати, по теме, когда-то наткнулся на опцию в ethtool для inetl'овских сетевух, которая заставляла лампочки на сетевухе мигать как на гирлянде. Я долго думал зачем это. А для винтов такого ещё не придумали :( -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Иван Лох wrote: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Если только вендор сервера не написал на внешней крышке корзины, какой ей соответствует by-path, оно не поможет :) Нужно какое-то соответствие между любым логическим именем диска (sdX или by-path - не суть) и корзиной на панели сервера. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если освободить устройство не удалось, выброса не происходит. Попробуй открыть файл на cd из консоли и потом его вынуть. Это ты говорить о причинах, которые мешают отсоединить том программно. А вот если устройства уже нет, а в системе оно есть, значит, либо система не узнала о его извлечении (нет поддержки контроллера и дров), либо она вообще не умеет отлавливать такие события. Либо узнала, но специально не стала его удалять. Попробуй вытащить примонтированную флэшку (с отключённым user space level отмонтированием). Тогда устройство останется, до тех пор пока оно будет использоваться хоть чем-то в ядре (в данном случае vfs). Кстати, это очень интересный вопрос. Может ли ядро отлавливать извлечение устройства и что для этого надо? Может, когда железо и драйвер это поддерживают. Может также обнаруживать исчезновение устройства по косвенным признакам, если драйвер это поддерживает. Вся необходимая инфраструктура есть. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: В Птн, 04/04/2008 в 17:56 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. Наклейки с серийным номером винта - решают, однозначно. Кстати, на 24-винтовой банке имени etegro, которая сделана на контроллере areca, идентификация дисков производится именно синтетической нагрузкой на винты. Отдельно замечу, что этот метод не очень помогает, кстати, в случае тупой корзины, без лампочки. И тут получается замкнутый круг: Чтобы вытащить винт надо узнать его серийник, а чтобы узнать серийник надо вытащить винт :). Добавим сюда случаи, где винты стоят не в корзинах и лампочка одна на всех :) Замкнутый круг решается наклеиванием наклеек на момент сборки системы. При живом массиве можно повыдергивать по одному винту, это не такая большая проблема, кстати. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 17:56 +0400, Nikita V. Youshchenko пишет: Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если освободить устройство не удалось, выброса не происходит. Попробуй открыть файл на cd из консоли и потом его вынуть. Это ты говорить о причинах, которые мешают отсоединить том программно. А вот если устройства уже нет, а в системе оно есть, значит, либо система не узнала о его извлечении (нет поддержки контроллера и дров), либо она вообще не умеет отлавливать такие события. Либо узнала, но специально не стала его удалять. Попробуй вытащить примонтированную флэшку (с отключённым user space level отмонтированием). Тогда устройство останется, до тех пор пока оно будет использоваться хоть чем-то в ядре (в данном случае vfs). Как отключить user space level отмонтирование? Вставил флёшку, открыл с неё фото, вынул, устройство пропало. Кстати, это очень интересный вопрос. Может ли ядро отлавливать извлечение устройства и что для этого надо? Может, когда железо и драйвер это поддерживают. Может также обнаруживать исчезновение устройства по косвенным признакам, если драйвер это поддерживает. Вся необходимая инфраструктура есть. Объясни тогда, зачем держать устройство если его вынули и воткнул ли обратно не известно? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Птн, 04/04/2008 в 18:46 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 17:56 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Птн, 04/04/2008 в 18:00 +0400, Иван Лох пишет: On Fri, Apr 04, 2008 at 11:59:24AM +0400, Nikita V. Youshchenko wrote: А что касается сложности (по крайней мере внешней) описанной процедуры - что-то мне подсказывает, что во всяких энтерпрайз дистрибутивах есть всякие гуёвые энтерпрайз инструменты, в которых корректная процедуры выполняется задокументированными кликами на красивых картинках. Но я этот вопрос не изучал - мне как кернел хакеру как-то ближе общение с ядром через sysfs :) Но согласитесь, определять диск по миганию светодиода это никакого отношения к sysfs не имеет ;-} Это 100% бубен. Но тут IMHO /dev/disk/by-path должно помочь. Наклеички не забудьте, тоже действенно. Конечно, если приматать eject к корзине, как в CD/DVD было бы проще. Наклейки с серийным номером винта - решают, однозначно. Кстати, на 24-винтовой банке имени etegro, которая сделана на контроллере areca, идентификация дисков производится именно синтетической нагрузкой на винты. Отдельно замечу, что этот метод не очень помогает, кстати, в случае тупой корзины, без лампочки. И тут получается замкнутый круг: Чтобы вытащить винт надо узнать его серийник, а чтобы узнать серийник надо вытащить винт :). Добавим сюда случаи, где винты стоят не в корзинах и лампочка одна на всех :) Замкнутый круг решается наклеиванием наклеек на момент сборки системы. При живом массиве можно повыдергивать по одному винту, это не такая большая проблема, кстати. Я так и делал :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если освободить устройство не удалось, выброса не происходит. Попробуй открыть файл на cd из консоли и потом его вынуть. Это ты говорить о причинах, которые мешают отсоединить том программно. А вот если устройства уже нет, а в системе оно есть, значит, либо система не узнала о его извлечении (нет поддержки контроллера и дров), либо она вообще не умеет отлавливать такие события. Либо узнала, но специально не стала его удалять. Попробуй вытащить примонтированную флэшку (с отключённым user space level отмонтированием). Тогда устройство останется, до тех пор пока оно будет использоваться хоть чем-то в ядре (в данном случае vfs). Как отключить user space level отмонтирование? Вставил флёшку, открыл с неё фото, вынул, устройство пропало. Не катит. То, что у вас открыта картинка в окошке, не означает, что открыт файл в системе. Скорее всего, программа считала файл и закрыла его. После чего pmount или hal или что там вы используете благополучно отмонтировал флэшку, поймав событие device remove. И только после этого устройство исчезло из системы. Попробуйте открыть терминал, перейти в каталог на флэшке и запустить что-то вроде ( while true; do sleep 10; echo X; done ) file чтобы файл на уровне файловой системы оставался открытым. Тогда ваш user space helper не сможет отмонтировать файловую систему, и устройство останется. Кстати, это очень интересный вопрос. Может ли ядро отлавливать извлечение устройства и что для этого надо? Может, когда железо и драйвер это поддерживают. Может также обнаруживать исчезновение устройства по косвенным признакам, если драйвер это поддерживает. Вся необходимая инфраструктура есть. Объясни тогда, зачем держать устройство если его вынули и воткнул ли обратно не известно? Для целостности структуры данных. Нельзя удалять объект, на который остаются ссылки. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Nikita V. Youshchenko - debian-russian@lists.debian.org @ Fri, 04 Apr 2008
20:12:36 +0400:
Дык эта. Там СНАЧАЛА идет его освобождение, потом выброс. Если
освободить устройство не удалось, выброса не происходит.
Попробуй открыть файл на cd из консоли и потом его вынуть.
Это ты говорить о причинах, которые мешают отсоединить том программно.
А вот если устройства уже нет, а в системе оно есть, значит, либо
система не узнала о его извлечении (нет поддержки контроллера и дров),
либо она вообще не умеет отлавливать такие события.
Либо узнала, но специально не стала его удалять.
Попробуй вытащить примонтированную флэшку (с отключённым user space level
отмонтированием). Тогда устройство останется, до тех пор пока оно будет
использоваться хоть чем-то в ядре (в данном случае vfs).
Как отключить user space level отмонтирование? Вставил флёшку, открыл с
неё фото, вынул, устройство пропало.
NVY Не катит.
NVY То, что у вас открыта картинка в окошке, не означает, что открыт файл в
NVY системе. Скорее всего, программа считала файл и закрыла его. После чего
NVY pmount или hal или что там вы используете благополучно отмонтировал
флэшку,
NVY поймав событие device remove. И только после этого устройство исчезло из
NVY системы.
NVY Попробуйте открыть терминал, перейти в каталог на флэшке и запустить
что-то
NVY вроде
NVY ( while true; do sleep 10; echo X; done ) file
NVY чтобы файл на уровне файловой системы оставался открытым.
NVY Тогда ваш user space helper не сможет отмонтировать файловую систему, и
NVY устройство останется.
Кстати, это очень интересный вопрос. Может ли ядро отлавливать
извлечение устройства и что для этого надо?
Может, когда железо и драйвер это поддерживают. Может также обнаруживать
исчезновение устройства по косвенным признакам, если драйвер это
поддерживает. Вся необходимая инфраструктура есть.
Объясни тогда, зачем держать устройство если его вынули и воткнул ли
обратно не известно?
NVY Для целостности структуры данных.
NVY Нельзя удалять объект, на который остаются ссылки.
По поводу нельзя - man umount на предмет ключа -f.
Видишь ли, объект, на который остаются ссылки в конечном итоге уже
удален - устройство-то из системы выдернуто. Что мешает при написании
даже не драйвера, а подсистемы учесть эту возможность - совершенно
непонятно.
Да и кроме того, должен заметить, что, скажем, Nokia N800 вполне
отлавливает выдергивание задействованной карточки (вернее, уже
открывание ее крышечки) и начинает вопить эй, мужик, верни мне
карточку, а то мало ли чего я не успела туда записать! И таки да, если
вернуть, допишет. Ей, правда, проще. У нее, в общем, хорошо определено
то место, куда надо вывести вопл.
Правда, порой она ее держит не по делу, но это уже к гному
сакраментальный вопрос...
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Save the environment. Create a closure today.
-- Cormac Flanagan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Объясни тогда, зачем держать устройство если его вынули и воткнул ли обратно не известно? NVY Для целостности структуры данных. NVY Нельзя удалять объект, на который остаются ссылки. По поводу нельзя - man umount на предмет ключа -f. -f Force unmount (in case of an unreachable NFS system). Не о том :) Видишь ли, объект, на который остаются ссылки в конечном итоге уже удален - устройство-то из системы выдернуто. Что мешает при написании даже не драйвера, а подсистемы учесть эту возможность - совершенно непонятно. Нет, объект не удалён. Устройство удалено, а вот представляющий его объект существует до тех пор, пока на него остаются ссылки. И должным образом обрабатывает попытки работать с этим устройством. Например, так, как в приведённом примере с Nokia N800. Так уж устроено ядро. Может и можно было его спроектировать по-другому - но это имхо совершенно не стоит той работы, которая потребуется. Попробуйте ради интереса написать программу, которая при каждом использовании внутренних объектов структуры данных должна быть готова к тому, что их уже нет :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Nikita V. Youshchenko - debian-russian@lists.debian.org @ Fri, 04 Apr 2008
23:01:11 +0400:
Объясни тогда, зачем держать устройство если его вынули и воткнул ли
обратно не известно?
NVY Для целостности структуры данных.
NVY Нельзя удалять объект, на который остаются ссылки.
По поводу нельзя - man umount на предмет ключа -f.
NVY-f Force unmount (in case of an unreachable NFS system).
NVY Не о том :)
Не скажи.
Видишь ли, объект, на который остаются ссылки в конечном итоге уже
удален - устройство-то из системы выдернуто. Что мешает при написании
даже не драйвера, а подсистемы учесть эту возможность - совершенно
непонятно.
NVY Нет, объект не удалён. Устройство удалено, а вот представляющий
NVY его объект существует до тех пор, пока на него остаются ссылки.
Объект физическое устройство удален. Представляющий его объект в ядре
является ссылкой на физический. Теперь - осиротевшей.
NVY И должным образом обрабатывает попытки работать с этим
NVY устройством. Например, так, как в приведённом примере с Nokia
NVY N800.
Речь у нас как раз идет о том, что недолжным. N800, впрочем, тоже (у
нее перекос в другую сторону - ей невозможно сказать свои приложения я
закрыл, все что осталось - это гномовские ублюдки, держащие cwd где
попало не по делу, руби их нафиг и отдай девайс), но она хотя бы
сообщает об этом.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает
трудовыми мозолями. (С)энта
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
На сколько я понимаю - мать и дрова должны поддерживать горячую замену.
Во вторых, можно пользоваться признаками дисков/разделов отличными
от /dev/sd*, например UUID'ами или LABEL'ами.
В Чтв, 03/04/2008 в 12:32 +0300, Sergej Kandyla пишет:
Есть сервачек на базе Intel S5000PSL, сделал программный рейд, при креш
тестах всплыли интересные ньюнасы.
Debian Etch.
На сервере 3 sata диска, sda,sdb,sdc в хотсвапе.
sda + sdb = md_raid1
# df -h|grep md
/dev/md3 227G 921M 214G 1% /
/dev/md1 183M 17M 157M 10% /boot
1)
Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все
ок, вставляю обратно, но он определяется уже не как sdb, а как sdd.
Подробней с выводом dmesg показано ниже. Неприятно, но ребут помогает,
диск снова именуюется правильно, восстанавливаю degraded зеркало по типу
# mdadm -a /dev/md3 /dev/sdb3
Вопрос: это так и должна себя вести система, или такое поведение можно
какото отключить (чтобы нумерация дисков не сбивалась)? Идея то хотсвапа
как раз в том, чтобы без простоя менять диски... Ну или возможно я
что-то не так делаю..?
dmesg:
=== Вытянул hotswap disk2 (sdb) ===
Apr 3 14:46:57 srv kernel: mptbase: ioc0: LogInfo(0x31010011):
Originator={PL}, Code={Open Failure}, SubCod
e(0x0011)
Apr 3 14:46:57 srv kernel: sd 0:0:1:0: SCSI error: return code = 0x0001
Apr 3 14:46:57 srv kernel: end_request: I/O error, dev sdb, sector
490223230
Apr 3 14:46:57 srv kernel: ^IOperation continuing on 1 devices
Apr 3 14:46:57 srv kernel: RAID1 conf printout:
Apr 3 14:46:57 srv kernel: --- wd:1 rd:2
Apr 3 14:46:57 srv kernel: disk 0, wo:0, o:1, dev:sda3
Apr 3 14:46:57 srv kernel: disk 1, wo:1, o:0, dev:sdb3
Apr 3 14:46:57 srv kernel: RAID1 conf printout:
Apr 3 14:46:57 srv kernel: --- wd:1 rd:2
Apr 3 14:46:57 srv kernel: disk 0, wo:0, o:1, dev:sda3
Apr 3 14:46:57 srv kernel: mptsas: ioc0: removing sata device, channel
0, id 12, phy 1
=== Вставил обратно hotswap disk2 (sdb), но он определился уже как sdd ===
Apr 3 14:54:03 srv kernel: mptsas: ioc0: attaching sata device, channel
0, id 12, phy 1
Apr 3 14:54:03 srv kernel: Vendor: ATA Model: WDC WD2500YS-01S
Rev: 6C06
Apr 3 14:54:03 srv kernel: Type: Direct-Access
ANSI SCSI revision: 05
Apr 3 14:54:03 srv kernel: SCSI device sdd: 490234752 512-byte hdwr
sectors (251000 MB)
Apr 3 14:54:03 srv kernel: sdd: Write Protect is off
Apr 3 14:54:03 srv kernel: SCSI device sdd: drive cache: write back
Apr 3 14:54:03 srv kernel: SCSI device sdd: 490234752 512-byte hdwr
sectors (251000 MB)
Apr 3 14:54:03 srv kernel: sdd: Write Protect is off
Apr 3 14:54:03 srv kernel: SCSI device sdd: drive cache: write back
Apr 3 14:54:03 srv kernel: sdd: sdd1 sdd2 sdd3
Apr 3 14:54:03 srv kernel: sd 0:0:4:0: Attached scsi disk sdd
2) Тест второй.
Выключаю машину, вытаскиваю (по очереди) составляющие диски рейда, загружаю.
Система грузится с оставшихся компонентов рейда нормально, но опять
же...нумерация дисков сбивается. Бывший sdc становится sdb
С рейдами не сильно опыта много, поэтому буду благодарен если кто
прояснит ситуацию. Как правильно тестировать и вести себя в боевых
условиях
--
Wbr, SK
--
Покотиленко Костик [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: На сколько я понимаю - мать и дрова должны поддерживать горячую замену. ну работает же ;) Мать естественно такое умеет, на счет дров не знаю...но в данном случае имитировался вариант креша диска. Во вторых, можно пользоваться признаками дисков/разделов отличными от /dev/sd*, например UUID'ами или LABEL'ами. ммм...а можно подробней для неискушенного человека, избалованного gmirrorами... как мне реализовать чтобы буква диска не менялась? или я просто неправильно готовлю рейды ? -- Wbr, SK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 13:24 +0300, Sergej Kandyla пишет: Покотиленко Костик wrote: На сколько я понимаю - мать и дрова должны поддерживать горячую замену. ну работает же ;) Мать естественно такое умеет, на счет дров не знаю...но в данном случае имитировался вариант креша диска. Во вторых, можно пользоваться признаками дисков/разделов отличными от /dev/sd*, например UUID'ами или LABEL'ами. ммм...а можно подробней для неискушенного человека, избалованного gmirrorами... как мне реализовать чтобы буква диска не менялась? или я просто неправильно готовлю рейды ? Наводка: mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка или вообще сказать чтобы все просканировал. # ls -la /dev/disk/by* /dev/disk/by-id: итого 0 drwxr-xr-x 2 root root 440 2008-04-01 16:45 . drwxr-xr-x 6 root root 120 2008-03-28 21:21 .. lrwxrwxrwx 1 root root 9 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 - ../../sda lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part1 - ../../sda1 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part2 - ../../sda2 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part3 - ../../sda3 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part4 - ../../sda4 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part5 - ../../sda5 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part6 - ../../sda6 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part7 - ../../sda7 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part8 - ../../sda8 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 ata-WDC_WD5000AAKS-0-WD-WCAS81269848 -part9 - ../../sda9 lrwxrwxrwx 1 root root 9 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848 - ../../sda lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part4 - ../../sda4 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part5 - ../../sda5 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part6 - ../../sda6 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part7 - ../../sda7 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part8 - ../../sda8 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 scsi-SATA_WDC_WD5000AAKS-_WD-WCAS812 69848-part9 - ../../sda9 /dev/disk/by-label: итого 0 drwxr-xr-x 2 root root 160 2008-03-31 15:27 . drwxr-xr-x 6 root root 120 2008-03-28 21:21 .. lrwxrwxrwx 1 root root 10 2008-03-28 21:21 data - ../../sda8 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 root - ../../sda2 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 tmp - ../../sda6 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 usr - ../../sda5 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 var - ../../sda7 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 WinData - ../../sda9 /dev/disk/by-path: итого 0 drwxr-xr-x 2 root root 260 2008-04-01 16:45 . drwxr-xr-x 6 root root 120 2008-03-28 21:21 .. lrwxrwxrwx 1 root root 9 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0 - ../ ../sda lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part4 - ../../sda4 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part5 - ../../sda5 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part6 - ../../sda6 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part7 - ../../sda7 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part8 - ../../sda8 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.2-scsi-1:0:0:0-part9 - ../../sda9 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 pci-:00:1f.5-scsi-0:0:0:0 - ../ ../scd0 /dev/disk/by-uuid: итого 0 drwxr-xr-x 2 root root 180 2008-04-01 16:45 . drwxr-xr-x 6 root root 120 2008-03-28 21:21 .. lrwxrwxrwx 1 root root 10 2008-03-28 21:21 8ECF3922 - ../../sda1 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 039713bb-1922-47e0-9f40-89ff7f2b6474 - ../../sda2 lrwxrwxrwx 1 root root 10 2008-03-28 21:21 39bfb1da-39da-4e60-aefd-370112d40703 - ../../sda7 lrwxrwxrwx 1 root root 10 2008-03-28 21:21
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 14:00 +0300, Sergej Kandyla пишет: # ls -la /dev/disk/by* # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987 - ../../sdc1 только один диск, третий, который не в зеркале. лучше все-таки по метке. её вручную проще написать. Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? э, батенька, вы хотите чтобы вообще диск менять в зеркале без телодвижений?? так не бывает, и дело тут не в метках. http://www.howtoforge.com/software-raid1-grub-boot-debian-etch - здесь есть кое-что на тему. Да, кстати, обязательно настройте и проверьте MD monitor daemon. А то у меня однажды целый месяц сервер на развалившемся зеркале работал. -- DamirX [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: Наводка: mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка или вообще сказать чтобы все просканировал. # ls -la /dev/disk/by* # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987 - ../../sdc1 только один диск, третий, который не в зеркале. Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? -- Wbr, SK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Sergej Kandyla wrote: Покотиленко Костик wrote: Наводка: mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка или вообще сказать чтобы все просканировал. # ls -la /dev/disk/by* # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987 - ../../sdc1 только один диск, третий, который не в зеркале. Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? Что значит нерабочими? У каждого диска и раздела есть свой серийнк, который не зависит от точки физического подключения. lrwxrwxrwx 1 root root 9 Мар 23 17:55 ata-ST3500630AS-6QG178DR - ../../sde lrwxrwxrwx 1 root root 9 Мар 23 17:55 ata-ST3500630AS-9QG1S96D - ../../sdb lrwxrwxrwx 1 root root 9 Мар 23 17:55 ata-ST3500630AS-9QG1S997 - ../../sdc lrwxrwxrwx 1 root root 9 Мар 23 17:55 ata-ST3500630AS-9QG1S9HR - ../../sda lrwxrwxrwx 1 root root 9 Мар 23 17:55 ata-ST3500630AS-9QG1SDF2 - ../../sdd Соответственно, можно указать /dev/disk/by-id/ata-ST3500630AS-6QG178DR, и оно всегда будет указывать на винт с соответствующим серийным номером. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 14:00 +0300, Sergej Kandyla пишет: Покотиленко Костик wrote: Наводка: mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка или вообще сказать чтобы все просканировал. # ls -la /dev/disk/by* # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987 - ../../sdc1 только один диск, третий, который не в зеркале. Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? Если такой вариант: 1 диск загрузочный 2 в raid 1 на подмену Если через uuid собрать массив из 2-х винтов, 3-й через uuid назначить как на подмену, mdadm'у сказать, чтобы сканировал все винты/партишки, то как ты потом не вынимай/втыкай/меняй местами - всё должно (по идее) работать нормально. А вот на счёт поддержки горячей замены ты проверь. Одно дело ядро уведомляют, что устройство извлекли, а другое дело, когда ядро думает, что винт умер и перестал отвечать (о чем по, моему, свидетельствует не освобождение устройства). Тут могут быть подводные камни. Смотри, устройство ты вынул, в системе оно осталось, что будет если попробовать прочитать с такого устройства? Я думаю это будет IO error и программа зависнет на долго. P.S. написал и до меня дошло, что uuid тут не причём :). Главное при создании и прикреплении замены правильные винты прописать, а потом сказать mdadm'у чтобы всё сканировал, он по подписям нужные винты найдёт. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 14:00 +0300, Sergej Kandyla пишет: # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987 - ../../sdc1 только один диск, третий, который не в зеркале. Тут кстати инетересный момент, который хотелось бы прояснить: у Вас зеркало собрано из разделов или дисков? Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? Современный md создает партиционируемые блочные девайсы, что может (а может и нет) уменьшить кол-во телодвижений при замене диска, исключая необходимость создания таблице разделов на новом диске. (Сам не пробовал.) -- DamirX [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все ок, вставляю обратно, но он определяется уже не как sdb, а как sdd. Это связано с тем, что логически sdb из системы не исчезло. Да и не могло - оно же открыто (хотя бы тем же raid). Поэтому процедура должна быть чуть сложнее. См. текст в аттачменте. Title: admin:raid[Документация ЛВК] New release candidate available: 2008-03-31. upgrade now! [11] [[admin:raid]] Документация ЛВК Вы посетили: start admin raid Содержание Обнаружение ошибки Уточнение происшедшего по логам Отключение томов от raid Отключение отказавшего диска от системы Определение, где находится отказавший диск Переподключение диска Отключение вновь обнаруженного диска от multipathd Возврат томов в raid Обнаружение ошибки В случае ошибки промлемный физический том перестаёт использоваться raid-ом, и демон mdadm уведомляет администраторов о происшедшем по почте: This is an automatically generated mail message from mdadm running on buki A Fail event had been detected on md device /dev/md2. It could be related to component device /dev/sdj2. Faithfully yours, etc. P.S. The /proc/mdstat file currently contains the following: Personalities : [raid1] [raid6] [raid5] [raid4] md2 : active raid5 sdi2[0] sdl2[3] sdk2[2] sdj2[4](F) 1463681856 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU] md1 : active raid1 sdk1[0] sdl1[1] 489856 blocks [2/2] [UU] md0 : active raid1 sdi1[0] sdj1[1] 489856 blocks [2/2] [UU] unused devices: none В данном случае ошибка была обнаружена на устройстве /dev/sdj2, входящем в raid /dev/md2. Уточнение происшедшего по логам Первое, что следует сделать, это посмотреть в логи - файл /var/log/syslog. Там должен остаться какой-то след происшедшего события. Примерное время события можно определить по времени отправки письма от демона mdadm. Если событие произошло достаточно давно, то информация может быть уже в файле /var/log/syslog.0 или в следующих файлах, оставленных службой logrotate. След события в логах может быть примерно таким: Dec 15 07:45:30 buki kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Dec 15 07:45:32 buki kernel: ata2.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout) Dec 15 07:45:38 buki kernel: ata2: port is slow to respond, please be patient Dec 15 07:46:01 buki kernel: ata2: port failed to respond (30 secs) Dec 15 07:46:47 buki kernel: ata2: soft resetting port Dec 15 07:46:47 buki kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 15 07:46:47 buki kernel: ATA: abnormal status 0xD0 on port 0xD9044CC7 Dec 15 07:46:47 buki last message repeated 4 times Dec 15 07:46:47 buki kernel: ata2.00: qc timeout (cmd 0xec) Dec 15 07:46:47 buki kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) Dec 15 07:46:47 buki kernel: ata2.00: revalidation failed (errno=-5) Dec 15 07:46:47 buki kernel: ata2: failed to recover some devices, retrying in 5 secs Dec 15 07:46:47 buki kernel: ata2: hard resetting port Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready) Dec 15 07:46:47 buki kernel: ata2: hardreset failed, retrying in 5 secs Dec 15 07:46:47 buki kernel: ata2: hard resetting port Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready) Dec 15 07:46:47 buki kernel: ata2: hardreset failed, retrying in 5 secs Dec 15 07:46:47 buki kernel: ata2: hard resetting port Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready) Dec 15 07:46:47 buki kernel: ata2: reset failed, giving up Dec 15 07:46:47 buki kernel: ata2.00: disabled Dec 15 07:46:47 buki kernel: ata2: EH complete Dec 15 07:46:47 buki kernel: sd 3:0:0:0: SCSI error: return code = 0x0004 Dec 15 07:46:47 buki kernel: end_request: I/O error, dev sdj, sector 976767869 Dec 15 07:46:47 buki kernel: raid5: Disk failure on sdj2, disabling device. Operation continuing on 3 devices Dec 15 07:46:47 buki kernel: RAID5 conf printout: Dec 15 07:46:47 buki kernel: --- rd:4 wd:3 fd:1 Dec 15 07:46:47 buki kernel: disk 0, o:1, dev:sdi2 Dec 15 07:46:47 buki kernel: disk 1, o:0, dev:sdj2 Dec 15 07:46:47 buki kernel: disk 2, o:1, dev:sdk2 Dec 15 07:46:47 buki kernel: disk 3, o:1, dev:sdl2 Dec 15 07:46:47 buki kernel: RAID5 conf printout: Dec 15 07:46:47 buki kernel: --- rd:4 wd:3 fd:1 Dec 15 07:46:47 buki kernel: disk 0, o:1, dev:sdi2 Dec 15 07:46:47 buki kernel: disk 2, o:1, dev:sdk2 Dec 15 07:46:47 buki kernel: disk 3, o:1, dev:sdl2 Видно, что проблема на интерфейсе ata2. Отключение томов от raid Первым действием нужно исключить sdj2 из состава raid. Важно сделать это до физического отключения диска, пока устройство /dev/sdj2 есть в файловой системе. [EMAIL PROTECTED]:/ mdadm /dev/md2
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 15:45 +0400, Nikita V. Youshchenko пишет: Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все ок, вставляю обратно, но он определяется уже не как sdb, а как sdd. Это связано с тем, что логически sdb из системы не исчезло. Да и не могло - оно же открыто (хотя бы тем же raid). Поэтому процедура должна быть чуть сложнее. См. текст в аттачменте. Вот, это очень интересная статья, хотя до автоматизма этой процедуре ещё далеко. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
alex kuklin - Sergej Kandyla @ Thu, 03 Apr 2008 15:35:33 +0400:
mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка
или вообще сказать чтобы все просканировал.
# ls -la /dev/disk/by*
# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Apr 3 14:56 20035e75-091a-41e8-83bb-55e036e53987
- ../../sdc1
только один диск, третий, который не в зеркале.
Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а
вставлю другой на его место, то соотвественно все эти махинации с метками
будут нерабочими ?
ak Что значит нерабочими?
Значит, что если ты вынешь диск, подцепленный по UUID'у, и вставишь
вместо него другой такой же, он не подцепится, потому как UUID другой.
Это я перевожу вопрос.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Рюкзак не пересобирают, рюкзак укладывают! (c)Руна
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В сообщении от 3 апреля 2008 16:51 Artem Chuprina написал(a): mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка ak Что значит нерабочими? Значит, что если ты вынешь диск, подцепленный по UUID'у, и вставишь вместо него другой такой же, он не подцепится, потому как UUID другой. Если речь про софтовый линукс райд, нужно различать утилиту mdadm и драйвер md. Подозреваю, что драйверу md на UUID диска наплевать, ему интересен только свой суперблок. А хранится ли в нём(суперблоке) информация о привязанном блочном устройстве (разделе или диске)? Думаю вряд ли. Посему, скопированный сектор в сектор другой аналогичный диск будет иметь другой UUID, но будет подцеплен в массив. Я прав? -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Thu, 03 Apr 2008 15:39:41 +0300 Покотиленко Костик [EMAIL PROTECTED] wrote: В Чтв, 03/04/2008 в 15:45 +0400, Nikita V. Youshchenko пишет: Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все ок, вставляю обратно, но он определяется уже не как sdb, а как sdd. Это связано с тем, что логически sdb из системы не исчезло. Да и не могло - оно же открыто (хотя бы тем же raid). Поэтому процедура должна быть чуть сложнее. См. текст в аттачменте. Вот, это очень интересная статья, хотя до автоматизма этой процедуре ещё далеко. Раз в полгода на сервере отваливается один из локальных дисков (всегда разные %)). Провернуть действия не очень сложно в принципе. Если просто вынуть-вставить, то он подцепится, но с другой буквой. В принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно отключать диск, чтобы он оказался свободен. Ну и запротоколировали, чтобы не вспоминать каждый раз. Автоматизировать в принципе можно, но такой цели не ставилось, все таки у нас не парк серверов, а всего несколько штук. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
DamirX wrote: лучше все-таки по метке. её вручную проще написать. Правильно ли я понимаю, что если я вытяну из корзины один физический диск, а вставлю другой на его место, то соотвественно все эти махинации с метками будут нерабочими ? э, батенька, вы хотите чтобы вообще диск менять в зеркале без телодвижений?? так не бывает, и дело тут не в метках. двигаться я привык ;) я просто хочу 1) четко знать как это следует делать (правильно) и как вести себя в соотвествующих случаях 2) выробатать процедуру, если не автоматизировать, то хотя бы не ломать голову когда нужно будет встречаясь с непонятным мне поведеним (сказываются годы бсд..), страюсь разобраться чтобы учесть ньюансы. http://www.howtoforge.com/software-raid1-grub-boot-debian-etch - здесь есть кое-что на тему. Я именно по этим хауту и делал ;) + http://www.linuxconfig.org/Linux_Software_Raid_1_Setup http://www.opennet.ru/tips/sml/120.shtml кстати на howtoforge мой вопрос не раскрыт. Там человек диск достает, машину выключает и вставляет новый. А мне хотелось бы без выключения (если такое можно...) Ну на самом деле выключить не проблема просто сейчас у меня сервер на тестировании, где он будет через пару месяцев я не знаю, и хочу быть готовым к разным ситуациям. Да, кстати, обязательно настройте и проверьте MD monitor daemon. А то у меня однажды целый месяц сервер на развалившемся зеркале работал. спасибо! Да, зеркало создано из разделов. (можно сказать что в статье на howtoforge приведен именно мой случай) Я бы с удовольствием сделал рейд1 из дисков целиком, но разве mdraid такое позволяет? PS. только что делал еще один тест. #apt-get upgrade называется..;) Чтобы и к этому варианту быть готовым. Оказалось, делал не зря. Система мне предложила обновить все пакеты включая кернел, хотя не понятно почему пыталось проапгрейдить на туже версию кернела. В результате данной процедуры мне перезаписало menu.lst, о данном факте я узнал после ребута ;) Пришлось пол часа поколдовать руками в консоли...благо серв рядом. У меня даже мысль возникла chattr на конфиг граба поставить, но боюсь как бы другие косяки от этого не стали вылазить. Так что просто данный ньюанс следует иметь в виду. 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) -- Wbr, SK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В сообщении от 3 апреля 2008 17:24 Sergej Kandyla написал(a): Да, зеркало создано из разделов. (можно сказать что в статье на howtoforge приведен именно мой случай) Я бы с удовольствием сделал рейд1 из дисков целиком, но разве mdraid такое позволяет? Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное массива - 2 шт. из /boot-ов и остального зеркало остального скармливаем LVM и нарезаем себе что нужно (/home, /var, /usr, ...) Все делает искаробочный debian-installer Загрузчик будет LILO, но после установки можно сменить на GRUB. -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Sergej Kandyla wrote: Я бы с удовольствием сделал рейд1 из дисков целиком, но разве mdraid такое позволяет? Позволяет, но делать так не рекомендуется. 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. -- maxym -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Thu, 03 Apr 2008 16:24:51 +0300 Sergej Kandyla [EMAIL PROTECTED] wrote: #apt-get upgrade называется..;) Чтобы и к этому варианту быть готовым. Оказалось, делал не зря. Система мне предложила обновить все пакеты включая кернел, хотя не понятно почему пыталось проапгрейдить на туже версию кернела. В результате данной процедуры мне перезаписало menu.lst, о данном факте я узнал после ребута ;) Пришлось пол часа поколдовать руками в консоли...благо серв рядом. У меня даже мысль возникла chattr на конфиг граба поставить, но боюсь как бы другие косяки от этого не стали вылазить. Так что просто данный ньюанс следует иметь в виду. Читай внимательно комментарии в этом файле и поймешь, что там безопасно править, а что потеряется при grub-update. 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) В нашем случае на сервере работает несколько ВМ и полсотни пользовательских сессий. Поэтому ребут - для крайних случаев. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 18:05 +0400, Alexander GQ Gerasiov пишет: Thu, 03 Apr 2008 16:24:51 +0300 Sergej Kandyla [EMAIL PROTECTED] wrote: #apt-get upgrade называется..;) Чтобы и к этому варианту быть готовым. Оказалось, делал не зря. Система мне предложила обновить все пакеты включая кернел, хотя не понятно почему пыталось проапгрейдить на туже версию кернела. В результате данной процедуры мне перезаписало menu.lst, о данном факте я узнал после ребута ;) Пришлось пол часа поколдовать руками в консоли...благо серв рядом. У меня даже мысль возникла chattr на конфиг граба поставить, но боюсь как бы другие косяки от этого не стали вылазить. Так что просто данный ньюанс следует иметь в виду. Читай внимательно комментарии в этом файле и поймешь, что там безопасно править, а что потеряется при grub-update. А по мимо этого если Вы объясните зачем править menu.lst, возможно Вам расскажут как этого не делать... -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 16:48 +0300, Maxim Kudelya пишет: Sergej Kandyla wrote: Я бы с удовольствием сделал рейд1 из дисков целиком, но разве mdraid такое позволяет? Позволяет, но делать так не рекомендуется. Ребята, не путайте dmraid и dmadm :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 17:51 +0400, alex kuklin пишет: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. К тому же, например raid из 2-х дисков 250GB, к тому времени когда возможно придётся заменить один диск, Вы скорее всего купите диск не меньше 1TB, однако жалко будет хоронить 750GB, и Вам возможно придёт идея купить 2 диска 1TB, а 250GB подарить кому-нибудь. А вообще, я тут вижу 2 варианта: - ставить raid сразу c hotspare; или - при необходимости покупать на raid все новые диски, а старые пускать по кругу. Тут также решается вопрос с износом остальных дисков. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Thu, 03 Apr 2008 17:48:50 +0300 Покотиленко Костик [EMAIL PROTECTED] wrote: Вот, это очень интересная статья, хотя до автоматизма этой процедуре ещё далеко. Раз в полгода на сервере отваливается один из локальных дисков (всегда разные %)). Провернуть действия не очень сложно в принципе. Если просто вынуть-вставить, то он подцепится, но с другой буквой. В принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно отключать диск, чтобы он оказался свободен. Ну и запротоколировали, чтобы не вспоминать каждый раз. Автоматизировать в принципе можно, но такой цели не ставилось, все таки у нас не парк серверов, а всего несколько штук. Знаешь, когда я первый раз коснулся этого вопроса, мне было непонятно, как на серверной операционке до сих пор нет отлаженного механизма hot-замены, в том числе дисков. Так есть же отлаженный механизм. Только вот выделяется новое устройство, если старое не корректно удалено. А если ты сам хочешь вынуть - отключи устройство сам (отмонтируй, удали из рейда etc) и будет все кошерно, с освобождением буквы. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 17:04 +0400, Andrey Nikitin пишет: В сообщении от 3 апреля 2008 16:51 Artem Chuprina написал(a): mdadm'у можно давать девайсы в таком виде /dev/disk/by-label/метка ak Что значит нерабочими? Значит, что если ты вынешь диск, подцепленный по UUID'у, и вставишь вместо него другой такой же, он не подцепится, потому как UUID другой. Если речь про софтовый линукс райд, нужно различать утилиту mdadm и драйвер md. Подозреваю, что драйверу md на UUID диска наплевать, ему интересен только свой суперблок. А хранится ли в нём(суперблоке) информация о привязанном блочном устройстве (разделе или диске)? Думаю вряд ли. Посему, скопированный сектор в сектор другой аналогичный диск будет иметь другой UUID, но будет подцеплен в массив. Я прав? Думаю, что Вы правы 100%. Только mdadm'у надо не забыть сказать - сканируй все винты и ищи свои суперблоки! А то по умолчанию по моему не так. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 17:20 +0400, Alexander GQ Gerasiov пишет: Thu, 03 Apr 2008 15:39:41 +0300 Покотиленко Костик [EMAIL PROTECTED] wrote: В Чтв, 03/04/2008 в 15:45 +0400, Nikita V. Youshchenko пишет: Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все ок, вставляю обратно, но он определяется уже не как sdb, а как sdd. Это связано с тем, что логически sdb из системы не исчезло. Да и не могло - оно же открыто (хотя бы тем же raid). Поэтому процедура должна быть чуть сложнее. См. текст в аттачменте. Вот, это очень интересная статья, хотя до автоматизма этой процедуре ещё далеко. Раз в полгода на сервере отваливается один из локальных дисков (всегда разные %)). Провернуть действия не очень сложно в принципе. Если просто вынуть-вставить, то он подцепится, но с другой буквой. В принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно отключать диск, чтобы он оказался свободен. Ну и запротоколировали, чтобы не вспоминать каждый раз. Автоматизировать в принципе можно, но такой цели не ставилось, все таки у нас не парк серверов, а всего несколько штук. Знаешь, когда я первый раз коснулся этого вопроса, мне было непонятно, как на серверной операционке до сих пор нет отлаженного механизма hot-замены, в том числе дисков. ... а так я всё понимаю, конечно. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Покотиленко Костик wrote: В Чтв, 03/04/2008 в 17:51 +0400, alex kuklin пишет: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. К тому же, например raid из 2-х дисков 250GB, к тому времени когда возможно придётся заменить один диск, Вы скорее всего купите диск не меньше 1TB, однако жалко будет хоронить 750GB, и Вам возможно придёт идея купить 2 диска 1TB, а 250GB подарить кому-нибудь. Можно вместо целого винта использовать раздел А вообще, я тут вижу 2 варианта: - ставить raid сразу c hotspare; или - при необходимости покупать на raid все новые диски, а старые пускать по кругу. Тут также решается вопрос с износом остальных дисков. Угу, просто нет обязательного требования идентичности винтов, вот я о чем. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 18:56 +0400, Alexander GQ Gerasiov пишет: Thu, 03 Apr 2008 17:48:50 +0300 Покотиленко Костик [EMAIL PROTECTED] wrote: Вот, это очень интересная статья, хотя до автоматизма этой процедуре ещё далеко. Раз в полгода на сервере отваливается один из локальных дисков (всегда разные %)). Провернуть действия не очень сложно в принципе. Если просто вынуть-вставить, то он подцепится, но с другой буквой. В принципе не страшно, можно и его подцепить, но пока разбирались с multipathd и тем, как у него диск отобрать, заодно поняли, как кошерно отключать диск, чтобы он оказался свободен. Ну и запротоколировали, чтобы не вспоминать каждый раз. Автоматизировать в принципе можно, но такой цели не ставилось, все таки у нас не парк серверов, а всего несколько штук. Знаешь, когда я первый раз коснулся этого вопроса, мне было непонятно, как на серверной операционке до сих пор нет отлаженного механизма hot-замены, в том числе дисков. Так есть же отлаженный механизм. Только вот выделяется новое устройство, если старое не корректно удалено. А если ты сам хочешь вынуть - отключи устройство сам (отмонтируй, удали из рейда etc) и будет все кошерно, с освобождением буквы. Что-то у меня не вяжется отлаженный механизм с если старое не корректно удалено... -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Покотиленко Костик wrote: В Чтв, 03/04/2008 в 17:51 +0400, alex kuklin пишет: Maxim Kudelya wrote: 2 Nikita V. Youshchenko: спасибо, интересная дока. Прочитал и пришла мысль, что если сдохнит винт, быстрее будет перезагрузиться и вставить новый, чем мудрствовать лукаво ;) Такой себе вариант для истинных джедаев )) Не новый, а предварительно замоченный в солидоле диск, с точно такой-же геометрией как и вылетевший. С фигов ли? Нужен диск НЕ МЕНЬШЕ. И непонятно, почему не новый? Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. К тому же, например raid из 2-х дисков 250GB, к тому времени когда возможно придётся заменить один диск, Вы скорее всего купите диск не меньше 1TB, однако жалко будет хоронить 750GB, и Вам возможно придёт идея купить 2 диска 1TB, а 250GB подарить кому-нибудь. Можно вместо целого винта использовать раздел А вообще, я тут вижу 2 варианта: - ставить raid сразу c hotspare; или - при необходимости покупать на raid все новые диски, а старые пускать по кругу. Тут также решается вопрос с износом остальных дисков. Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Это да. Но глубже смотреть надо :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
В Чтв, 03/04/2008 в 18:52 +0400, alex kuklin пишет: Существует мнение, что в raid лучше работают ОДИНАКОВЫЕ диски. Я ни разу не видел подтверждения тому, для случая софтрейда во всяком случае. Существует мнение, что _одинаковые диски_ умирают в один день. Сам видел. Угу, просто нет обязательного требования идентичности винтов, вот я о чем. Рекомендуется использовать в одном зеркале диски разных производителей. -- DamirX [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Andrey Nikitin пишет: В сообщении от 3 апреля 2008 17:24 Sergej Kandyla написал(a): Да, зеркало создано из разделов. (можно сказать что в статье на howtoforge приведен именно мой случай) Я бы с удовольствием сделал рейд1 из дисков целиком, но разве mdraid такое позволяет? Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать массива - 2 шт. из /boot-ов и остального зеркало остального скармливаем LVM и нарезаем себе что нужно (/home, /var, /usr, ...) Все делает искаробочный debian-installer Загрузчик будет LILO, но после установки можно сменить на GRUB. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: md raid1 testing issue
Andrey Lyubimets wrote: Как вариант для зеркала: 2 диска, на них по 3 одинаковых раздела - /boot, swap, остальное имхо, своп лучше тоже на зеркале держать Swap на зеркале будет медленнее, чем на разделе. Если нужна сохранность данных, то необязательно. Если нужна стабильность работы - то да, но вообще, при нынешних ценах на память, лучше больше памяти поставить. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
