[Comm] root raid on Master 2.2

[Sergey Vlasov]

On Thu, Nov 06, 2003 at 10:36:54AM +0300, Grigory Batalov wrote:
[skip] 
> initrd для загрузки создавался по мотивам
> http://www.atmsk.ru/index.php?option=faq&task=viewfaq&artid=163
> 
> Использовалась команда:
> $ sudo mkinitrd --with raid5 --with raid1 --pause initrd-2.4.20-alt10-smp.img 2.4.20-alt10-smp
> 
> Для создания дискеты:
> $ sudo mkbootdisk --mkinitrdargs '--with raid1 --with raid5 --pause' 2.4.20-alt10-smp
> 
> Во время паузы и ожидания нажатия ENTER в указанную директорию
> initrd были скопированы:
> 
> /dev/md{0,1,2}
> /dev/sd{a,b,c,d,e}{,1,2,3}
> /etc/raidtab
> /sbin/raidstart
> 
> В linuxrc дописано:
> /sbin/raidstart /dev/md0 /dev/md1 /dev/md2

При таком способе RAID не запустится, если исчезнет первое
устройство, прописанное в raidtab для массива.  Дело в том, что
raidstart фактически использует только первую запись, а остальные
разделы находит само ядро, используя данные из суперблока RAID с
этого устройства.

Для SCSI это не так критично - при исчезновении устройств произойдёт
перенумерация.  Проблема возникнет только в случае, когда само
устройство доступно, но суперблок RAID прочитать не удаётся.  А вот
в случае IDE при отсутствии первого диска система не загрузится.

В mkinitrd из Сизифа используется другой способ запуска RAID - через
ioctl RAID_AUTORUN; в этом случае не нужно указывать устройства -
используется информация, собранная ядром при распознавании
RAID-разделов.  Можно поставить этот mkintrd на Master 2.2 - там нет
лишних зависимостей.  С ядром из Master 2.2 этот способ работает -
только не используйте /dev/md255 (в той версии ядра есть ошибка -
нельзя вызывать RAID_AUTORUN через то устройство md, которое потом
будет использоваться).

> Raidstart в данном случае собирался статически, что позволило
> обойтись без динамических библиотек и уместить initrd на дискету.
> Для пересборки был взят raidtools-0.90-ipl11mdk.src.rpm.
> В specfile добавлено '-static':
> ...
> CFLAGS="$RPM_OPT_FLAGS -static" CXXFLAGS="$RPM_OPT_FLAGS" LDFLAGS="-static" ./autogen.sh
> ...
> 
> Бинарник получается после 
> $ rpmbuild -bi --target i586 raidtools.spec
> в директории ~/tmp/raidtools-buildroot/sbin.
> 
> 
> Несмотря на вышеизложенные действия (где была ошибка?),
> загрузиться со SCSI не удалось. Не оказалось загрузочной
> записи. Поэтому, загрузились с дискеты и сказали поочерёдно
> $ sudo lilo -b /dev/sda
> ...
> $ sudo lilo -b /dev/sde
> После чего стало возможно загружаться сразу с дисков.
> 
> При сбое одного из дисков в массиве предполагается сделать:
> $ sudo raidhotremove /dev/md0 /dev/sdN
> $ sudo raidhotremove /dev/md1 /dev/sdN
> $ sudo raidhotremove /dev/md2 /dev/sdN
> <заменить диск N>
> $ sudo sfdisk -d /dev/sda > table.sda
> $ sudo sfdisk /dev/sdN < table.sda
> $ sudo raidhotadd /dev/md0 /dev/sdN
> $ sudo raidhotadd /dev/md1 /dev/sdN
> $ sudo raidhotadd /dev/md2 /dev/sdN
> $ sudo lilo -b /dev/sdN
> 
> Вопросы:
> 
> 1. Как реагировать на сообщения типа:
> 
> md: invalid raid superblock magic on md2
> md: md2 has invalid sb, not importing!
> (ругается на все md*)

Игнорировать.  Это попытка найти вложенный RAID (например, RAID0, а
внутри - RAID1).

> 2. Чем чревато, что при перезагрузке не размонтируется md0
>    по причине busy, хотя md2 и md1 были только что успешно
>    размонтированы, и как с этим бороться?

Бороться с этим бесполезно - на md0 лежит корневая ФС.  Ничего
страшного в этом нет - ядро при завершении работы автоматически
выполняет останов RAID.

> 3. Есть ли какая-нибудь утилитка, следящая за шиной SCSI и
>    рассылающая письма или мигающая лампочками при сбое диска?

smartmontools (есть в Сизифе, только там initscript новый... надо бы
сделать, как в apache) умеет работать в том числе и со
SCSI-устройствами.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/community/attachments/20031106/05d0bb12/attachment-0002.bin>