Dotaz: Disky v MD raidu

[LuRy]

Ahoj mam takovy problem s sw raidem na linuxu. Jedna se o dva stejne 1TB disky ale po kazdem restartu se ten raid rozpadne. Proc? vzdy musim udelat renew delam to nasledujicimi prikazy

mdadm --fail /dev/md0 /dev/sda1
mdadm --manage /dev/md0 --add /dev/sdb1

dostanu takovyto vystup po dodelani 100% se raid tvari jako funkcni a bezi jak ma

cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md0 : active raid1 sdb1[2] sda1[0]
      966796224 blocks [2/1] [U_]
      [>....................]  recovery =  0.9% (9616384/966796224) finish=452.2min speed=35277K/sec

unused devices: none

Odpovědi

[dustin]

Podívej se, jestli mají obě části pole stejný název - viz řádek Name v mdadm --examine /dev/sda1, sdb1 a zda jsou jako local pro daný stroj. Defaultně se už místo uuid při bootovacím sestavování používá ten homehost, nedávno jsem s tím taky bojoval. http://comments.gmane.org/gmane.linux.raid/37524

[LuRy]

ve /etc/fstab

/dev/md0  /  ext3  usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0  0  1

uuid maji stejny predpokladam ze to si myslel tim nazvem? disky jsou stejne i stejny vyrobce

mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1fbb909d:b9762bbf:a35bfd78:fe6e271e
  Creation Time : Sat Aug  6 02:22:15 2011
     Raid Level : raid1
  Used Dev Size : 966796224 (922.01 GiB 990.00 GB)
     Array Size : 966796224 (922.01 GiB 990.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Mon Apr 16 09:37:07 2012
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1
       Checksum : fcf32dea - correct
         Events : 11649562


      Number   Major   Minor   RaidDevice State
this     0       8        1        0      active sync   /dev/sda1

   0     0       8        1        0      active sync   /dev/sda1
   1     1       0        0        1      faulty removed
   2     2       8       17        2      spare   /dev/sdb1

mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1fbb909d:b9762bbf:a35bfd78:fe6e271e
  Creation Time : Sat Aug  6 02:22:15 2011
     Raid Level : raid1
  Used Dev Size : 966796224 (922.01 GiB 990.00 GB)
     Array Size : 966796224 (922.01 GiB 990.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Mon Apr 16 09:38:08 2012
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1
       Checksum : fcf32ea1 - correct
         Events : 11649616


      Number   Major   Minor   RaidDevice State
this     2       8       17        2      spare   /dev/sdb1

   0     0       8        1        0      active sync   /dev/sda1
   1     1       0        0        1      faulty removed
   2     2       8       17        2      spare   /dev/sdb1

[LuRy]

nebude problem v tom ze mdadm.conf neni nijak nastavenej? jak ho pripadne nastavit? tohle je muj prvni raid. mel sme spise zkusenosti s hw raidem kde se tohle resit nemuselo..

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This file was auto-generated on Tue, 23 Sep 2008 08:22:52 +0200
# by mkconf $Id: mkconf 261 2006-11-09 13:32:35Z madduck $

[ency]

Bude to ono, je potreba abys tam soupnul to nastaveni, ted si nejsem jisty, jak se ten scan dela, myslim ze mdadm --scan --all

[dustin]

Aha, to mě nenapadlo, že bys neměl mdadm.conf :) Na konec /etc/mdadm.conf přidej aktuální definice polí - viz man mdadm:

echo 'DEVICE /dev/hd[a-z] /dev/sd*[a-z]' > /etc/mdadm/mdadm.conf
mdadm --examine --scan --config=mdadm.conf >> /etc/mdadm/mdadm.conf

Pokud tvá distribuce používá initrd (což asi jo), je potřeba aktuální mdadm.conf uložit do initramdisku, jinak to při bootu nezdetekuje. V debianu/ubuntu je to příkaz pod rootem:

update-initramfs -u

[LuRy]

cat /etc/mdadm/mdadm.conf
DEVICE /dev/hd[a-z] /dev/sd*[a-z]
ARRAY /dev/md0 UUID=1fbb909d:b9762bbf:a35bfd78:fe6e271e
   spares=1

to vypada ze by mohlo byt.. ale problem je s initramfs (debian squeeze)

update-initramfs -u
bash: update-initramfs: příkaz nenalezen

[dustin]

Taky squeeze:

server:~# dpkg -S update-initramfs
initramfs-tools: /etc/initramfs-tools/update-initramfs.conf
initramfs-tools: /usr/sbin/update-initramfs
initramfs-tools: /usr/share/man/man5/update-initramfs.conf.5.gz
initramfs-tools: /usr/share/man/man8/update-initramfs.8.gz

Je možné, že initrd nepoužíváš, máš jej uveden u bootovací položky v grubu (/boot/grub/menu.lst nebo grub.conf)?

[LuRy]

oh asi ma chyba doinstaloval sem initramfs tools .. ale nevratilo to zadny vystup to je ok?

[dustin]

To mi nepřijde OK.

server:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64

Spíš by to vypadalo, že žádné initrd opravdu nepoužíváš. Díval ses do toho grubu?

[LuRy]

jee ono je tam vlastne lilo :D

[dustin]

To nevadí, i to umí initrd.

[LuRy]

 ls /boot
boot.0800  boot.0810  coffee.bmp  debianlilo.bmp  sarge.bmp  System.map
boot.0801  boot.0900  debian.bmp  map             sid.bmp    vmlinuz-2.6.34.1

[dustin]

lilo má konfiguraci v /etc/lilo.conf

[dustin]

a to initrd v /boot nemáš, takže se asi nepoužívá. V takovém případě bohužel nevím, jak se nutí přímo jádro, aby samo buildovalo pole, bez initrd. Jsou na to nějaké parametry jádra, ale je možné, že s novějšími verzemi jádra se situace mění. Máme všude initrd, ale tady lidi určitě budou vědět.

[dustin]

Zkus jej přidat přes update-initramfs -c, tím nic nezkazíš.

[LuRy]

~# update-initramfs -c -k all
~# update-initramfs -u

oboje bez jakyho koliv vystupu.. a grub tam nacpat nemuzu kdyz sem to zkusil minule zesralo se to byl tam nejaky problem se zavadenim server je po reinstalaci po nejakym mbr viru

[LuRy]

co tohle? :D zacinam se bat jeslti to nabehne vubec po tom rebootu :D nejsem u topho fyzicky a jen tak nebudu .. :D

~# update-initramfs -c -k 2.6.34.1
update-initramfs: Generating /boot/initrd.img-2.6.34.1
grep: /boot/config-2.6.34.1: Adresář nebo soubor neexistuje
mdadm: cannot open /dev/md0: No such file or directory
mdadm: cannot open /dev/md0: No such file or directory

[LuRy]

~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.34.1
grep: /boot/config-2.6.34.1: Adresář nebo soubor neexistuje
Warning: LBA32 addressing assumed
Warning: '/proc/partitions' does not match '/dev' directory structure.
    Name change: '/dev/sdb' -> '/dev/sdb'
Warning: Name change: '/dev/sdb1' -> '/dev/sdb1'
Cannot proceed. Maybe you need to add this to your lilo.conf:
        disk=/dev/sdb inaccessible
(real error shown below)
Fatal: open /dev/sdb: No such file or directory
run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1

[Mti.]

zeptam se mozna mimo misu ... jak tento stav vlastne vznikl? To byl system puvodne na jinem disku a "nekdo" ho teprve zraidovatel/presunul? Nebo to byl donekonecna upgradovany starsi stroj s vlastnim kernelem? Update-initramfs umi jako parametr sezrat i seznam modulu, ktere si ma pribalit... tay raidove bych tomu urcite vnutil (zejmena jestli k tomu stroji neni dobry pristup)

(kdysi davno se u redhatu (6-7 ; kernel 2.4.neco byl jeste mlady) initrd nemuselo pouzit, kdyz si jeden zakompiloval raid do kernelu... a nebylo potreba neco zurive nastavovat... jen se to pak sdelilo lilu ... ale podrobnosti bych zjistoval dost tezko... halva uz neslouzi .. nicmene bych bezici rh.7.3 jeste nekde nasel )

[LuRy]

je to puvodne distro ispadminu ktery je na debianu takze predinstalovana distribuce s vlastnim nastavenim upravoval sem ji pro pouziti zaroven s ispconfigem + dist-upgrade na squeeze. jinak tvorba toho raidu vznikla tak ze to podporuje bios resp je tam nejaky bios kterej ten raid slozil do takovyho stavu sam se mse divil ze to neudelal hardwarove (neumi)

[Mti.]

no... nechcu byt drzy, ale vse toto se mohlo zminit uz na zacatku. Usetrilo by to vyptavani.

Jinak je smutne, ze tam tolik veci chybi. Otazka co jeste dalsiho tam neni. Sezen si nekoho, kdo Ti u te masiny pri resetu posedi Pripadne az to budes instalovat znovu, tak ten raid v biosu (jestli to je opravdu na nem) zrus a pouzij cisty sw-raid z linuxu.

[LuRy]

tak vicemene to je tak jak rikas raid spravuje linux.. problemem je ze pri startu nenacte druhy disk nebo se to proste rozpadne i po uprave mdadm.conf. mozna problem s tim lilem ze to nenacte pri startu.. jenze grub je docela risk tam hodit choval se nejak divne.. mozna znate nejakej vir nebo ja nevim uz tka mi to prinesli nezabezpeceny deravy neaktualizovany a pak po jednom restartu pres celej monitor samy 99999 po nekolika rozbti partition a formatu se disk chytnul aspon takhle ale grub se pri nacitani kousnul hned po "odentrovani" vyberu .. lilo to prechroupalo a rozjelo se to

[dustin]

Myslím, že v tomto vlákně začíná docházet k řadě nedorozumění.

1. Raid v biosu a přesto bezproblémů spravovatelný přes mdadm? Nevím, fake raidy jsem nikdy nepoužíval, ale opravdu jsou spravovatelné přes mdadm? Nějak se mi to nezdá, IMO jde o normální linuxový softraid.

2. lilo vs. grub. Myslím, že lilo by mělo stačit, nikdy jsem s ním problém neměl. Doporučoval bych přechod na grub, je to opravdu daleko flexibilnější. Není důvod, aby to nešlo, pokud to házelo chyby, určitě šly vyřešit.

3. initrd - jak říkám, nevím, zda pro root na raidu je potřeba initrd. Pokud ano, opět není problém na něj přejít. Ten update-initramfs výše vyhnil právě na aktualizaci historického lilo.conf, třeba by s grubem problém neměl.

Určitě to jde nějak vyřešit (a bude to nějaká ptákovina), zatím bych nic nepřeinstalovával. V tom systému je pár historických technologií, které by to nejdříve chtělo zaktualizovat (min. lilo na grub), kdo ví, jak jsou stále ještě v update skriptech podporované a hlavně otestované.

[LuRy]

jsem zastance grubu ale pri pokusu o instalaci mi zustal nabeh vyset na Welcome to GRUB a dal se to semnou odmitlo jakkoliv bavit tak sem musel nabootovat nejaky distro a preinstalovat to lilem ktery puvodne v ty predinstalovany distribuci (ispadminu) bylo

[dustin]

A jak jsi jej instaloval? Používal jsi nástroje v debianu (grub-install, update-grub, atd.)?

[LuRy]

http://www.i4wifi.cz/img.asp?attid=225715 podle tohodle akort partisnu sem tvoril pres liveboot gpartedu tusim ale s nastavenim stejnym linux raid autodetect.. ale uz je to nejaky ten patek zpatky instaloval sem funkcni system strasne dlouho protoze sem tam prvne nacpal ispadmina a premaznul mbr grubem kterej se zahryz a lilo uz tam nechtelo zpatky

[Mti.]

Sezen lidi a cas a dojdi k te masine. Nech tam smrdet alespon jeden cely prubeh memtestu (protoze to co pises smrdi nejakym hw problemem) a zbav se toho biosiho raidu, pokud to jen trochu pude. Zejmena jestli na tom dlouhodobe zavisi "vetsi" sit.

Vir uz je ten bios-raid. Je mozne, ze pri startu systemu bios prizna jen 1 disk (ten "raidovy") a proto se kernel pri startu nepokusi o rebuild...

[dustin]

Biosí raid lze taky konfigurovat přes mdraid, používá uuid a celkově se tváří stejně, jako swraid? Nevím, nikdy jsem jej nepoužíval, jenom mi to přijde zajímavé (a nepravděpodobné).

[Mti.]

biosi raid snad nejde... ale jestli ho nekde vytvoril a kernel o nem nevi (nema "spolehlivy" driver) , muze to delat buurdel.

biosi raid sem taky nikdy v linuxu nepouzil... jen 1x na stroji s windowsy a chodim kolem te masiny obzvlast opatrne :-/

[LuRy]

asi to vidim na to ze se bude muset poridit hw raid a reinstall .. mam na jednom serveru hw raid od adaptecu s 256MB baterii zalohovanou cache a nemuzu si vynachvalit.. uz jednou sem mel problem s md raidem 0 a nakonec a ted sem do toho vletel hlupak znova :D .. kazdopadne diky za tu radu ohledne toho memtestu to me nenapadlo je fakt ze se ten pocitac chova prazvlastne hlavne po tom "viru" nebo co to bylo mel sem podezreni na disky ale kdyz uz sem nekolikrat rozbil partisny a udelal x formatu a porad byl problem trochu to smrdelo.. je mozny ze by tohle delaly pameti? parkrat se i samovolne restartnul bez jakyhokoliv zaznamu v logu

[lertimir]

No trochu tomu nerozumím. HW raid má podle mne hlavní výhodu ve chvíli, kdy zátěž na serveru je taková, že hlavní procesor nestíhá počítat raid pro zátěž, jinak spolehlivost HW a SW raid je stejná (tedy pokud je paměť v pořádku). A problém s raid 0? RAID 0 je dle mne jedině na dočasné temporální úložitě vytvořené pro rychlost, nikdy jsem od nich neočekával žádnou spolehlivost.

[LuRy]

necham dodelat to recovery (jeste cca 372 minut :D ) a uvidim pak po resetu co to udela

[jekub]

fake raid v biosu?

[LuRy]

oprandu netusim sam sem to videl poprvy .. proste po biosu nabiha druhej bios toho radice ve kterym sem vytovril raid a pri instalaci os se tvaril jako md0

[jekub]

Zruste ten raid v biosu a mate (podle me) po problemu. Kdyby to byl opravdovsky raid(™), videl byste v systemu jen to, co by nastavil raid radic.

[LuRy]

no problemem je ze vu toho serveru fyzicky nejsem a je to trochu problematicke se k tomui dostat byt jen jej vyradit protoze monitoruje + ridi celkem rozsahlou sit klientu.. proc vidite problem v tom raidu pres bios? ja vidim problem pri zavadeni systemu ze se proste nenacte pri initu nebo tak neco

[jekub]

rekl bych, ze sw bios raid rozhodi sw Linux raid pri kazdem restartu a pak je potreba delat synchronizaci. Mozna mate problem i jinde, ale timto bych zacal.

[lertimir]

Zásadní problém pro RAID v BIOSu, že nevíte, co vám to dělá. Jak a kam se, co počítá zabezpečuje chip na motherboardu a tím pádem je to obtížně přenositelné, protože jiný chip to může počítat jinak. V SW raidu RAID počítá hlavní procesor všude stejně. Při poruše desky je dost nízká pravděpodobnost, že dáte dohromady disky běžící na BIOS RAIDu, při poruše desky na SW RAIDU se nestane nic, pokud zároveň porucha neodpálí i elektroniku disku, přehodíte desku a jedeta stejně dále. Také jsem BIOS RAIDy nikdy nepoužíval a právě si myslím, že spravovat je přes mdadm nejde, a myslím že ty BIOS RAID jsou natvrdo provázány s Windows s tím že ten BIOS RAID není plný fyzický RAID jak byste měl třeba s řadičem od ADAPTECu, kdy byste vůbec neměl vidět jednotlivé disky, ale jen ten RAID jako /dev/sda. BIOS RAID chápu jako nějaký hybrid, který má částečnou HW podporu a potřebuje driver do widlí. To že s tím pracujete přes mdadm podle mne znamená, že ten BIOS RAID obcházíte a pracujete s disky přímo, a je možné, že právě při startu ten BIOS RAID do komunikace s disky nějak zasahuje a mdadm se dobře nedomluví.

[LuRy]

parada z nejakeho duvodu mi zmizely vsechny /dev/sd* ... fdisk -l nevypise absolutne nic a mount zalozniho disku na /dev/sdc1 skonci s mount: special device /dev/sdc1 does not exist

pritom ale dmesg

scsi 5:0:0:0: Direct-Access     ATA      SAMSUNG HD753LJ  1AA0 PQ: 0 ANSI: 5
sd 5:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB)

[Mti.]

Vyborne. Nabootovat live, vyzalohovat (pokud uz neni) a zacit znovu a poradne. A pred tim se zbavit toho fake raidu a otestovat ram.

[LuRy]

To je dokonalej ocistec spojovat 2 systemy do sebe.. to uz se na to radsi vyto.. a necham to jak to je :/

[Mti.]

ehm... jake 2? Byla rec o debianu (pripade cemsi na nem zalozenem), ne?

[LuRy]

omlouvam se za nepresny termin systemy -> nastaveni serveru jasne debian 5.0 x64 s ispadminem coz znamena s temer prekopanym debianem k obrazu a fungovani ispadmina bohuzel jsem chtel pouzivat ispconfig a zkloubeni 2 nastaveni byl docela ocistec hlaven webserver nastavit tak abych nemusel prepisovat x milionu konfu cronu a buhvi ceho kuli cestam a podobne.. navic ten system je znacne zastaralej (jeste lenny s pomerne old aktualizacema) takze dist-upgrade na squeeze a modlit se aby se neco nevysralo

[trubicoid]

bez initrd jde bootovat do / ktery je zaroven pole, je potreba pouze prvni dve veci, ta posledni vec pomaha proti samovolnymu prejmenovani:

1. typy partisen, ze kterych se pole sklada je fd = Linux raid autodetect

2. superblock v poli je verze 0.90, jinak to nefunguje; tedy pri vytvareni mdadm --create blablabla -e 0.90 blablabla

3. parametry jadra treba takto: ... root=/dev/md1 md=1,/dev/sda2,/dev/sdb2,/dev/sdc2 ...

jinak si taky myslim, ze bios neco na disky napise, protoze si mysli, ze to je jeho pole a pak linuxovy md disk z pole vyhodi...

takze RAID v biosu zrusit a dat tam AHCI a hotovo

[MMichal]

Neni mozne, ze se o sestaveni pole pokousi zaroven mdadm i dmraid ?

[LuRy]

md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
md: multipath personality registered for level -4
md: faulty personality registered for level -5
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 1 and added 1 devices.
md: autorun ...
md: considering sda1 ...
md:  adding sda1 ...
md: created md0
md: bind<sda1>
md: running: <sda1>
raid1: raid set md0 active with 1 out of 2 mirrors
md0: detected capacity change from 0 to 989999333376
md: ... autorun DONE.
 md0:
EXT3-fs (md0): recovery required on readonly filesystem
EXT3-fs (md0): write access will be enabled during recovery
EXT3-fs (md0): recovery complete
EXT3-fs (md0): mounted filesystem with writeback data mode
EXT3-fs (md0): using internal journal