[Sysadmins] Собрать raid после сбоя и перезагрузки

[Sysadmins] Собрать raid после сбоя и перезагрузки

[Денис Ягофаров]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

Доброго времени суток.

Создал raid массив:
mdadm  --create /dev/md0 --level=10  --name=test10 --raid-devices=4 
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

Потом один из дисков (тестово) полетел...
mdadm --manage /dev/md0 --fail /dev/sdb1

Добавил другой вместо него (вынутый-вставленный "полетевший"):
mdadm --manage /dev/md0 --add /dev/sde1

Массив перестроился.

После этого перезагрузился. Устройство /dev/md0 есть, массива нет.
# chkconfig --list | grep mdadm
mdadm           0:off   1:off   2:off   3:off   4:off   5:off   6:off

Собираю руками:
# mdadm --assemble /dev/md0 --scan
mdadm: no devices found for /dev/md0

В конфиге:
DEVICE /dev/sd[a-d]1
ARRAY /dev/md0 level=10 num-devices=4 
UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
MAILADDR root
PROGRAM /sbin/mdadm-syslog-events

Как мне собрать массив?


[-- Attachment #2: denyago.vcf --]
[-- Type: text/x-vcard, Size: 281 bytes --]

begin:vcard
fn:Denis Timurovich Yagofarov
n:Yagofarov;Denis Timurovich
org:ITGIS NASU
adr:room 615;;Chokolovski blvdr., 13;Kiev;;03151;Ukraine
email;internet:denyago@rambler.ru
title:system administrator
tel;work:80442480755
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Денис Ягофаров]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

Всё, что есть в логах:

Oct 24 11:23:42 localhost kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, 
MD_SB_DISKS=27
Oct 24 11:23:42 localhost kernel: md: bitmap version 4.39
...
Oct 24 11:23:44 localhost kernel: device-mapper: ioctl: 4.7.0-ioctl 
(2006-06-24) initialised: dm-devel@redhat.com
Oct 24 11:23:44 localhost kernel: md: md0 stopped.


[-- Attachment #2: denyago.vcf --]
[-- Type: text/x-vcard, Size: 281 bytes --]

begin:vcard
fn:Denis Timurovich Yagofarov
n:Yagofarov;Denis Timurovich
org:ITGIS NASU
adr:room 615;;Chokolovski blvdr., 13;Kiev;;03151;Ukraine
email;internet:denyago@rambler.ru
title:system administrator
tel;work:80442480755
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Alexey Shabalin]

24 октября 2008 г. 12:33 пользователь Денис Ягофаров написал:
> Доброго времени суток.
>
> Создал raid массив:
> mdadm  --create /dev/md0 --level=10  --name=test10 --raid-devices=4
> /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
>
> Потом один из дисков (тестово) полетел...
> mdadm --manage /dev/md0 --fail /dev/sdb1
>
> Добавил другой вместо него (вынутый-вставленный "полетевший"):
> mdadm --manage /dev/md0 --add /dev/sde1
>
> Массив перестроился.
>
> После этого перезагрузился. Устройство /dev/md0 есть, массива нет.
> # chkconfig --list | grep mdadm
> mdadm           0:off   1:off   2:off   3:off   4:off   5:off   6:off
>
> Собираю руками:
> # mdadm --assemble /dev/md0 --scan
> mdadm: no devices found for /dev/md0
>
> В конфиге:
> DEVICE /dev/sd[a-d]1
может ошибаюсь, но Вы же добавили диск sde. А в конфиг он не попадает.

> ARRAY /dev/md0 level=10 num-devices=4
> UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
> MAILADDR root
> PROGRAM /sbin/mdadm-syslog-events
>
> Как мне собрать массив?


-- 
Alexey Shabalin

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Денис Ягофаров]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Alexey Shabalin пишет:
> 24 октября 2008 г. 12:33 пользователь Денис Ягофаров написал:
>   
>> Доброго времени суток.
>>
>> Создал raid массив:
>> mdadm  --create /dev/md0 --level=10  --name=test10 --raid-devices=4
>> /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
>>
>> Добавил другой вместо него (вынутый-вставленный "полетевший"):
>> mdadm --manage /dev/md0 --add /dev/sde1
>>
>> Собираю руками:
>> # mdadm --assemble /dev/md0 --scan
>> mdadm: no devices found for /dev/md0
>>
>> В конфиге:
>> DEVICE /dev/sd[a-d]1
>>     
> может ошибаюсь, но Вы же добавили диск sde. А в конфиг он не попадает.
>   
sde стал после перезагрузки sdb.... (т.к. полетел sdb, его "вытащили", 
затем "вставили" новый, он стал sde)

пробую так:
# mdadm --assemble /dev/md0 --run -v
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdd1 has wrong uuid.
mdadm: /dev/sdc1 has wrong uuid.
mdadm: /dev/sdb1 has wrong uuid.
mdadm: /dev/sda1 has wrong uuid.
mdadm: no devices found for /dev/md0

# blkid
/dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
TYPE="ext3"
/dev/hda1: UUID="7deb64be-1be5-49dc-9e0f-4ac9381173f2" SEC_TYPE="ext2" 
TYPE="ext3"
/dev/sdc1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
/dev/sdd1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
/dev/sdb1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"

в конфиге:
DEVICE /dev/sd[a-d]1
ARRAY /dev/md0 UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
MAILADDR root
PROGRAM /sbin/mdadm-syslog-events

П.С. А как бы я собирал массив из дисков на сервере В, если на сервере А 
полетел контроллер и на В они (диски) опознались по другим именам?


[-- Attachment #2: denyago.vcf --]
[-- Type: text/x-vcard, Size: 269 bytes --]

begin:vcard
fn:Denis Timurovich Yagofarov
n:Yagofarov;Denis Timurovich
org:ITGIS NASU
adr:room 615;;Chokolovski blvdr., 13;Kiev;;03151;Ukraine
email;internet:denyago@rambler.ru
title:system administrator
tel;work:80442480755
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Денис Ягофаров]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

Денис Ягофаров пишет:
> Alexey Shabalin пишет:
>> 24 октября 2008 г. 12:33 пользователь Денис Ягофаров написал:
>>  
>>> Доброго времени суток.
>>>
>>> Создал raid массив:
>>> mdadm  --create /dev/md0 --level=10  --name=test10 --raid-devices=4
>>> /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
>>>
>>> Добавил другой вместо него (вынутый-вставленный "полетевший"):
>>> mdadm --manage /dev/md0 --add /dev/sde1
>>>
>>> Собираю руками:
>>> # mdadm --assemble /dev/md0 --scan
>>> mdadm: no devices found for /dev/md0
>>>
>>> В конфиге:
>>> DEVICE /dev/sd[a-d]1
>>>     
>> может ошибаюсь, но Вы же добавили диск sde. А в конфиг он не попадает.
>>   
> sde стал после перезагрузки sdb.... (т.к. полетел sdb, его "вытащили", 
> затем "вставили" новый, он стал sde)
>
> пробую так:
> # mdadm --assemble /dev/md0 --run -v
> mdadm: looking for devices for /dev/md0
> mdadm: /dev/sdd1 has wrong uuid.
> mdadm: /dev/sdc1 has wrong uuid.
> mdadm: /dev/sdb1 has wrong uuid.
> mdadm: /dev/sda1 has wrong uuid.
> mdadm: no devices found for /dev/md0
>
> # blkid
> /dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
> TYPE="ext3"
> /dev/hda1: UUID="7deb64be-1be5-49dc-9e0f-4ac9381173f2" SEC_TYPE="ext2" 
> TYPE="ext3"
> /dev/sdc1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> /dev/sdd1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> /dev/sdb1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
>
> в конфиге:
> DEVICE /dev/sd[a-d]1
> ARRAY /dev/md0 UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
> MAILADDR root
> PROGRAM /sbin/mdadm-syslog-events
>
> П.С. А как бы я собирал массив из дисков на сервере В, если на сервере 
> А полетел контроллер и на В они (диски) опознались по другим именам?
смог запустить mdadm -A /dev/md0 /dev/sd[a-d]1

но что ему в конфигурации не нравится?

[-- Attachment #2: denyago.vcf --]
[-- Type: text/x-vcard, Size: 269 bytes --]

begin:vcard
fn:Denis Timurovich Yagofarov
n:Yagofarov;Denis Timurovich
org:ITGIS NASU
adr:room 615;;Chokolovski blvdr., 13;Kiev;;03151;Ukraine
email;internet:denyago@rambler.ru
title:system administrator
tel;work:80442480755
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Konstantin A. Lepikhov]

Hi Денис!

Friday 24, at 01:56:58 PM you wrote:

<skip>
> sde стал после перезагрузки sdb.... (т.к. полетел sdb, его "вытащили", 
> затем "вставили" новый, он стал sde)
> 
> пробую так:
> # mdadm --assemble /dev/md0 --run -v
> mdadm: looking for devices for /dev/md0
> mdadm: /dev/sdd1 has wrong uuid.
> mdadm: /dev/sdc1 has wrong uuid.
> mdadm: /dev/sdb1 has wrong uuid.
> mdadm: /dev/sda1 has wrong uuid.
> mdadm: no devices found for /dev/md0
> 
> # blkid
> /dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
> TYPE="ext3"
> /dev/hda1: UUID="7deb64be-1be5-49dc-9e0f-4ac9381173f2" SEC_TYPE="ext2" 
> TYPE="ext3"
> /dev/sdc1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> /dev/sdd1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> /dev/sdb1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> 
> в конфиге:
> DEVICE /dev/sd[a-d]1
> ARRAY /dev/md0 UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
> MAILADDR root
> PROGRAM /sbin/mdadm-syslog-events
После замены диска mdadm перестроил массив, изменив при этом его  uuid,
чтобы нельзя было добавить не то диск. А в конфиге у вас указан масссив со
старыми uuid'ами. Собственно, не совсем понятно, чем вы удивлены и на
какое поведение вы расчитываете.


> 
> П.С. А как бы я собирал массив из дисков на сервере В, если на сервере А 
> полетел контроллер и на В они (диски) опознались по другим именам?
что значит "опознались по другим именам"?

-- 
WBR et al.

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Maks Re]

> После замены диска mdadm перестроил массив, изменив при этом его  uuid,
> чтобы нельзя было добавить не то диск. А в конфиге у вас указан масссив со
> старыми uuid'ами. Собственно, не совсем понятно, чем вы удивлены и на
> какое поведение вы расчитываете.

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

вот если мы сами перестроили массив, с потерей всей информации, тогда
понятно появление нового uuid...

-- 
С уважением,
  Макс.

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

"Maks Re" <admaks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

>> После замены диска mdadm перестроил массив, изменив при этом его  uuid,
>> чтобы нельзя было добавить не то диск. А в конфиге у вас указан масссив со
>> старыми uuid'ами. Собственно, не совсем понятно, чем вы удивлены и на
>> какое поведение вы расчитываете.
>
> непонятно вот что
> почему, при добавлении диска взамен неисправного, перестроился массив?
> массив надо-то восстановить, путем добавления диска взамен
> неисправного, и след-но у него должен сохраниться старый uuid, который
> и прописан в fstab.
Нет, иначе массив при следующей загрузке будет пытаться собиратся с
"битым" диском.

> вот если мы сами перестроили массив, с потерей всей информации, тогда
> понятно появление нового uuid...
UUID должен меняться при любом изменении конфигурации массива.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

Ivan Fedorov пишет:
> "Maks Re" <admaks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
>>> После замены диска mdadm перестроил массив, изменив при этом его  uuid,
>>> чтобы нельзя было добавить не то диск. А в конфиге у вас указан масссив со
>>> старыми uuid'ами. Собственно, не совсем понятно, чем вы удивлены и на
>>> какое поведение вы расчитываете.
>> непонятно вот что
>> почему, при добавлении диска взамен неисправного, перестроился массив?
>> массив надо-то восстановить, путем добавления диска взамен
>> неисправного, и след-но у него должен сохраниться старый uuid, который
>> и прописан в fstab.
> Нет, иначе массив при следующей загрузке будет пытаться собиратся с
> "битым" диском.
> 
>> вот если мы сами перестроили массив, с потерей всей информации, тогда
>> понятно появление нового uuid...
> UUID должен меняться при любом изменении конфигурации массива.

   Это не очевидно. По крайней мере для меня...

   Переход с имён устройств на их UUID`ы для меня был замотивирован тем, 
что UUID в отличии от имён вещь постоянная, в частности не меняется -- 
при переездах с LVM на EVMS и обратно и/или смене физического 
подключения дисков. Теперь оказывается что UUID тоже вещь не постоянная, 
и он будет изменён при замене диска в массиве...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Yuri Bushmelev]

В сообщении от Понедельник 27 октября 2008 Aleksey Avdeev написал(a):
> Ivan Fedorov пишет:

>    Переход с имён устройств на их UUID`ы для меня был замотивирован тем,
> что UUID в отличии от имён вещь постоянная, в частности не меняется --
> при переездах с LVM на EVMS и обратно и/или смене физического
> подключения дисков. Теперь оказывается что UUID тоже вещь не постоянная,
> и он будет изменён при замене диска в массиве...

Можно рассмотреть использование LABEL вместо UUID.

-- 
С уважением,
Бушмелев Юрий

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

Aleksey Avdeev <solo-+V32sm3JFRb+YQgHObkolA@public.gmane.org> writes:

>>> непонятно вот что почему, при добавлении диска взамен неисправного,
>>> перестроился массив? массив надо-то восстановить, путем добавления
>>> диска взамен неисправного, и след-но у него должен сохраниться
>>> старый uuid, который и прописан в fstab.
>> Нет, иначе массив при следующей загрузке будет пытаться собиратся с
>> "битым" диском.
>>
>>> вот если мы сами перестроили массив, с потерей всей информации, тогда
>>> понятно появление нового uuid...
>> UUID должен меняться при любом изменении конфигурации массива.
>
>   Это не очевидно. По крайней мере для меня...
>
>   Переход с имён устройств на их UUID`ы для меня был замотивирован
>   тем, что UUID в отличии от имён вещь постоянная, в частности не
>   меняется при переездах с LVM на EVMS и обратно и/или смене
>   физического подключения дисков. Теперь оказывается что UUID тоже
>   вещь не постоянная, и он будет изменён при замене диска в массиве...

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

Это НОВЫЙ массив, на котором просто лежат СТАРЫЕ ДАННЫЕ.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

Ivan Fedorov пишет:
> Aleksey Avdeev <solo-+V32sm3JFRb+YQgHObkolA@public.gmane.org> writes:
> 
>>>> непонятно вот что почему, при добавлении диска взамен неисправного,
>>>> перестроился массив? массив надо-то восстановить, путем добавления
>>>> диска взамен неисправного, и след-но у него должен сохраниться
>>>> старый uuid, который и прописан в fstab.
>>> Нет, иначе массив при следующей загрузке будет пытаться собиратся с
>>> "битым" диском.
>>>
>>>> вот если мы сами перестроили массив, с потерей всей информации, тогда
>>>> понятно появление нового uuid...
>>> UUID должен меняться при любом изменении конфигурации массива.
>>   Это не очевидно. По крайней мере для меня...
>>
>>   Переход с имён устройств на их UUID`ы для меня был замотивирован
>>   тем, что UUID в отличии от имён вещь постоянная, в частности не
>>   меняется при переездах с LVM на EVMS и обратно и/или смене
>>   физического подключения дисков. Теперь оказывается что UUID тоже
>>   вещь не постоянная, и он будет изменён при замене диска в массиве...
> 
> А ты просто рассматривай эту ситуацию, как вариант полной замены
> массива, ибо так и есть - у тебя ведь массив теперь уже другой.
> 
> Это НОВЫЙ массив, на котором просто лежат СТАРЫЕ ДАННЫЕ.

   При монтировании из /etc/fstab мне неважно изменился изменился массив 
или нет (новый он или старый) -- мне важно чтобы данные (ФС, лежащая на 
данном массиве) были примонтированны в строго определённое место (если 
они не разрушены, разумеется).

   Грубо говоря, при загрузке для меня главное взлететь... В каком виде 
при этом массив -- дело десятое: т. к. пока не взлетишь доступа по ssh 
нет => ничего нельзя сделать удалённо (как правело)...

PS: Не исключено что я зря гоню пургу: Перечитав тред обратил внимание 
что меняется UUID массива под которым он присутствует в конфиге mdadm... 
Но меняется ли при этом UUID по которому происходит монтирование? 
(Другими словами: Меняющийся UUID -- это тот UUID по которому 
осуществляется монтирование при указании его в /etc/fstab, или какой-то 
другой?)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Денис Ягофаров]

[-- Attachment #1: Type: text/plain, Size: 10971 bytes --]

Проведем эксперимент. Устроим "сбой" диска в массиве raid5, и посмотрим 
с каким UUID массив восстановится.

Вот так оно выглядит до сбоя:

# blkid
/dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
TYPE="ext3"
/dev/sdc1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/sdd1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/sdb1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/md0: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
TYPE="ext3"

# cat /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

# mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Fri Oct 24 16:29:15 2008
     Raid Level : raid5
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent
    Update Time : Sat Oct 25 07:09:34 2008
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
         Layout : left-symmetric
     Chunk Size : 64K
           UUID : 62985eb6:1297d375:923a4cf5:5754a253
         Events : 0.2
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
 
Предположим, что 1 из жёстких дисков совсем погиб. При этом он уже ни на 
что не отвечает. 

# echo "scsi remove-single-device 2 0 0 0" > /proc/scsi/scsi
# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sdb  /dev/sdb1  /dev/sdd  /dev/sdd1  /dev/sde

в логах
Oct 27 11:37:22 localhost kernel: ata3.00: disabled

# mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Fri Oct 24 16:29:15 2008
     Raid Level : raid5
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent
    Update Time : Sat Oct 25 07:09:34 2008
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
         Layout : left-symmetric
     Chunk Size : 64K
           UUID : 62985eb6:1297d375:923a4cf5:5754a253
         Events : 0.2
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync
       3       8       49        3      active sync   /dev/sdd1


Как ни странно, он ещё не failed. Стоит ли его вручную помечать как failed?
# cat /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

Пробуем отформатировать, к примеру, /dev/md0... впрочем иное действие 
чтения/записи
тоже должно подойти.
Personalities : [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[3] sdc1[4](F) sdb1[1] sda1[0]
      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/3] [UU_U]

в логах
Oct 27 11:40:21 localhost kernel: scsi 2:0:0:0: rejecting I/O to dead device
Oct 27 11:40:21 localhost mdmonitor: Fail event on /dev/md0
Oct 27 11:40:21 localhost kernel: scsi 2:0:0:0: rejecting I/O to dead device
Oct 27 11:40:21 localhost kernel: scsi 2:0:0:0: rejecting I/O to dead device
Oct 27 11:40:21 localhost kernel: raid5: Disk failure on sdc1, disabling 
device. Operation continuing on 3 devices
Oct 27 11:40:21 localhost kernel: RAID5 conf printout:
Oct 27 11:40:21 localhost kernel:  --- rd:4 wd:3 fd:1
Oct 27 11:40:21 localhost kernel:  disk 0, o:1, dev:sda1
Oct 27 11:40:21 localhost kernel:  disk 1, o:1, dev:sdb1
Oct 27 11:40:21 localhost kernel:  disk 2, o:0, dev:sdc1
Oct 27 11:40:21 localhost kernel:  disk 3, o:1, dev:sdd1
Oct 27 11:40:21 localhost kernel: RAID5 conf printout:
Oct 27 11:40:21 localhost kernel:  --- rd:4 wd:3 fd:1
Oct 27 11:40:21 localhost kernel:  disk 0, o:1, dev:sda1
Oct 27 11:40:21 localhost kernel:  disk 1, o:1, dev:sdb1
Oct 27 11:40:21 localhost kernel:  disk 3, o:1, dev:sdd1

Если, нужно отключить погибший, но ещё крутящийся жёсткий диск, можно ли 
как-то на него подать сигнал
к полному останову и отключению питания? Или обо всём позаботится backplain?

Мы "прибежали" с новым жёстким диском. Создали раздел (а может, он уже 
заранее был создан?)
и подключили его...
# echo "scsi add-single-device 2 0 0 0" > /proc/scsi/scsi

в логах
Oct 27 11:42:59 localhost kernel: ata3: soft resetting port
Oct 27 11:42:59 localhost kernel: ata3: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
Oct 27 11:42:59 localhost kernel: ata3.00: ATA-7, max UDMA/133, 
1465149168 sectors: LBA48 NCQ (depth 31/32)
Oct 27 11:42:59 localhost kernel: ata3.00: configured for UDMA/133
Oct 27 11:42:59 localhost kernel: ata3: EH complete
Oct 27 11:42:59 localhost kernel:   Vendor: ATA       Model: 
ST3750640AS       Rev: 3.AA
Oct 27 11:42:59 localhost kernel:   Type:   
Direct-Access                      ANSI SCSI revision: 05
Oct 27 11:42:59 localhost kernel: SCSI device sdf: 1465149168 512-byte 
hdwr sectors (750156 MB)
Oct 27 11:42:59 localhost kernel: sdf: Write Protect is off
Oct 27 11:42:59 localhost kernel: SCSI device sdf: drive cache: write back
Oct 27 11:42:59 localhost kernel: SCSI device sdf: 1465149168 512-byte 
hdwr sectors (750156 MB)
Oct 27 11:42:59 localhost kernel: sdf: Write Protect is off
Oct 27 11:42:59 localhost kernel: SCSI device sdf: drive cache: write back
Oct 27 11:42:59 localhost kernel:  sdf: sdf1
Oct 27 11:42:59 localhost kernel: sd 2:0:0:0: Attached scsi disk sdf

Правильно, его нету уже, может, это стоило сделать раньше?
# mdadm /dev/md0 --remove /dev/sdc1
mdadm: cannot find /dev/sdc1: No such file or directory

Добавляем новый диск...
# mdadm /dev/md0 --add /dev/sdf1
mdadm: re-added /dev/sdf1

в логах
Oct 27 11:44:30 localhost kernel: md: bind<sdf1>
Oct 27 11:44:30 localhost kernel: RAID5 conf printout:
Oct 27 11:44:30 localhost kernel:  --- rd:4 wd:3 fd:1
Oct 27 11:44:30 localhost kernel:  disk 0, o:1, dev:sda1
Oct 27 11:44:30 localhost kernel:  disk 1, o:1, dev:sdb1
Oct 27 11:44:30 localhost kernel:  disk 2, o:1, dev:sdf1
Oct 27 11:44:30 localhost kernel:  disk 3, o:1, dev:sdd1
Oct 27 11:44:30 localhost kernel: md: recovery of RAID array md0
Oct 27 11:44:30 localhost kernel: md: minimum _guaranteed_  speed: 1000 
KB/sec/disk.
Oct 27 11:44:30 localhost kernel: md: using maximum available idle IO 
bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 27 11:44:30 localhost kernel: md: using 128k window, over a total of 
732571904 blocks.
Oct 27 11:44:30 localhost mdmonitor: RebuildStarted event on /dev/md0

Ждём 700 минут.... (ок. 12 часов)
# cat /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sdf1[2] sdd1[3] sdc1[4](F) sdb1[1] sda1[0]
      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/3] [UU_U]
      [>....................]  recovery =  0.1% (1136640/732571904) 
finish=717.3min speed=16992K/sec

После восстановления:
# mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Fri Oct 24 16:29:15 2008
     Raid Level : raid5
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
   Raid Devices : 4
  Total Devices : 5
Preferred Minor : 0
    Persistence : Superblock is persistent
    Update Time : Mon Oct 27 22:53:14 2008
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 0
         Layout : left-symmetric
     Chunk Size : 64K
           UUID : 62985eb6:1297d375:923a4cf5:5754a253
         Events : 0.8
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       81        2      active sync   /dev/sdf1
       3       8       49        3      active sync   /dev/sdd1
       4       8       33        -      faulty spare

Как видим, UUID не поменялся.... добавляем его в конфиг:
DEVICE /dev/sd[a,b,c,d]1
ARRAY /dev/md0 UUID=62985eb6:1297d375:923a4cf5:5754a253
MAILADDR root
PROGRAM /sbin/mdadm-syslog-events

Пробуем перезагрузиться...

Как видим, всё восстановилось:
# mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Fri Oct 24 16:29:15 2008
     Raid Level : raid5
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent
    Update Time : Mon Oct 27 22:53:14 2008
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
         Layout : left-symmetric
     Chunk Size : 64K
           UUID : 62985eb6:1297d375:923a4cf5:5754a253
         Events : 0.8
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
# blkid
/dev/sda1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/sdd1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/sdb1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/sdc1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
/dev/md0: UUID="6201837c-d0db-4e0e-a7ae-d3490c47cc46" SEC_TYPE="ext2" 
TYPE="ext3"

Вывод:
Не путайте UUID : 62985eb6:1297d375:923a4cf5:5754a253 из mdadm -D /dev/md0
и /dev/md0: UUID="6201837c-d0db-4e0e-a7ae-d3490c47cc46" SEC_TYPE="ext2" 
TYPE="ext3"
из blkid, как это сделал я.

[-- Attachment #2: denyago.vcf --]
[-- Type: text/x-vcard, Size: 281 bytes --]

begin:vcard
fn:Denis Timurovich Yagofarov
n:Yagofarov;Denis Timurovich
org:ITGIS NASU
adr:room 615;;Chokolovski blvdr., 13;Kiev;;03151;Ukraine
email;internet:denyago@rambler.ru
title:system administrator
tel;work:80442480755
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3527 bytes --]

Денис Ягофаров пишет:
> Проведем эксперимент. Устроим "сбой" диска в массиве raid5, и посмотрим 
> с каким UUID массив восстановится.
> 
> Вот так оно выглядит до сбоя:
> 
> # blkid
> /dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
> TYPE="ext3"
> /dev/sdc1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/sdd1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/sdb1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/md0: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2" 
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> TYPE="ext3"
> 
> # cat /proc/mdstat
> Personalities : [raid10] [raid6] [raid5] [raid4]
> md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
>      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
> 
> # mdadm -D /dev/md0
> /dev/md0:
...
>           UUID : 62985eb6:1297d375:923a4cf5:5754a253
...
> 
> После восстановления:
> # mdadm -D /dev/md0
> /dev/md0:
...
>           UUID : 62985eb6:1297d375:923a4cf5:5754a253
...
> 
> Как видим, UUID не поменялся.... добавляем его в конфиг:
> DEVICE /dev/sd[a,b,c,d]1
> ARRAY /dev/md0 UUID=62985eb6:1297d375:923a4cf5:5754a253
> MAILADDR root
> PROGRAM /sbin/mdadm-syslog-events
> 
> Пробуем перезагрузиться...
> 
> Как видим, всё восстановилось:
> # mdadm -D /dev/md0
> /dev/md0:
...
>           UUID : 62985eb6:1297d375:923a4cf5:5754a253
...
> # cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid5 sda1[0] sdd1[3] sdc1[2] sdb1[1]
>      2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
> # blkid
> /dev/sda1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/sdd1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/sdb1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/sdc1: UUID="b65e9862-75d3-9712-f54c-3a9253a25457" TYPE="mdraid"
> /dev/md0: UUID="6201837c-d0db-4e0e-a7ae-d3490c47cc46" SEC_TYPE="ext2" 
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> TYPE="ext3"
> 
> Вывод:
> Не путайте UUID : 62985eb6:1297d375:923a4cf5:5754a253 из mdadm -D /dev/md0
> и /dev/md0: UUID="6201837c-d0db-4e0e-a7ae-d3490c47cc46" SEC_TYPE="ext2" 
> TYPE="ext3"
> из blkid, как это сделал я.

   Вот UUID из blkid меня в первою очередь и волнует, т. к. именно по 
нему и выполняется монтирование при загрузке (при указании его в 
/etc/fstab). Ваш эксперимент показал, что именно он и меняется (см. 
выделение выше) => если нет уровней абстракции расположенных над ним 
(нечто типа LVM/EVMS, которые подобное должны перенести по идее) система 
не загрузится...

   в частности, данная мина сработает если корень расположен поверх 
/dev/md*. (Особенно с учётом того, что наш инсталятор осуществляет 
привязку по UUID...)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Tue, 28 Oct 2008 12:17:16 +0200 Денис Ягофаров wrote:

[...]
> Предположим, что 1 из жёстких дисков совсем погиб. При этом он уже ни на
> что не отвечает.
>
> # echo "scsi remove-single-device 2 0 0 0" > /proc/scsi/scsi
> # ls /dev/sd*
> /dev/sda  /dev/sda1  /dev/sdb  /dev/sdb1  /dev/sdd  /dev/sdd1  /dev/sde
[...]
> Как ни странно, он ещё не failed. Стоит ли его вручную помечать как failed?

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

> # cat /proc/mdstat
> Personalities : [raid10] [raid6] [raid5] [raid4]
> md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
>       2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
>
> Пробуем отформатировать, к примеру, /dev/md0... впрочем иное действие
> чтения/записи
> тоже должно подойти.

Лучше было делать "иное действие" - при форматировании как раз и
поменялся UUID файловой системы.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On Sat, 25 Oct 2008 20:53:37 +0400 Konstantin A. Lepikhov wrote:

> Hi Денис!
>
> Friday 24, at 01:56:58 PM you wrote:
>
> <skip>
> > sde стал после перезагрузки sdb.... (т.к. полетел sdb, его "вытащили",
> > затем "вставили" новый, он стал sde)
> >
> > пробую так:
> > # mdadm --assemble /dev/md0 --run -v
> > mdadm: looking for devices for /dev/md0
> > mdadm: /dev/sdd1 has wrong uuid.
> > mdadm: /dev/sdc1 has wrong uuid.
> > mdadm: /dev/sdb1 has wrong uuid.
> > mdadm: /dev/sda1 has wrong uuid.
> > mdadm: no devices found for /dev/md0
> >
> > # blkid
> > /dev/sda1: UUID="4aa4c1e1-a3e5-464c-8305-a2be835250b6" SEC_TYPE="ext2"
> > TYPE="ext3"
> > /dev/hda1: UUID="7deb64be-1be5-49dc-9e0f-4ac9381173f2" SEC_TYPE="ext2"
> > TYPE="ext3"
> > /dev/sdc1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> > /dev/sdd1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> > /dev/sdb1: UUID="75a37462-2c1e-240b-ce20-a292849720eb" TYPE="mdraid"
> >
> > в конфиге:
> > DEVICE /dev/sd[a-d]1
> > ARRAY /dev/md0 UUID=4aa4c1e1:a3e5:464c:8305:a2be835250b6
> > MAILADDR root
> > PROGRAM /sbin/mdadm-syslog-events
> После замены диска mdadm перестроил массив, изменив при этом его  uuid,
> чтобы нельзя было добавить не то диск. А в конфиге у вас указан масссив со
> старыми uuid'ами. Собственно, не совсем понятно, чем вы удивлены и на
> какое поведение вы расчитываете.

Ничего там не меняется (если не пересоздавать массив полностью - что
иногда приходится делать, если развалилось всё и нормальным образом
собрать не удаётся).  А вот форматы представления UUID у mdadm и
blkid разные (отличается даже порядок байтов); в udev (vol_id) тоже
другой формат (ещё и менявшийся в каких-то версиях).  Так что в
mdadm.conf нужно вписывать UUID именно из вывода mdadm.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Maks Re]

>  Так что в
> mdadm.conf нужно вписывать UUID именно из вывода mdadm.
>

пожалуй эту фразу надо прибито бОльшими буквами на "заборе"...

чтобы не забыть (понятно, что это есть в мане...)


-- 
С уважением,
  Макс.

Re: [Sysadmins] Собрать raid после сбоя и перезагрузки

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Sergey Vlasov пишет:
> On Tue, 28 Oct 2008 12:17:16 +0200 Денис Ягофаров wrote:
> 
> [...]
>> Предположим, что 1 из жёстких дисков совсем погиб. При этом он уже ни на
>> что не отвечает.
>>
>> # echo "scsi remove-single-device 2 0 0 0" > /proc/scsi/scsi
>> # ls /dev/sd*
>> /dev/sda  /dev/sda1  /dev/sdb  /dev/sdb1  /dev/sdd  /dev/sdd1  /dev/sde
> [...]
>> Как ни странно, он ещё не failed. Стоит ли его вручную помечать как failed?
> 
> failed появляется после обнаружения ошибки, что не произойдёт, пока
> не попытаться обратиться к массиву.
> 
>> # cat /proc/mdstat
>> Personalities : [raid10] [raid6] [raid5] [raid4]
>> md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
>>       2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
>>
>> Пробуем отформатировать, к примеру, /dev/md0... впрочем иное действие
>> чтения/записи
>> тоже должно подойти.
> 
> Лучше было делать "иное действие" - при форматировании как раз и
> поменялся UUID файловой системы.

   У-ф-ф... Похоже я пропустил, что выполнялось именно форматирование.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]