SRSU42X RAID10 RedHat замена HDD MaxtorIV на V.

[gim]

Есть массив RAID10, на котором запущен RedHat. Нужно поменять HDD MaxtorIV 147Gb (износ) на MaxstorV 146Gb. В документации на SRCU42X сказано, что уменьшить размер тома нельзя. Предположим, что размер раздела из-под RedHat уменьшу. Можно ли уменьшить каким-то образом на столько же размер тома RAID-а (с любой стороны) ? Или всё-таки перезаливка машины ?

[gs]

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

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

[gim]

Добрый день !
Бсспорно, что эти вещи разные. Многочисленные попытки отыскать способ уменьшить RAID-том пока не увенчались успехом. Проблема как раз в том, что при "закладке" массива (года 2 назад) предшественником опция "coercion size" была переведена с 1Gb на "none" (от жадности ?). Теперь, когда некоторые диски начали "высыпаться" из массива, стало весьма проблематично найти подходящие диски для ребилда в он-лайне (впрочем, в офф-лайне та же петрушка будет). Размер раздела операционки худо-бедно уменьшить можно, но тайные тропы вендора по уменьшению RAID-тома в розыске.
Конечно, перелить систему на новый сервер проще (и даже лучше), можно обновить платформу, но... система real-time; перерыв для перезаливки - пару дней плотной работы, что непозволительно. (Ждём, как всегда, пока всё не рухнет.) Если какая-то мысль или новость проскочит, буду признателен, ежели шепнёте.
По поводу SRCU41L с новой прошивкой: я в восторге. Жаль, уменьшать нельзя, зато любые расширения в он-лайне без приостановки сервиса на "Ура!"

" ... и воззвал он к богам Олимпа..." Аминь, т.е. Enter.

[gs]

Уменьшение размера массива невозможно ни на одном из известных мне контроллеров. Суть проста - контроллер понятия не имеет какие данные где лежат. Поэтому полагает, что они лежат везде. Точка.

[gim]

Что да, то - да. Однако по инженерным трекам почтенной публике тоже не дозволительно шастать. Только просвещённым. Полагаю, что сие может распространиться и на RAID. Али мои познания малы, али заблуждения велики?
Рассуждая логически предполагаю, что уменьшив данные ОС (типа Acronis и иже им подобных) на N блоков, и даже на N+n пуще запаса, и, загодя полазив в скрытых от пользовательских глаз байто-ячейках сего контроллера, можно приуменьшить на N и размер RAID-тома. Ему-то какая разница? В конце концов спасение байтов операционки - дело рук (менеджеров, сервисов...) самой операционки. Вот и живу с такой мыслью об Иване Сусанине недр RAID-овских...
К сожалению, пока не наткнулся на какие-либо писания вендоров либо им подобных энтузазистов. Буду благодарен, ежели бросите какие-либо ссыли на описания форматов системных зон RAID-дисков, чтобы можно было побайтно полазить (в духе DiskEditor...). Бывали случаи, когда контроллер не-Intel помирал, а Intel - "нихт ферштейн, формат не знайт".

[gs]

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

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

[gim]

Класс !!! Попробую на тестовой машине.

Впечатление правильное, за малым исключением. Толкают на них. Полубоги просят чуда. А пять раз не получится за это время: массив почти на Тб. Создавался трудами непосильными, базы наполнял широченные, апплеты прикручивалися хитрющие, мужи-авторы уже далече...

Не буду злоупотреблять Вашим вниманием, бородатый анекдот под занавес. Вышел молодец на развилку трёх дорог, читает на камне: "Прямо пойдёшь - по башке получишь, налево пойдёшь - по башке получишь, напрво пойдёшь - по башке получишь." Стоит башку чешет. Внутренний голос: "Думай быстрее, а то по башке получишь".

Думаю, топик можно закруглить, но если будут ссылочки.... 8(

[gs]

Ну Вы блин даете!
1. Фуллбэкап ntbackup'ом (впрочем он у Вас уже должен быть в любом случае).
2. Инит новых винтов - пара часов.
3. Инсталл системы - полчаса.
4. Рестор.
Делов на день (ночь) - не больше.

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

[gim]

Если бы винда... Вопросов бы было меньше. А то ведь RedHat Linux Ent со своими SQL-ми, примочками, базейками своего формата (обращаются непосредственно по абсолютному номеру сектора) и т.п. и т.д. Отразно, что не висят в самом хвосте. Как себя поведёт - ХЗ. В иных случаях и мечтаешь о винде......

Раскланиваюсь уважительно.

[gs]

База обращается к секторам???
Не, возможно так надо, но я реально балдею

[gs]

А что бэкап такой машины не сделать никак? И как тогда Вы без него живете? Ведь если банально подохнет - что делать-то будете?

[gim]

Из-за скорости, из-за неё окаянной.
А как я балдею без нагана...
В конце-концов ежели рухнет, всё меньше, чем 11 сентября.
И даже никто не умрёт, не сядет. Просто родится новая система.

[gim]

Бэкап..? Есть точно такая же машина, синхронизированная, горячий резерв то бишь. "Есть два бассейна, в них втекает и никуда не вытекает", даже в отстойник. Ещё на пару-тройку лет хватит...

[gs]

Ну так может того - перезалить обычным бэкапом систему и софт, а базу засинхронизировать со второй машины, раз механизм уже налажен?

[gim]

Рассматривался и этот вариант, как крайний (когда рухнет "один из близнецов"). Пока не дозволяют - не могу дать гарантий, что клон получится. Скорее всего будет обновление машин через год, когда гарантия иссякнет. Либо когда рухнет... Либо - ДМБ, и "проблемы негров шерифа не волнуют".