The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В реализации программного RAID для Linux обнаружена ошибка, которая может привести к повреждению мета-данных

19.06.2012 10:13

Нейл Браун (Neil Brown), основной разработчик пакета mdadm и подсистемы для обеспечения работы программных RAID-массивов в Linux, опубликовал предупреждение о выявлении серьёзной ошибки в md/raid, которая может привести к обнулению важных мета-данных на дисках, входящих в программный RAID. Например, может быть очищена информация о массиве, о смещениях данных, размерах блоков и роли каждого диска в массиве. Всем пользователям рекомендуется первым делом сохранить на внешнем носителе вывод команды "mdadm -Evvvvs", для обеспечения возможности восстановления в случае проявления ошибки (для восстановления достаточно пересоздать массив через "mdadm --create" с теми же параметрами).

Проблема присутствует в ядрах Linux с 3.4-rc1 по 3.4-rc4, с 3.3.1 по 3.3.3 и с 3.2.14 по 3.2.16. В ядра некоторых дистрибутивов также был портирован код, приводящий к ошибке: в SLES11-SP2 проблеме подвержены ядра 3.0.26-0.7 и 3.0.26-0.8, в Ubuntu - с 3.2.0-22.35 по 3.2.0-24.37. Ошибка проявляется только при перезагрузке, выключении или аварийном завершении работы. В процессе штатного функционирования проблема не всплывает. Ошибка возникает в ситуации, когда в процессе завершения работы массив находится в частично собранном и остановленном состоянии, что может возникнуть, например, при использовании команд "mdadm --incremental" или "mdadm -A". В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".

Для исключения проявления ошибки в процессе обновления подверженного проблеме ядра рекомендуется перед перезагрузкой убедиться в отсутствии частично собранных RAID-разделов. Например, рекомендуется перед перезапуском выполнить команды "mv /sbin/mdadm /sbin/mdadm.moved; /sbin/mdadm.moved --stop --scan", после чего загрузиться с новым ядром в одиночный режим и восстановить переименованный файл "mv /sbin/mdadm.moved /sbin/mdadm".

  1. Главная ссылка к новости (http://neil.brown.name/blog/20...)
  2. OpenNews: Доступна реализация программного RAID для Linux - mdadm 3.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/34131-linux
Ключевые слова: linux, raid, mdadm, bug
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:51, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Афигеть мой конфиг, бегу...
     
     
  • 2.93, Anonim (??), 23:35, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Дебиана 6 с ядром из 3,2 бэкпортов (конкретно версия непонятно какая, Apt скрывает) касается?
     
  • 2.5, ааноним (?), 11:32, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    [correctmode]
    И как всегда ошибку нашёл сам разработчик, а не некий аноним, читающий исходники
    > ночью. В очередной раз миф о том, что открытые исходники позволяют
    > найти ошибки, развалился на глазах. С таким же успехом разработчик закрытой
    > системы находит ошибки, без лишней лапши о чтении исходников всеми.

    [/correctmode]

     
     
  • 3.26, AZ_from_Belarus (ok), 12:47, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Аноним читающий по ночам исходники - это миф выдуманный ниспровергателями мифа и не имеющий отношения к действительности.
    Ошибки отлавливаются чаще всего разработчиками. Существенно то, что возможность стать разработчиком открыта для любого. И код читают не анонимы, а те, кто предполагает модифицировать код для некоторых своих потребностей либо для того, чтобы уяснить для себя особенности работы системы для всяческих отстраивания под те или иные нужды.
    Далее - вероятности обнаружения. У изначального разработчика не забрасывающего поддержку написанного кода вероятность обнаружения ошибки выше. Особенно если ошибка проявляется в довольно редких условиях. Но это же не делает невероятным выявление ляпов кем-то другим.
     
     
  • 4.99, Аноним (-), 01:08, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > читающий по ночам исходники

    читающий исходники после того как его софтрейд внезапно помер

    FIXED

     
  • 4.115, Michael Shigorin (ok), 13:46, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Аноним читающий по ночам исходники - это миф выдуманный ниспровергателями мифа

    Не обращайте вминания, это было выступление пользователя Apple, который даже не сообразил, что обнаружение, диагностика, исправление и анонс -- это четыре разных вещи.

    > Далее - вероятности обнаружения.

    Around 3.0/3.1 people started reporting this bug being triggered at shutdown.

    > Особенно если ошибка проявляется в довольно редких условиях.

    Надо же, убунтушники приложили свои усилия к тому, чтобы эти условия были менее редкими...

     
  • 2.13, Аноним (-), 11:57, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > В очередной раз миф ... развалился на глазах

    Хорошая оговорка. Миф может развалиться только один раз, а если он разваливается "в очередной раз", то, видимо, у разваливателей "мифа" кишка тонка

     
  • 2.43, Аноним (-), 13:37, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Почему "как всегда" и что за аноним?
     
  • 2.75, ytrrt (?), 15:18, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    О, ты много знаешь людей способных понять код драйверов для RAID?
     
     
  • 3.94, Аноним (-), 00:23, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да в общем похрену какой код разбирать. Если задаться целью, то желаемое становится действительностью и этот случай не исключение. Некоторые требуемые навыки и опыт ни кто не отменял, впрочем они не зависят от контекста исследований. И да, в чем отличие кода поддержки RAID от простого и обычного кода всего остального?
     
     
  • 4.107, www2 (??), 06:05, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    "Простой и обычный код" звучит как "обычный стиральный порошок". Не бывает такого кода, разве что в лабораторных работах у студентов.
     
     
  • 5.121, Аноним (-), 14:42, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это и должно так звучать. Код есть код и нечего его делить на код RAID, VM или еще какой.
     
     
  • 6.124, Michael Shigorin (ok), 15:34, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Код есть код и нечего его делить на код RAID, VM или еще какой.

    Что, серьёзно?  А вот для народа в lkml, помнится, страшнее VM бывал разве что tty.c ;-)

    Свой код тоже очень разный -- иной и через десять лет прозрачен, а иной не узнаёшь.  Ваш-то есть где посмотреть?

     
  • 5.132, fhunter (?), 16:20, 21/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "Простой и обычный код" звучит как "обычный стиральный порошок".
    > Не бывает такого кода, разве что в лабораторных работах у студентов.

    Вот не видели вы работ студентов. Там как раз код необычный (уж проще разбирать драйвер, чем некоторые их работы).

     
  • 3.116, Michael Shigorin (ok), 13:48, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > О, ты много знаешь людей способных понять код драйверов для RAID?

    С учётом того, что начинал его Мигель -- думаю, достаточно много.  Это всё-таки не VM...

     
  • 2.84, Аноним (-), 16:54, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В очередной раз миф о том, что открытые исходники позволяют найти ошибки развалился на глазах.

    Откуда вы такой отборный маркетинговый буллшит берете? От того что сорц посмотрит не только разработчик но и еще 100500 человеков - хуже не станет. А вот лучше - может. И багтрекеры багами заполнены явно не только от разработчиков. Врядли бы разработчики наколотили столько багов :)

     
     
  • 3.106, Аноним (-), 05:51, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да, только баги не от чтения исходников там, а от ой, мой рейд рассыпался при перезагрузке!
     
     
  • 4.117, Michael Shigorin (ok), 13:49, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да, только баги не от чтения исходников там, а от ой, мой
    > рейд рассыпался при перезагрузке!

    Баги багам рознь.  Бывают и [PATCH] с хорошим внятным разбором полётов впридачу.

     
  • 2.110, askh (ok), 13:18, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Разработчик нашёл ошибку. Вы из этого сделали вывод о том, что сообщество не может находить ошибки. Вам не кажется, что у вас проблемы с логикой?..

    Разработчик может найти ошибку, может её не найти. Кто-то из пользователей может найти ошибку, а может также её не найти. То есть возможны разные сценарии. Но вы, увидев реализацию одного из них, делаете вывод, что другой принципиально невозможен...

     

  • 1.4, Аноним (-), 11:30, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Во время чтения новости стало очень очень страшно!!!
     
  • 1.7, ааноним (?), 11:36, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я правильно понял, что если стоит gentoo-source-3.4.2-r1 то можно расслабиться?
     
     
  • 2.19, Анонище (?), 12:12, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно. Расслабляйся.
     
  • 2.134, Aleks Revo (ok), 17:37, 21/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Unstable система? "Расслабься и получай удовольствие" ))
     

  • 1.8, Guest (??), 11:41, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Если мое предположение верно, что "аппаратный RAID" является на самом деле програмным RAIDом, только с программой в ПЗУ, то выходит, что и аппаратные подвержены этой ерунде.

    И возможно, это и было причиной, по которой в течение года оба моих RAID-контроллера при включении компьютера вдруг забывали, что диски должны быть зазеркалированы и сбрасывали свои настройки.

     
     
  • 2.11, Аноним (-), 11:50, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер, и там могут быть разнообразные плюшки, вплоть до дополнительного питания носителей в том случае, если и основной источник питания, и даже бесперебойники откажут - все равно кэш на диски будет записан, а носители корректно остановлены. Что же до сохранности данных - тут раз на раз не приходится. У нас, например, был чудный аппаратный контроллер, после пары лет работы в массиве которого ЖД можно было просто выкидывать на помойку - они все были усеяны бэдами и областями затрудненного чтения. Не стали разбираться, что с ним - просто выкинули. Так что всякое бывает - где-то mdadm навернется, а где-то и аппаратный рейд. Мораль? Делайте бэкапы всегда.
     
     
  • 3.88, Dimez (ok), 17:02, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер, и там
    > могут быть разнообразные плюшки, вплоть до дополнительного питания носителей в том
    > случае, если и основной источник питания, и даже бесперебойники откажут -
    > все равно кэш на диски будет записан, а носители корректно остановлены.

    Можно пример такого контроллера? Потому-что обычно батарейка для сохранности данных в кэше.

     
     
  • 4.108, ACCA (ok), 07:50, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    EMC CLARiiON. В SPE там обычно пара таких.
     
  • 3.97, Аноним (-), 00:29, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер..

    По сути обычный программно-аппаратный комплекс "от производителя" с соответствующими гарантиями. Ошибки могут быть и в программной и в аппаратной части. Тут больше вопрос доверия/гарантий и предоставляемых возможностей. Вот интересно как контроллер мог повлиять на развитие бед блоков на ЖД. Вменяемых объяснений не вижу.

     
     
  • 4.102, mavriq (ok), 02:34, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот интересно как контроллер мог повлиять на развитие бед блоков на ЖД

    примерно аналогичным образом - http://forum.ixbt.com/topic.cgi?id=11:38813
    причем это не такая большая редкость, во всяком случае на дешевых материнках, когда контроллер тянет за собой hdd.

     
  • 2.24, ReWire (??), 12:40, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • –12 +/
    Конечно в аппаратных RAID массивах есть софт, а как же иначе? Другое дело что софт для этих контроллеров пишут не энтузиасты, а отдельные группы людей. Ну и многолетняя отладка... В итоге всё очень надежно. Ну и цена соответсвующая ;)

    В ноунейм контролерах и линуксах такого нет, поэтому потери данных или как у вас, забывали про массивы и диски. Зато недорого или даже бесплатно ;)  

     
     
  • 3.27, Аноним (-), 12:48, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы не поверите, но в линуксе рейд тоже пишут группы людей, и отлаживают много лет, и в результате все очень надежно.
    И если подобные ошибки проскакивают и в линуксе - то они точно так же могут оказаться и в любом аппаратном рейде. Особенно, если там прошит урезанный линукс, что случается очень часто.
     
     
  • 4.98, Аноним (-), 00:33, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы не поверите, но в линуксе рейд тоже пишут группы людей, и
    > отлаживают много лет, и в результате все очень надежно.
    > И если подобные ошибки проскакивают и в линуксе - то они точно
    > так же могут оказаться и в любом аппаратном рейде. Особенно, если
    > там прошит урезанный линукс, что случается очень часто.

    Зачем контроллеру RAID куча всякой х..ни, поддерживаемой линуксом и абсолютно бесполезной для такого рода задач? Приведите доказательства.

     
     
  • 5.125, Crazy Alex (ok), 17:57, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что дешевле вкрутить линукс чем разрабатывать свою фирмварь - по крайней мере до определённых масштабов производства.
     
  • 5.133, Maniaq (ok), 16:42, 21/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем контроллеру RAID куча всякой х..ни, поддерживаемой линуксом и абсолютно бесполезной
    > для такого рода задач? Приведите доказательства.

    Ну например для реализации графической управлялки контроллером, с шахматами и поэтессами...
    Не поверите в IBM 3560 торчит какой-то LSI SAS-RAID и там именно так и сделано. Для особо желающих можно загрузить CLI-утиль... И все это из фирмвары контроллера. Что у ней в потрохах - х.з. не ковырял, мне ни к чему...

     
  • 3.105, mavriq (ok), 02:41, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Другое дело что софт для этих контроллеров пишут не энтузиасты, а отдельные группы людей. Ну и многолетняя отладка... В итоге всё очень надежно.
    > В ноунейм контролерах и линуксах такого нет, поэтому потери данных или как у вас, забывали про массивы и диски

    то-то я смотрю - в оффтопОС все так прям и используют программный рейд. все потому-что над кодом работают "отдельные группы людей" и "В итоге всё очень надежно"
    Кстати, если-бы "забывание" дисков в mdadm было бы обычной ситуацией, как вы сейчас пытаетесь представить, об этом уже давно было бы известно, и это давно было бы пофикшено, а значит этого давно небыло бы.

     
  • 3.118, Michael Shigorin (ok), 14:06, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    формат данных на дисках пока не стандартизирован между различными поставщикам... большой текст свёрнут, показать
     
     
  • 4.122, rt (??), 14:43, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Миша, ты мой герой! )
     

  • 1.9, Аноним (-), 11:41, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Редко пользуемся убунтой на серверах (выбираем Debian и CentOS во имя стабильности), но даже там, где она используется, можно спокойно обновиться до 3.2.0-25. Ребутнуться пришлось, это да. Но не критично.
     
  • 1.10, Аноним (-), 11:50, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну зашибись блин, токо сделал файл-сервер на убунте с RAID-1, даже запустить не успел, а тут такие печеньки... Правильно я понял, что достаточно будет откатиться на ядро 3.0 ?
     
     
  • 2.28, AZ_from_Belarus (ok), 12:50, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ну зашибись блин, токо сделал файл-сервер на убунте с RAID-1, даже запустить
    > не успел, а тут такие печеньки... Правильно я понял, что достаточно
    > будет откатиться на ядро 3.0 ?

    В процессе штатного функционирования проблема не всплывает.

     
     
  • 3.30, Аноним (-), 12:51, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В процессе штатного функционирования проблема не всплывает.

    Только при выключении и перезагрузке, ага.

     
     
     
     
    Часть нити удалена модератором

  • 6.46, AZ_from_Belarus (ok), 13:51, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Массив остановлен, и мы его берём и повреждаем. Молодца!

    Читать надобно внимательней.
    "в частично собранном и остановленном состоянии"
    В русском языке союзы "и" и "или" в большинстве контекстов имеют различное значение. В данном контексте они как раз не совпадают и речь идет о выполнении обоих условиях.
    Надо постараться чтобы выполнить.

     
     
  • 7.71, Аноним (-), 14:47, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Из того же второго абзаца:
    "
    В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".
    "

    Тут наверное как раз говорится про обычные штатные механизмы завершения работы. Так что не словоблудьте. И не начинайте рассказывать что настоящие сервера у настоящих админов никогда не выключаются

     
     
  • 8.77, AZ_from_Belarus (ok), 15:33, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, конечно Такое тоже может быть Админ не дождавшись загрузки сервера резко ... большой текст свёрнут, показать
     
  • 2.38, Аноним (-), 13:14, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ...короче, обновил ядро до 3.4, автор пишет, что оно не подвержено багу. Да и вообще, т.к. сервак еще не запущен, то и терять было пока нечего. Но новость, конечно, не из приятных.
     

  • 1.15, rain87 (?), 12:00, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мда. жесть конечно. хорошо что я не стал обновлять домашнюю файлопомойку до новой убунты, на моём 2.6.38 как я понял бага нет
     
     
  • 2.56, Lain_13 (?), 14:09, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Там уже пофикшеное ядро в новой Убунте, да и ещё постараться нужно, чтоб сломать.
     
  • 2.112, ананим (?), 13:27, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уверены что у вас вообще рэйд есть?
     
     
  • 3.135, rain87 (?), 14:12, 25/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Уверены что у вас вообще рэйд есть?

    root@rain87gw:~# cat /proc/mdstat
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
    md0 : active raid5 dm-2[0] dm-1[1] dm-0[2]
          1953517952 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
          
    unused devices: <none>

    странный вопрос, я даже не понял - это такой тонкий^W толстый троллинг?

     

  • 1.23, Аноним (-), 12:35, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Ошибка возникает в ситуации, когда в процессе завершения работы массив находится в частично собранном и остановленном состоянии, что может возникнуть, например, при использовании команд "mdadm --incremental" или "mdadm -A". В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".

    Судя по всему, проблема специфична только для систем на базе upstart, т.е. Ubuntu и RHEL6 (с клонами).
    В sysvinit, systemd и openrc эти операции не распараллеливаются.

     
     
  • 2.29, Аноним (-), 12:50, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по всему, проблема специфична только для систем на базе upstart, т.е.
    > Ubuntu и RHEL6 (с клонами).

    Хотя нет, для RHEL тоже не специфична (они не стали бэкпортировать этот патч в свое ядро).
    Остается только убунта.

     
     
  • 3.39, Аноним (-), 13:16, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Судя по всему, проблема специфична только для систем на базе upstart, т.е.
    >> Ubuntu и RHEL6 (с клонами).
    > Хотя нет, для RHEL тоже не специфична (они не стали бэкпортировать этот
    > патч в свое ядро).
    > Остается только убунта.

    ...а в ней обновление до 3.2.0-25 в репах. Остается SLES?

     
     
  • 4.120, Аноним (-), 14:21, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ...а в ней обновление до 3.2.0-25 в репах. Остается SLES?

    SLES уже перевели на upstart?

     

  • 1.31, Егор (??), 12:59, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    часом не та ошибка, которая селектеловское облако клала?
     
     
  • 2.34, Ваня (??), 13:02, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет. Ту ещё не исправили.
     
     
  • 3.35, Егор (??), 13:07, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    печально
     
     
  • 4.85, Аноним (-), 16:57, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > печально

    Это Ваня. Рассматривайте его как генератор случайных чисел скрещенный с миллионом обезьян пишущий войну и мир (примерная схема-эквивалент, продуцирующая такой же бред на выходе).

     
  • 2.52, Аноним (-), 14:02, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >часом не та ошибка, которая селектеловское облако клала?

    Опередил :)

     

  • 1.36, Аноним (-), 13:09, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    В очередной раз стало ясно, что использовать дистрибутивы с красноглазыми ядрами себе дороже, только RHEL/CentOS/EL!
    Стремно на сервер ставить даже Debian/Ubuntu, но нет же, находятся "самородки", которые водружают туда Арч или даже Генту!

    Очень зря в SLE теперь не своя ветка, как раньше, а как у всех красноглазые большие номера ядер!

     
     
  • 2.41, AZ_from_Belarus (ok), 13:30, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Стремно на сервер ставить даже Debian/Ubuntu, но нет же, находятся "самородки", которые
    > водружают туда Арч или даже Генту!

    Вы полагаете, что разницы между дебиан и убунту нет? Ну-ну...

     
  • 2.42, Crazy Alex (ok), 13:34, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Дебиан-то чем не угодил в данном случае?
     
  • 2.92, RG (?), 22:51, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    :D

    Стрёмно на сервер ставить то, чем не умеешь управлять.

    Вот почему у меня под арчем отваливаются только бинарный видеодрайвер NVIDIA и медиаплеер, да и то иногда и на десктопе, а? :)

     

  • 1.45, AZ_from_Belarus (ok), 13:42, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Ошибка
    > проявляется только при перезагрузке, выключении или аварийном завершении работы. В процессе
    > штатного функционирования проблема не всплывает. Ошибка возникает в ситуации, когда в
    > процессе завершения работы массив находится в частично собранном и остановленном состоянии,

    И не ясно - ЧТО за народ поднял панику в комментах?
    Дисковый массив все же более характерен для сервака.
    Сервак предполагает все же что даже перезагрузку на нем выполняет не "марьиванна", а более-меннее админ. У более-менее админа, как бы предполагается, что сервак с серьезным содержимым сидит на бесперебойнике способном поддержать хотя бы корректное завершение работы.
    Админ у которого сервак при недособранном массиве может экстренно вылететь - мудак, а не админ. Если не мудак, то такое может произойти при диковинном стечении обстоятельств - например, именно в описанной ситуации накрылся бесперебойник + сбойнуло питание.

     
     
     
     
    Часть нити удалена модератором

  • 4.72, Аноним (-), 14:57, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да прочти ты уже наконец:
    "В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental". "


    Это штатное завершение работы, в котором тебе может повезти или не повезти (пересекутся два скрипта или нет)

     
     
  • 5.73, Аноним (-), 15:04, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    не дописал, вдогонку - ведь при обычной физической перезагрузке, которую ты только и подразумеваешь ("сбойнул бесперебойник + пропало электричество", про которые ты писАл выше), скрипты завершения выполняться не будут. Это и есть корректное завершение работы, которое на самом деле не всегда корректно - как повезет


     
  • 3.57, AZ_from_Belarus (ok), 14:10, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А паника из-за того что RAID "зеркало" собирают как раз для повышения
    > надёжности хранения данных, а не наоборот. Жаль что разработчики это не
    > до конца понимают.

    Для повышения надежности хранения данных предпринимается КОМПЛЕКС мероприятий одним из которых может быть и использование массива. Те, кто этого не понимает оказываются наказанными по жизни и могут сколь угодно долго лепить отговорки о ненадежности железа, линей, винды и т.д.

     
  • 2.50, Аноним (-), 14:00, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении работы может возникнуть описанное автором состояние, при котором и проявляется баг.
     
     
  • 3.69, Frank (ok), 14:38, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении
    > работы может возникнуть описанное автором состояние, при котором и проявляется баг.

    Это Вы не совсем поняли. В оригинале говорится, что баг словили только убунтушники, из-за того что в ней при загрузке делается incremental assembly по udev rules 85-mdadm.rules, в результате чего и становилось возможным через этот баг повреждение метаданных, если перезагрузка происходила раньше, чем массив полностью собирался.

     
     
  • 4.74, AZ_from_Belarus (ok), 15:12, 19/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, в целом так Кстати русский сабж довольно корректно и по существу описал сит... большой текст свёрнут, показать
     
  • 4.95, Аноним (-), 00:26, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении
    >> работы может возникнуть описанное автором состояние, при котором и проявляется баг.
    > Это Вы не совсем поняли. В оригинале говорится, что баг словили только
    > убунтушники, из-за того что в ней при загрузке делается incremental assembly
    > по udev rules 85-mdadm.rules, в результате чего и становилось возможным через
    > этот баг повреждение метаданных, если перезагрузка происходила раньше, чем массив полностью
    > собирался.

    А где Вы в моем посте углядели отрицание того, "что баг словили только убунтушники". Отличный стиль вести дискуссию - выдумать аргумент оппонента и с пеной у рта его опровергать. К тому же писал я вовсе не Вам...

     
     
  • 5.109, Frank (ok), 08:08, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А где Вы в моем посте углядели отрицание того, "что баг словили
    > только убунтушники". Отличный стиль вести дискуссию - выдумать аргумент оппонента и
    > с пеной у рта его опровергать. К тому же писал я
    > вовсе не Вам...

    Так будьте бобры в следующий раз не говорить с недоговорками. Есть чёткое определение когда проявляется баг: остановка частично собранного активированного массива, и всё.

     

  • 1.51, Аноним (-), 14:01, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не на эту ли ошибку напоролся в свое время Selectel?
     
  • 1.83, Аноним (-), 16:44, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня стоял kernel 3.3.3 на slackware 13.37 x86_64 и программный RAID0
    Множество раз перезагружал/выключал, а так же сбои от света и т. д. - выжил.
    Сейчас пересобрал новое ядро 3.4.3.
    Всё работает так же.
    Единственное, что, так это VirtualBox не собирал модули ядра, пришлось линк поставить на один include файл, видать место положение этого файла сменилось в новом ядре.

     
     
  • 2.119, Michael Shigorin (ok), 14:13, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня стоял kernel 3.3.3 на slackware 13.37 x86_64 и программный RAID0
    > Множество раз перезагружал/выключал, а так же сбои от света и т. д. - выжил.

    Так если RAID0, целостность данных всё равно имеет весьма условное значение -- с учётом того, что винчестеры уж лет пятнадцать как пытаются стать расходниками. :(

     
     
  • 3.126, Crazy Alex (ok), 18:04, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну... Они, конечно, пытаются, но не то чтобы очень успешно. Во всяком случае я не вижу чтобы отказов было больше сейчас чем лет 10 назад. Скорее уж наоборот - тогда те же самсунги были "чудесны", да и эпичные проблемы с "дятлами" и фуджиками вспоминаются.
     

  • 1.100, iZEN (ok), 01:16, 20/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Да уж! Как вам только живётся в прошлом веке с деревянными игрушками, линуксоиды... ZFS так не тупит./thread
     
     
  • 2.113, ананим (?), 13:30, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А как она тупит?
    6мв/с?
    Да уж лучше сабж с багом.
     
     
  • 3.114, ыгчч (?), 13:41, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А как она тупит?

    Бывает что и сильно. Но не так сильно как iZen :)

     
     
  • 4.123, ананим (?), 14:55, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну... любая технология работает в связке технология-человек.
    но кто-то упорно утверждает, что:
    — "этавон_панацея" в человеке не нуждается. тут так удобно, сухо и тепло.
     
  • 2.130, AlexAT (ok), 20:26, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Танцы на 20см гвоздях, стоя на голове, тоже могут приводить к повреждению мозга.
     

  • 1.127, Аноним (-), 18:30, 20/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что за opennet, если не дают слово без регистрации.
     
     
  • 2.128, Michael Shigorin (ok), 18:47, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за opennet, если не дают слово без регистрации.

    Надеюсь, Вы гостеприимны, но при этом не позволите у себя дома бесчинствовать.  Насколько понимаю здешние правила -- примерно так же.

     
     
  • 3.129, Аноним (-), 19:19, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь все стало понятно.
     
  • 3.131, ананим (?), 21:10, 20/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а с другой стороны, если знакомый достаточны близкий (зарегистрированный), то можно? :D
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру