» Все о железячном RAID

alexpowermetal

Цитата:

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

RAID 0. Итоговые результаты - скидывать на другой винт.
PS: какой хоть контроллер?

TRANTOR
Да нормальные винты.
Эверестом тоже все пучком.
Кстати, температура на WD 2500 YS - 23
А на старом (WD 2500 YD) - 52
Может из-за того, что я на старый установил систему, а YS - как загашник.
А может NCQ даёт о себе знать.


Цитата:

RAID 0. Итоговые результаты - скидывать на другой винт.

Точно, что не помешает

Xeonc_II

Цитата:

А на старом (WD 2500 YD) - 52

это глюки термодатчика.

Xeonc_II
А данные СМАРТа из Эвереста можно узреть?

Цитата:

А данные СМАРТа из Эвереста можно узреть?

Не всегда. Но в большинстве случаев можно. Скачай, запусти и станет ясно.
Следил, да не уследил. Сорри.

FrontMan
Это была просьба к Xeonc_II выложить данные СМАРТа из Эвереста по подозрительному харду. За дискуссией следим или лишь бы просто так что-нить написать?

vertex4
Материнка: MSI Ms-7356 (v1.x)
RAID контроллер: Intel ICH9R SATA RAID


Цитата:

RAID 0. Итоговые результаты - скидывать на другой винт.

Что ты имелл в виду, я не понял.

alexpowermetal

Цитата:

Что ты имелл в виду, я не понял.

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

TRANTOR
Вы были правы. Есть проблемы с винтом - периодически отваливается
Но тест Эверестом проходил !? Сейчас не могу выложить скрин, т. к. снова отвалился и система его не видит.
Слава Богу, хоть ось поставил на старый винт.
Что этот гад хочет? Ставил его и мастером, и слейвом - проблемы остаются.
Может дело в питании? У меня корпус CHIEFTEC LCX-01 с БП GPS-400AA-101A - выход на два винта на одном шлейфе. Но со старым YD не было проблем ни разу.
Наверное проблемы с винтом, или всё таки руки?

Xeonc_II

Цитата:

Есть проблемы с винтом - периодически отваливается

Ну вот - корень зла найден.

Цитата:

корпус CHIEFTEC LCX-01

Лично я несколько раз наблюдал проблемы с питанием Чифтеков (в том числе испытал как-то и на себе - питало сдохло и унесло с собой мать). Советую заменить питало.

Здраствуйте уважаемые рубордцы. Обращаюсь к Вам за советом что делать в моей безнадежной ситуации.
Суть вопроса такова:
Жили были 3 SATA винта по 500 гигов в 5ом рейдике на LSI контроллере. Тут понадобилось добавить еще 4 винта по 500 гигов. Долго не раздумывая я установил в корзину винты, включился и полез в бивис контроллера. Там я к сожалению их не увидел в ONLINE режиме. Ничего другого в голову мне не пришло в то время как попробовать поменять местами работающий винт с новым, который не завелся и я нагорячую их поменял находясь в бивисе контроллера. Изучив похожие топики я понял что это был ой как напрасно... В общем сервер подвис после рефреша. Я выключил серво, вернул все на место, вынул 4 винта которые нужно было добавить, загрузился - контроллер запищал о том, что один из рабочих винтов FAILED. Бился долго и мучительно пытаясь запустить его, в итоге черт меня попутал или мозг клин словил от этого писка и я в горячах сделал CLEAR CONFIGURATION......................... Далее сконфигурил заново тот же массив, разобрался с новыми винтами и рядом создал еще один 5ый рейд из таких же 3 винтов, поставил на него систему и сейчас поставил сканирование первого рейда при помощи R-Studio.... Что-то находит, но боюсь увидеть результаты сканирования.....
Натворил делов, сам понимаю... Но все же, какова вероятность восстановления информации? Чем еще можно попробовать восстановить инфу? Или как?
Заранее благодарю всех откликнувщихся на призыв о помощи.

DeH

Цитата:

Но все же, какова вероятность восстановления информации?

Она довольно низка.

Все эти действия, конечно, проделаны очень зря. Кроме того, что контроллеры LSI тормозные, они еще и довольно "веселые", как оказывается. Советую поменять сей контроллер на какой-нить более вменяемый, например 3ware, Areca, Adaptec. И, разумеется, так больше никогда не делать и вообче перед любыми действиями с массивом делать бэкап.

А вообще - надо смотреть. Если не делали consistensy check, или если делали, то с теми же винтами и теми же параметрами массива (а чек мог запуститься автоматически без предупреждения, посмотреть можно в BIOS'е контроллера в пункте, где есть что-нибудь про background activity, или что-то подобное) , то восстановить инфу можно. Но к контроллеру желательно не подключать, а собирать массив программно. Лучше, естесственно, силами специалистов по восстановлению инфы.

Елки палки, тыкал все что можно, в том числе и consistensy check, но не помню когда.. до или после дропа конфы..

Главное, чтобы чек делался с теми же винтами, и тоже в 5-м RAID'е. XOR в этом случае все равно должен был сходиться в любых сочетаниях, и инфу это не испортило бы. Вот если делали, заменив один из винтов - тогда все, можно больше не мучаться.

Ребят, может софт какой толковый наподобии R-Studio еще посоветуете?

DeH

Цитата:

наподобии R-Studio еще посоветуете?

Да вроде это наиболее известный из всех известных.

LeoT
Наверное имеется в виду не консистенси чек, а ребилд? Какой уж тут чек, когда массив в дегрейде. Хотя, в случае приличного контроллера, ребилд бы прошел с новым хардом и все было бы нормально. А вот если хард (любой) был вытащен во время ребилда, то всё: капут.

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

LeoT

Цитата:

ставят в онлайн давно отвалившийся диск

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


Цитата:

А на самом деле это перезапись всех XORов по кругу на всех дисках.

Это не совсем так. В продвинутых контроллерах, помимо инфы и ксора пишутся еще некие дополнительные контрольные суммы, которые позволяют в случае сбойных секторов восстановить инфу (или ксор), определить - где неверный ксор, а где неверная инфа. Иначе восстанавливая по неверной инфе (к примеру сбойный сектор, помеха на шине, итд) получаем неверный ксор. К чему это приведет - надеюсь понятно. А в случае неверного, сбойного ксора - получаем неверную инфу. Т.е., по идее, при отсутствии инфы (и этих дополнительных контрольных сумм) на чистом диске он должен был бы восстановиться из имеющихся ксоров, т.е. должен был бы произойти аналог ребилда. А тут этого не произошло. Значит контроллер несколько "глупее", чем нужно, и он не пишет этих контрольных сумм или их пишет мало. Отсюда и результат, как я понимаю.

Цитата:

В продвинутых контроллерах, помимо инфы и ксора пишутся еще некие дополнительные контрольные суммы,

Куда они пишутся? Ни разу ничего подобного не видел. Это же как минимум карта должна быть немаленькая где-то за пределом пользовательского объема, а максимум - еще один диск.
На чистом диске отсутствует конфигурационная инфа контроллера, по которой он и определяет, что диск заменен.

LeoT

Цитата:

Куда они пишутся?

Достоверно не знаю, но знаю, что пишутся. Рискну предположить, что к примеру на один блок страйпа 1, наример, байт контрольной суммы или даже меньше - байт CRC на 2 или 4 страйпа.


Цитата:

Это же как минимум карта должна быть немаленькая где-то за пределом пользовательского объема, а максимум - еще один диск.

Не такая уж и большая. [more=Вот, набросал просчет размера области контрольной суммы для своего массива]
Код: Лун, номер           Объем, байт     
1              751 617 826 816     
2              2 048 300 318 720     
Всего              2 799 918 145 536     
        
Харды, шт         
1              400 000 000 000     
8             3 200 000 000 000     
7              2 800 000 000 000     
        
разница             81 854 464     
        
страйп             16 384          65 536
колво страйпов полезных    170 893 442     42 723 360
колво страйпов по идее     170 898 438 42 724 609
        
CRC на 1 страйп         170 893 442      42 723 360
CRC на 2 страйпа         85 446 721      21 361 680
CRC на 4 страйпа          42 723 360       10 680 840

Подскажите: есть два диска 7200.10 и контроллер PCI-E на Sil3132, воткнул диски в контроллер, в биосе контроллера создал рэйд 1, вставил диск с виндовс, через ф6 добавил драйвера, а виндовс пишет, что не находит диски и прерывает установку, что я не так делаю?

TRANTOR:
Буду смотреть на попадающихся массивах, есть ли там что похожее на эти дополнительные CRC. Штука полезная, если она там есть, с некоторыми неоднозначными случаями позволит быстрее разбираться...

Появились несколько вопросов по рейдам, поиск юзал и здесь, и в гугле - но ничего конкретного, ясного и чёткого не нашёл. Может быть здешние спецы подскажут что к чему. Речь будет идти только о RAID 1, все опыты проводились на nForce 570, где находится рейд-контроллер MediaShield. При создании массива RAID 1 нужно указать диски для объединения, после чего он спрашивает - удалить все данные с дисков или нет. Если нажать нет, данные остаются, а далее можно выбрать какой диск ребилдить - если выбираем второй, то в фоне при работе компа данные копируются с первого на второй винт - с этим вопросов не возникает (рассказываю для понимания общей картины). Уже в самой винде в утилитке управления рейдом есть две опции восстановления: собственно восстановление (ребилд, аналогичная опции ребилда в биосе) и синхронизация. При восстановлении нужно выбрать диск, который нужно ребилдить, а при синхронизации просто происходит операция, по времени равная ребилду, но ничего не выбирается.

1. Чем конкретно отличается восстановление от синхронизации? Если (предполагаю) синхронизация - это тот же ребилд, но сбойный диск определяется самим контроллером, то по какому принципу выбирается диск-источник? Ведь как восстановление, так и синхронизация доступны и работают даже когда оба диска массива находятся в исправном состоянии. Тем более дело осложняет второй вопрос.

Некоторые программы, которые работают с дисками напрямую, не видят рейда, даже если винты в него объединены и в винде он работает как нормальный рейд. Например программа HDClone увидит два диска, с каждым из которых можно работать в отдельности. Допустим помимо массива мы поцепим третий винт (то есть из винды будет видно рейд как один массив и наш третий винт как просто винт, а в HDClone мы увидим три винта), и с помощью данной программы склонируем один из разделов с третьего отдельного винта на один из разделов второго винта из рейда. Контроллер аппаратный, но не препятствует таким операциям. После этого данные первого винта в рейде уже будут отличаться от данных второго. Или другой пример - мы можем просто расформировать рейд-массив, изменить часть данных на втором винчестере и обратно объединить их в рейд - контроллер позволяет делать это без потери данных. При чём в обоих случаях контроллер будет говорить что рейд исправен.

2. Как будут реагировать на рейд после таких операций винда или программы, которые видят именно рейд, а не два отдельных винта? С каким из двух винтов они будут работать и откуда будут считываться данные? При синхронизации - первый винт скопируется на второй, или второй на первый - и почему?

Вот пока основные вопросы, хотелось бы лучше разобраться в работе рейда-1, чтобы дальше было меньше неожиданностей

simplix

Цитата:

Чем конкретно отличается восстановление от синхронизации?

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


Цитата:

Контроллер аппаратный

Это не так. Он полуаппаратный, на 90% он программный.


Цитата:

Некоторые программы, которые работают с дисками напрямую, не видят рейда

Это потому, что он полуаппаратный. В моем случае, любые проги видят два диска, которые ЛУНы массива.


Цитата:

С каким из двух винтов они будут работать и откуда будут считываться данные?

Это зависит от того, как реализована работа с массивом в дровах. Как именно она реализована в данном случае - загадка.

TRANTOR

Спасибо за ответ.


Цитата:

В случае консистенси чека мы еще ничего не знаем и контроллер пытается определить, все ли в порядке.

Если я правильно понял, то операция синхронизации должна 1) определить сбойный диск, 2) самостоятельно не вносить изменения, 3) показать, где находятся различающиеся данные, 4) предложить варианты восстановления данных (например какой диск на какой копировать, или часть предполагаемого рабочего диска на соответствующую часть другого)? Укажите плиз, какие именно из этих предположений не совпадают с действительностью


Цитата:

Это не так. Он полуаппаратный, на 90% он программный.

Под аппаратным имелся в виду контроллер на материнке, в том смысле что в отличие от него программный создаётся только средствами операционной системы.

Цитата:

1) определить сбойный диск

По идее - да.


Цитата:

2) самостоятельно не вносить изменения

Не факт. Зависит от политики конкретного контроллера.


Цитата:

3) показать, где находятся различающиеся данные

Не обязательно. Может и просто сказать, что что-то не в порядке, а может и пофиксить.


Цитата:

4) предложить варианты восстановления данных (например какой диск на какой копировать, или часть предполагаемого рабочего диска на соответствующую часть другого)?

Ну это как получится. Точнее, опять же, зависит от политики конкретного контроллера.


Цитата:

в том смысле что в отличие от него программный создаётся только средствами операционной системы.

А этот создается дровами и чипом. Считает все равно основной камень. И в случае какого-то сбоя (что не редкость) все может быть очень грустно.

Цитата:

зависит от политики конкретного контроллера.

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

Добавлено:
simplix
Есть подозрение, что в Вашем контроллере при синхронизации просто всегда источником выбирается один и тот же диск.

TRANTOR

Цитата:

А этот создается дровами и чипом. Считает все равно основной камень.

Какая разница, в чипсете материнки находится контроллер рейда, или на pci-плате - они организованы аппаратно, и тот и другой требует дрова, оба общаются с процом и оба (опять же зависит от контроллера) производят вычисления. Это к тому что не имеет значения где стоит чип, на материнке или отдельной плате, функциональность контроллера от расположения не пострадает - другое дело что встроенных в материнки высокопроизводительных контроллеров не делают (смысла нету, кому нужно - купят отдельной платой). В программной реализации рейда вся нагрузка ложится на проц, а в аппаратной может быть и так и сяк, но по крайней мере после объединения в рейд двух винтов на nForce 570 (контроллер MediaShield) никакой дополнительной нагрузки на проц я не зафиксировал даже при ребилде или синхронизации, чем и объясняю аппаратную реализацию.

LeoT

Цитата:

И уж совсем фантастика - ждать от контроллера какого-то анализа пользовательской инфы.

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


Цитата:

Есть подозрение, что в Вашем контроллере при синхронизации просто всегда источником выбирается один и тот же диск.

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

По поводу фантастики - такого (сравнить и показать) нет и на "самых навороченных" контроллерах, все молча копируют или XOR'ы переписывают. А тут - интегрированный "недоконтроллер". Их главный минус - то, что они являются "бесплатным приложением" к МВ, сделаны не для работы, а "чтобы было". И фирмварь их также по остаточному принципу написана, кое как работает - и ладно. Там и общеупотребительных фичей многих нет, не то что какого-то дополнительного сервиса...
Как проверить, какой диск куда пишется - например, внести на один изменения, синхронизировать и посмотреть. Потом повторить, с изменениями на другом диске.