Portál AbcLinuxu, 17. července 2025 18:20
# mdadm -C -ap7 /dev/md_d127 -R -f -l1 -n2 /dev/sda /dev/sdb ### slovo "missing" muze nahradit jedno zarizeni # fdisk /dev/md_d127 /dev/md_d127p1 * 10M 83 ext2 for boot /dev/md_d127p2 10G 83 ext3 for system /dev/md_d127p3 2G 82 swap /dev/md_d127p4 rest 83 ext3 for home # mkswap /dev/md_d127p3 # swapon /dev/md_d127p3 # mke2fs /dev/md_d127p1 # for i in 2 4;do mke2fs -j /dev/md_d127p$i; doneGrub instaluju:
# cd /dev ; ln -s md_d127 md_d127p ### osetreni chyby grubu # echo "(hd0) /dev/md_d127p" > /boot/grub/device.map # grub --device-map=/boot/grub/device.map root (hd0,0) setup (hd0) quitV /boot/grub/grub.conf (menu.lst standardniho grubu):
title= system root (hd0,0) kernel /kernel md=d127,/dev/sda,/dev/sdb root=/dev/md_d127p2Kernel delam sam, vse mam v nem, nemam tam moduly. Ale ramdisk je to schopno z /bootu nacist taky. Mam to tak v beznem produkcnim nasazeni u zakazniku, jen tech oddilu je tam o neco vice. Oproti kontrole nekolika (mnoha) raidu staci kontrolovat tento jeden, instalace i udrzba je jednoduzsi.
Naproti tomu pouziti /etc/mdadm.conf (nebo jak se to jmenuje) umoznuje presne specifikovat konfiguraci pole a nehrozi, ze se sestavi spatne.
Navíc je současný mdadm.conf
a vlastně v něm stačí definovat, kde hledat a jak přiřadit zařízení podle UUID pole.
Ale pravda, pak je potreba mit initramfs (tedy v pripade, ze na poli je rootfs).
Což už je dnes stejně potřeba skoro vždy, křečovitou snahou vyrobit za každou cenu systém bez initial ramdisku si člověk spíš víc práce přidělá než ušetří.
Navíc je současný mdadm.conf a vlastně v něm stačí definovat, kde hledat a jak přiřadit zařízení podle UUID pole.AFAIK jádro k sestavení pole taky používá UUID.
Což už je dnes stejně potřeba skoro vždy, křečovitou snahou vyrobit za každou cenu systém bez initial ramdisku si člověk spíš víc práce přidělá než ušetří.Tak to mám zkušenost přesně opačnou. Jednak z initramfs v kombinaci se software suspendem nemám dobrý pocit (pokud vím, když se něco nepovede - připojí se oddíl a pak se začne probouzet - sbohem data). No a druhak už mě vadný mdadm.conf několikrát pokousal, takže jsem musel bootovat LiveCD a opravovat. (Třeba když se initramfs s mdadm.conf přegeneroval blbě nebo taky vůbec.) Prostě na systém bez initramfs a autodetekci nedám dopustit, s tím jsem ještě v životě problémy neměl, žádné problémy se špatně sestaveným polem, a to i v případě různých stěhování disků.
AFAIK jádro k sestavení pole taky používá UUID.
To asi ano. Jde ale o to, že jádro neví, že konkrétní UUID odpovídá md0
, druhé md1
a třetí je jen náhodný kolemjdoucí, který tu nemá vůbec co dělat. Takže se musí orientovat jen podle "preferred minor" ze superbloku a tam právě může nastat problém v okamžiku, kdy připojíte disk, na kterém je FD oddíl, který byl součástí cizího pole. Jádro sice možná pozná, že je z jiného md0
než ostatní, ale už nemá šanci poznat, které z těch dvou md0
je to pravé.
Jednak z initramfs v kombinaci se software suspendem nemám dobrý pocit (pokud vím, když se něco nepovede - připojí se oddíl a pak se začne probouzet - sbohem data).
Používám už celkem dlouho systém s kombinací několika SW polí a LVM, suspend používám také a problém, který popisujete, jsem nikdy nezaznamenal. Naopak, initial ramdisk se hodí i k řadě dalších užitečných věcí, které je bez něj čím dál těžší obcházet.
/dev/disk/by-uuid/*
, které vytváří udev a ten je v tomto případě třeba spustit z initial ramdisku. Neříkám, že to nelze obejít, ale jsme zase na začátku - křečovitým odmítáním initial ramdisku si dnes většinou víc práce přiděláte než ušetříte.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.