Dotaz: SW raid, partition (sda1) nebo cely disk (sda)

[Jan Kratochvíl]

Dobrý den,

mám vytvořený SW raid z instalace Ubuntu a ten pracuje nad oddíly linux raid autodetect, tudíž raid se skládá z /dev/sda1 a /dev/sdb1. To je jasný, ale na jiné mašině máme SW raid, který se skládá přímo z disků, tedy /dev/sda a /dev/sdb, pokud se na ně kouknu fdiskem, žádné oddíly tam nejsou.

Teď jsem zkusil ze srandy degradovyný raid doplnit diskem a tak jsem k /dev/sda1 přidal /dev/sdb a čekal nějakou chybu, ale ono se to začalo rebuildovat, chaos.

Na internetu jsem našel návody na sestavení raidu, které vždy začínají vytvořením toho oddílu raid.

Můj dotaz, jaký je rozdíl pokud se použije ten oddíl nebo ne? je to z důvodu bootu?

Díky

Odpovědi

[Sten]

Ano, rozdíl je pouze v možnosti bootovat

[r00t]

ak sa nemylim bootovat mozes beproblemov aj z /dev/md* zariadenia, je to len vec konfiguracie initrd

[H0ax]

V podstatě můžeš softraid složit ze spousty různých zařízení. To, jestli uděláš raid z disku a nebo z nasekaných partišen, je technicky jedno.

[pet]

Pouzivam RAID1 nad celymi disky, na udrzbu je to jednoduzsi nez hromada malych raidu. Pro bootovani je to u RAID1 jedno, protoze bootloader nabiha z prvniho nalezeneho disku a je mu zcela fuk, ze tento disk je soucasti nejakeho RAID1, protoze vypada i jako samostatny disk.

[dustin]

Opravdu lze v linuxovém SW raidu vytvořit raid1 jako celý disk, který lze dále rozdělovat od oddílů? A nebo používáš HW/fake HW raid a ne mdadm?

Nevím, jak bych to partišnoval, a např. http://blog.taggesell.de/index.php?/archives/46-Linux-Software-RAID-101-Part-1-creating-a-RAID-array.html také uvádí, že linuxový sw raid pracuje na úrovni partišen (nebo celého disku), ale vyleze zase jen jedna dále nedělitelná partišna.

[Sten]

RAID se neparitionuje, ale lze použít LVM. LILO tuším umí bootovat i z full disk RAID1, GRUB to ale neumí (při instalaci RAID zničí)

[Michal Kubeček]

Jádra 2.6 umožňují "partitionable array", ale moc se to nepoužívá, protože LVM je praktičtější.

[Jan Kratochvíl]

Super, začínám to chápat, je to vlastně úplně jedno, ale používáme GRUB, takže potřebuju ty fd oddíly, aby to bootovalo (to je dost zásadní). My nad tim máme samo LVM a v tom hromadu dalších oddílů, ale to s dotazem vůbec nesouvisí.....

[pet]

Pouzivam gentoo. Disky pripravuju:

# 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; done

Grub 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)
   quit

V /boot/grub/grub.conf (menu.lst standardniho grubu):

  title= system
  root (hd0,0)
  kernel /kernel md=d127,/dev/sda,/dev/sdb root=/dev/md_d127p2

Kernel 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.

[dustin]

Díky za info, jak na to.

[houska]

kdyz to udelas partisnu s typem fd tak ziskas vyhodu ze je partisna rozpoznana behem bootu, kdyz to udelas primo na disk pez partisny, tak si musis udrzovat informace o raidu nekde v konfiguraku

[MMichal]

Coz je mimochodem lepsi. Autodekce pole se uz moc nedoporucuje, neni totiz nijak ovlivnitelna - proste jadro najde nejake RAID Autodetect partisny a pokusi se z nich sestavit pole. Trable mohou nastat v ruznych pripadech, kdy je na systemu vice poli a nebo byl disk prendavan mezi poli bez dusledneho uklidu predchozich metadat.

I zde na abclinuxu jsem videl nekolik diskuzi, ze system chybne sestavil jednotliva pole a poskodil data tim, ze synchronizoval co nemel.

Naproti tomu pouziti /etc/mdadm.conf (nebo jak se to jmenuje) umoznuje presne specifikovat konfiguraci pole a nehrozi, ze se sestavi spatne. Ale pravda, pak je potreba mit initramfs (tedy v pripade, ze na poli je rootfs).

[dustin]

Jo, zrovna nedávno jsem řešil, proč ubuntu po instalaci mdadm (a automatickém přegenerování initramfs v rámci konfigurace toho balíku) již nenabootuje a hlásí, že rootovská partišna je busy a nelze ji namontovat. Ukázalo se, že disk byl svého času součástí sw raidu a přímo na sda byl superblock. Automatická detekce raidu tedy při bootu milý disk nejdříve strčila do nějakého md_X a následný mount rootu (sda3) selhal. A protože šlo o disk, na kterém byl root, nešlo superblock ani smazat (mdadm --reset-superblock /dev/sda) přímo ze systému (device busy) a musel jsem to smazat z liveCD. Pak už to samozřejmě nabootovalo OK. Automatická detekce raidu mi přijde dost nebezpečná, raději si upravím mdadm.conf a přegeneruji initramfs.

[Michal Kubeček]

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ří.

[MMichal]

Mam jednoho takovyho kolegu, co ma vylozene negativni vztah k initramfs

[Michal Kubeček]

Každý svého štěstí strůjcem… :-)

[trekker.dk]

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ů.

[Michal Kubeček]

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.

[Sten]

Ten první problém se dá vyřešit snadno tak, že se i root zařízení identifikuje pomocí UUID a ne pomocí toho, že je to md0

[Michal Kubeček]

V zásadě ano. Jenže to mountování podle UUID obvykle funguje díky linkům /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.