Почему не получается удалить диск из RAID-массива?

>md0 : active raid6 sdc[0] sdf[3] sde[2] sdd[1]

А где sdb?

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

А он, внезапно, уже отключен. Автоматически.

он, внезапно, уже отключен.

верно. В этом можно убедится при помощи
mdadm -D /dev/md0

я раньше думал, что диск сначала переходит в состяние fail,
а потом его надо вручную отключать...

Копетан подсказываетъ, TYPE=«linux_raid_member» означает что диск имеет соответствующую метку и «суперблок». Это не означает, что он находится в массиве.

# mdadm -D /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Thu Sep 2 23:04:35 2010
Raid Level : raid6
Array Size : 5860540224 (5589.05 GiB 6001.19 GB)
Used Dev Size : 1953513408 (1863.02 GiB 2000.40 GB)
Raid Devices : 5
Total Devices : 6
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : /mnt/pciessd/mdadm_write_intent_bitmap

Update Time : Tue Dec 21 16:32:29 2010
State : clean, degraded, recovering
Active Devices : 4
Working Devices : 5
Failed Devices : 1
Spare Devices : 1

Chunk Size : 64K

Rebuild Status : 0% complete

UUID : ...some.uuid...
Events : 0.37853

Number Major Minor RaidDevice State
0 8 32 0 active sync /dev/sdc
1 8 48 1 active sync /dev/sdd
2 8 64 2 active sync /dev/sde
3 8 80 3 active sync /dev/sdf
5 8 112 4 spare rebuilding /dev/sdh

6 8 16 - faulty spare

Скажи, капитан, как избавится от этого faulty spare, если команда
mdadm --manage /dev/md0 --remove /dev/sdb выдает

mdadm: cannot find /dev/sdb: No such file or directory

mdadm --zero-superblock

If the device contains a valid md superblock, the block is overwritten with zeros. With --force the

block where the superblock would be is overwritten even if it doesn't appear to be valid.

очисти суперблок на выпавшем винте.

ТС сделай и выложи сюда

mdadm -Q --detail /dev/md0

> очисти суперблок на выпавшем винте.

выпавший винт уже физически вытащен

> ТС сделай и выложи сюда

см. http://www.linux.org.ru/jump-message.jsp?msgid=5701904&cid=5702277

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

запасной винт подключать пробовал ?

запасной винт подключать пробовал ?

Сначала был RAID-6 с пятью винтами: sdb, sdc, sdd, sde, sdf
потом сдох sdb, я его вынул
потом я воткнул новый, сделал --re-add, массив начал перестраиваться
потом я решил, что странно, что lshw показывает старые данные и выполнил рескан шины sata, устройство /dev/sdb пропало и появилось /dev/sdh
выполнил --add /dev/sdh, запустился снова ребилд. Вывод диагностики выше соответствует этому моменту.

Теперь я хочу понять, как удалить faulty spare из массива /dev/md0

покажи вот это

cat /sys/block/md0/md/array_state

>> потом я воткнул новый, сделал --re-add, массив начал перестраиваться

надо было не --re-add делать, а добавить в массив раздел как hot spare шобе оно само заменило аварийный выпавший винт.

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

http://www.mail-archive.com/sysadmins@lists.altlinux.org/msg13358.html

> как удалить faulty spare из массива /dev/md0

mdadm --manage /dev/md0 --remove detached

выполнил рескан шины sata, устройство /dev/sdb пропало и появилось /dev/sdh

Надо было делать RAID на основе меток UUID, а не физических устройств. Теперь поздно пить Баржоми — почки отвалились RAID не может принять новое устройство за старое.

После перестроения попробуй постпенно перестроить массив, вытаскивая по-одному устройства /dev/sd* и заменяя их логическими UUID-девайсами на тех же «мощностях» (вынутыми винтами).

Аналогичная ситуация, но с ZFS, описывается тут: http://habrahabr.ru/blogs/bsdelniki/77722/

# cat /sys/block/md0/md/array_state

clean

iZEN там немного другая ситуация.

Надо было делать RAID на основе меток UUID

это как?

У меня сейчас так:
# cat /etc/mdadm.conf
ARRAY /dev/md0 UUID=...some_uid... bitmap=/mnt/pciessd/mdadm_write_intent_bitmap

где ...some_uid... - такой же как в первом сообщении треда.

Создавал я изначально действительно по буквам, но не очень понятно, как бы новый встал вместо старого, если у него UUID вообще не установлен (диск из магазина и не инициализирован)

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

Разве?

Сначала собрали RAID из /dev/da*-устройств. Потом вынули/переставили диски, информация о девайсах «съехала» на один номер «вверх», массив развалился. После пертурбаций автор решил сделать свой выбор в пользу меток GPT для отдельных девайсов, на чём, собственно, и решилась его проблема.

> Разве?

по-моему он все правильно говорит, но проверять (перезагружать машину) не хочется. Подожду, когда что-нибудь еще навернется.

массив то большой по объему ?

> массив то большой по объему ?

6TB номинально, USE = 47% => примерно 3TB

говорит, что через 20 часов перестроится.

Потом буду сбекапливать (в принципе бекапы есть недельной давности)

Потом вынули/переставили диски, информация о девайсах «съехала» на один номер «вверх», массив развалился.

В метаданных записываются UUID'ы, они «съехать» никак не могут.

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

повер рейда лвм ?

*поверх рейда LVM ?

> поверх рейда LVM ?

нет, рейд прокидывается внутрь kvm как один drive, файл с pciessd прокидывается как другой драйв, а там внутри kvm создается ext3 + extended acl (с журналом на втором драйве) и затем куски выставляются разными способами (nfs, samba/CIFS, svn/WebDAV, https и т.д.)