RAID laite hukassa - wrong fs type, bad option, bad superblock on [RATKAISTU]

[tikola]

Tarina menee näin. Minulla on vuosia palvellut RAID-1 pakka (10.04 64bit Ubuntu), jota käytän kodin tiedostopalvelimena verkon yli. Viikolla huomasin, että jostain syystä en pysty antamaan Itunesissa tiedostoille mp3 tageja, siis esittäjän nimeä ja sitä rataa. Syy paljastui kun aloin käytellä Ubuntua suorana ja yritin kopioda tiedostoja raid levyjaolle. Ilmoitus oli jotain busy tai denied, eli pystyin lukemaan mutten kirjoittamaan.

Sen jälkeen kokeilin normaalikonstit md laitteen uudelleenkäynnistyksen ja koneen buuttauksen ja nyt olen päässyt siihen tilaan että md laite käynnistyy, mutta sen mounttaus ei onnistu. Virheilmoitus kertoo:

sudo mount /dev/md0 /home/tikola/data
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so


Kun sitten aloin kokeilla kaikkea vähää mitä mdadm komennosta ymmärrän sain ulos seuraavia tietoja:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : active raid1 sdc1[0] sdd1[1]
      976759936 blocks [2/2] [UU]
      unused devices: <none>


sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sun Jul 19 16:29:53 2009
     Raid Level : raid1
     Array Size : 976759936 (931.51 GiB 1000.20 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Fri Jun 17 01:39:38 2011
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 925e226b:c1661175:5c658924:daf7db08 (local to host serveri)
         Events : 0.91684

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1


tikola@serveri:~$ dmesg | tail
[ 2917.458271] md: md0 stopped.
[ 2917.461336] md: bind<sdd1>
[ 2917.462588] md: bind<sdc1>
[ 2917.496878] raid1: raid set md0 active with 2 out of 2 mirrors
[ 2917.496907] md0: detected capacity change from 0 to 1000202174464
[ 2917.497357]  md0: unknown partition table
[ 2929.570056] journal_bmap: journal block not found at offset 3323 on md0
[ 2929.570059] JBD: bad block at offset 3323
[ 2929.570065] JBD: recovery failed
[ 2929.570066] EXT3-fs: error loading journal.


Kaikesta tuosta sain pääteltyä että levyt todennäköisesti ovat kunnossa, mutta jokain on nyt mennyt vikaan ja partition table tai joku muu kriittinen käynnistymisen kannalta olennainen komponentti on hukassa. Koska olen mdadm ja muiden levytyökalujen kanssa hieman noviisi olen hyvin varovainen ennen kuin jakelen mitään kokoa pakka uudelleen komentoja.

Mitä minun pitäisi tehdä jotta arvokkaat kotitiedostot saisin taas normaalisti käyttöön. Backuppi on kyllä muutaman viikon takaa, eli mitään korvaamatonta ei ole tapahtunut, mutta toisaalta en usko vielä minkään pahemmin rikkoutuneenkaan oikeasti.


timo

[L.General]

Kurkkaapa Järjestelmän graafisesta levytyökalusta kummassa levyssä on virhesektoreita. Sieltä saattaa pystyä liittämään taltion halvaantuneenakin että saat tiedostot talteen. Oma RAID5-pakka ei suostunut mounttaamaan käynnistyksen yhteydessä, koska yhdessä levyssä oli muutama viallinen sektori.

[tikola]

Molemmat levyt näyttävät pelkkää vihreää ja "disk is healthy". Mikään ei siis indikoi, että joku levy olisi rikki tai olisi huonompi kuin toinen. Siis jos kyse on tuosta viallisista sektorista niin mikään mitä osaan katsoa ei siitä kyllä minulle kerro. Siis vaikka tuolla yhdessä ensimmäisen viestini rivissä puhutaan "bad blockista" en osaa noilla graafisilla työkaluilla päätellä kummalla levyllä se on vaiko kummallakaa.

Toisekseen olen sen peilatun RAID-1 levypakan tehnyt juuri turvautuakseni levyrikolta ja jos se nyt yhdestä levystä menisi noin kyykkyyn niin eikös koko vaiva olisi turha. Tosin tässä voi olla kyse myös minun vajaasta ymmärryksestä Linux softaraidia kohtaan.

[L.General]

Minullakaan RAID-pakka ei mounttaannu käynnistyksessä viallisena. Graafisella levytyökalulla sen olen saanut käyntiin, jos bootissa on tullut virheitä. Tiedot ovat todennäköisesti tallessa, pitäisi saada vaan pakka käyntiin ja liitettyä että saisit otettua tuoreemman varmuuskopion. Sen jälkeen voisi turvallisimmin mielin etsiä vikaa. Voit myös ajaa levytyökalulla SMART-levytestejä jos pääsisit ongelmaan käsiksi.

Mikäli RAID-pakan epäonnistunut liittäminen bootin yhteydessä tuottaa ongelmia voit estää sen kommentoimalla (#) /dev/md0 rivin /etc/fstab:stä.

Eli:

Koodia: [Valitse]

sudo gedit /etc/fstab
Ja laita #-merkki rivin alkuun jossa esiintyy /dev/md0

[tikola]

Minusta minulla RAID pakka nousee pystyyn tai ainakin kaikki kielii minulle siitä. Kaikki pakan levyt ovat Health tilassa graafisen työkalun mukaan. Koetin ajaa kaikki tarkistukset mitä graafinen työkalu tarjosi, mutta mitään muutosta ei tullut. Ohessa kuvankaappaus levytyökalustani:



Mikään ei siis kieli edelleenkään minulle että joku levy olisi rikki - vaikka todennäköinen syy se onkin. Jokin olennainen partition table tai vastaava siellä on nyt rikki.

Graafisesta työkalusta saan pysäytettyä ja startattua RAID laitteen samoin kuin komentoriviltä. Check Array menee hienosti läpi eikä valita mitään. Check file system antaa selvän viestin File System is NOT clean. Miten voisin siis sen korjata tyhjentämättä samalla koko pakkaa.

timo

[L.General]

Ajoitko pintatarkistuksen noille teran levyille erikseen valitsemalla ne tuosta vasemmanpuoleisesta listasta? Vaikka ne ovat pakan osana niin voit silti ajaa levyn lukutestejä erikseen kummalle tahansa levyistä. RAID näyttää olevan käynnissä mutta osiointia ei ole tunnistettu.

[tikola]

Luultavasti ajoin, mutta ajelen ne nyt kaikki järjestelmällisesti uudestaan, jotta olen ihan varma. Joka tapauksessa jokaisen pakassa erillisenä olevan levyn kohdalla lukee vihreällä levyn olevan "Healthy".

Siinä välissä kun jätän ne ajelemaan tarkistuksiaan käyn tuossa juoksemassa Jukolan viestin ja palaan huomenna aiheeseen puolenpäivän jälkeen.

timo

[tikola]

fsck.ext3 -fyc /dev/md0 taisi ratkaista ongelman Jukolan viestin aikana, koska nyt kotona buutattuani koneen homma alkoi taas pelata. 8 bad inodea tai jotain sinneppäin se löysi ja väitti korjanneensa. Koetan ajaa graafisella työkalulla vielä levyjen testit ja katsoa voisinko paikantaa missä levyssä ne vialliset sektorit tai vastaavat ovat ja pistää kyseisen levyn vaihtoon

kiitokset kommenteista

timo

[qwertyy]

Eikös tuo inode virhe viittaa enemmän siihen, että tiedostojärjestelmä on seonnut väärän sammuttamisen tms. takia? En ole varma asiasta, mutta muistaakseni tuo ei viittaa suoraan aseman fyysiseen vikaan.

[tikola]

Poistetaanpa tuo hätäisesti laittamani ratkaistu tuolta otsikosta. Se toimi tunnin pari ja sen jälkeen putosi taas "vain luku" moodiin. Kaikki minusta viittaa siihen, että mikään levy ei ole rikki, koska kummankaan levyn diagnostiikka graafisella työkalulla ei palauttanut mitään virheitä. Tämän hetken tilanne on se, että koetan saada kaiken kopioitua ulkoiselle USB levylle, jonka jälkeen formatoin RAID1 pakan ja siirrän datat takaisin sinne.  Minusta kaikki kielii siitä, että levyjärjestelmä on jotenkin seonnut ja se aiheuttaa kaiken havaitun. Sinällään se on harmillista, sillä RAIDilla olen nimenomaan hakenut varmuutta ja nyt sitä en saa kun se sekoaa omia aikojaan.

Olisiko jollakulla loitsua jolla tiedostojärjestelmän saisi korjattua formatoimatta sitä - fsck teki sen kyllä, mutta ei nähdäkseni pysyvästi vaan jäi ikuiseen luuppiin toistamaan korjausta ja jokaiselle kerralla antoi samat virheilmoitukset.  Otan ne ilmoitukset seuraavalla kerralla talteen kun näen ja pistän tänne jakoon, jotta joku osaavampi voi niistä päätellä jotain. Ongelma tässä on se, että jokainen repair kierros ottaa muutaman tunnin ja siksi en saa virheilmoitusta esiin juuri sillä sekunnilla kuin haluaisin.

timo

ps. Välipalana yritän saada USB levyä toimimaan samassa roolissa kuin RAID laite on ollut (kolmen hakemiston Samba jako) - sain hakemistot kivasti näkyviin, mutta ongelma on nyt etteivät oikeudet riitä hakemiston sisälle menemiseen. Normaali sudo chmod ei oikein tunnu tarttuvan USB levyn hakemistoihin.

[tikola]

Tässäpä sitä fsck:n saldoa. Käytännössä muutama illegal block jotka ohjelma väittää "clearenaasa", jonka jälkeen ajo pyörähtää uudelleen käyntiin ja löytää ne samat ja jatkaa tätä käsittääkseni ikuisessa luupissa....tai ainakin vuorokauden mittaisessa luupissa, koska en ole vielä pidempään odottanut.


timo




tikola@serveri:~/data$ sudo fsck.ext3 -fyc /dev/md0
e2fsck 1.41.11 (14-Mar-2010)
Checking for bad blocks (read-only test): done                               
/dev/md0: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Inode 8 has illegal block(s).  Clear? yes

Illegal block #755818 (4202056824) in inode 8.  CLEARED.
Illegal block #755819 (2334909638) in inode 8.  CLEARED.
Illegal block #755820 (777311745) in inode 8.  CLEARED.
Illegal block #755821 (3838303690) in inode 8.  CLEARED.
Illegal block #755822 (3447371010) in inode 8.  CLEARED.
Illegal block #755823 (1717127755) in inode 8.  CLEARED.
Illegal block #755824 (3418850519) in inode 8.  CLEARED.
Illegal block #755825 (1886901272) in inode 8.  CLEARED.
Illegal block #755827 (2628886881) in inode 8.  CLEARED.
Illegal block #755828 (1788243645) in inode 8.  CLEARED.
Illegal block #755829 (3757754683) in inode 8.  CLEARED.
Too many illegal blocks in inode 8.
Clear inode? yes

Restarting e2fsck from the beginning...
Checking for bad blocks (read-only test): done                               
/dev/md0: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Inode 8 has illegal block(s).  Clear? yes

Illegal block #755830 (2331230713) in inode 8.  CLEARED.
Illegal block #755831 (4069862959) in inode 8.  CLEARED.
Illegal block #755832 (1473100121) in inode 8.  CLEARED.
Illegal block #755833 (4014277019) in inode 8.  CLEARED.
Illegal block #755834 (4222152906) in inode 8.  CLEARED.
Illegal block #755835 (1238563863) in inode 8.  CLEARED.
Illegal block #755837 (1276651951) in inode 8.  CLEARED.
Illegal block #755838 (2726078057) in inode 8.  CLEARED.
Illegal block #755839 (3026429348) in inode 8.  CLEARED.
Illegal block #755840 (2388179278) in inode 8.  CLEARED.
Illegal block #755841 (2861141769) in inode 8.  CLEARED.
Too many illegal blocks in inode 8

[L.General]

Nyt menee vähän yli oman kokemukseni, mutta löysin aihetta käsittelevän linkin.
Muissa yhteyksissä vihjailtiin useammassakin paikassa että levy saattaa olla rikkoutumassa. Inhottava tilanne mikäli se rikkoutuu tuolla tavoin että se jättää systeemin toimimattomaan tilaan.

http://www.clip.dia.fi.upm.es/~cochoa/wiki/index.php/Linux_hints:_a_bit_of_everything

[tikola]

Ja tästä googlatusta vinkistä iso käsi L.Generalille

Tästä minulla oli kyse ja tämä auttoi. Nyt pitää sitten vain pohtia ja seurailla onko levyssä vikaa, vaikka mikään ei siitä kerro vai oliko tässä vain kyse siitä että kahden vuoden päälläolon jälkeen bitti sattui menemään poikittain.

Suuret kiitokset avusta Kenraalille ja muille

Timo

Nyt menee vähän yli oman kokemukseni, mutta löysin aihetta käsittelevän linkin.
Muissa yhteyksissä vihjailtiin useammassakin paikassa että levy saattaa olla rikkoutumassa. Inhottava tilanne mikäli se rikkoutuu tuolla tavoin että se jättää systeemin toimimattomaan tilaan.

http://www.clip.dia.fi.upm.es/~cochoa/wiki/index.php/Linux_hints:_a_bit_of_everything

[L.General]

Hienoa että ongelma ratkesi! 

[tikola]

Palataanpa tähän ikivanhaan aiheeseen, koska teema tuntuu itselläni olevan edelleen ajakohtainen. Tällä kertaa hallitsematon buutti rikkoi RAID-5 laitteen. Käytännössä neljästä levystä kaksi unohti olevansa osa RAID5 pakkaa ja sen jälkeen alkoi kasa ongelmia. Käytännössä levyt luulivat olevansa RAID0 laitteita oikean viitosversion sijaan.

Näissä ongelmissa minulla homma tuntuu jotenkin aina päätyvän tuohon Bad Superblock teemaan.


Tämän linkin:
http://serverfault.com/questions/525965/recovering-raid5-array-after-zeroing-wrong-superblock

Rohkea komento puri:
sudo mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sde1 /dev/sdb1 missing /dev/sda1

Siis kun perus mdadm --assemble komennot eivät pure on mahdollista tietyin ehdoin palautua alkuperäiseen tilaan luomalla uusi laite mdadm --create komennolla. Jos palikat ovat uuden luomisessa samassa asennossa kuin alkuperäisessä hajonneessa, niin on hyvinkin mahdollista, että homma palautuu alkuperäiseen tilaan ja data pelastuu. Kieltämättä hirvitti kun komento kyseli, olenko ihan varma, mutta rohkeasti menin eteenpäin ja pääsin onnelliseen lopputulokseen.

Yhden kerran aiemmin on käynyt sama ja silloin menetin datani, mutta nyt tällä uudella tiedolla olisin ehkä silloinkin selvinnyt. No onneksi TV lähettää niin paljon uusintoja, että täydellinen palautuminen on vain ajan kysymys. Nyt kaikesta oppineena alkaa RAID laitteen remontti, jossa levyt siivotaan ja alustetaan parempaan kuntoon kuin ne tällä hetkellä ovat, jotta riski ongelmiin pienenee. Samalla RAID5 tulee päivittymään RAID6 muotoon, jotta senkin myötä riski ongelmiin pienenee.

Innostuneena positiivisia kokemuksiaan jakamassa  - Timo - jolla edelleenkin isoja puutteita perusteissa, mutta kokeilunhalua ja sinnikkyyttä sitäkin enemmän.

[L.General]

Mukava kuulla, että olet aktiivinen linux-käyttäjä vielä monen vuoden jälkeen.
Minulla oon tällä hetkellä RAID0-asetus kahdella 2Tb levyllä, joka on jaettu verkkoasemaksi.
Kun aikaa jää, opettelen käyttämään FreeNASia, asennus vanhassa pöytäkoneessa, viidellä erikokoisella kovalevyllä, jotka on muistaakseni määritetty RAIDZ1:ksi
Käyttötavaltaan hyvin RAID5:n kaltainen ja sallii yhden levyn vikaantumisen.

EDIT: Korjattu sekavaa kirjoitusasua.

[tikola]

Olen ollut Ubuntu ja VDR käyttäjä kaikki nämä vuodet. Minun järjestelmä on vain viimevuodet ollut sellainen, että siellä on ollut yksi Raid-1 laite, joka toimii kuin se kuuluisa junan vessa, mutta nyt uuden serverikoneen myötä kasvatin tallennustilaa ja siirryin RAID-5 laitteeseen. Se ja hieman muisteille krannttu epävakaa emolevy ovat nyt sitten poikineet näitä ongelmia. Käytännössä ongelma syntyy siitä, että levyjen kirjaimet saattavat hallitsemattomassa buutissa muuttua ja siitä sitten seuraa kaikenlaista. Kaksi perustavanlaatuista virhettä tein RAID laitteen perustamisessa, joita olen parhaillaan korjaamassa.

- Jos levyjä on useampi RAID-6 on parempi kuin RAID-5, koska RAID 6 kestää kahden levyn rikkoutumisen
- Tein laitteen koko levylle (SDA) - nyt muutan sen vain koko levyn kattavalle ensimmäiselle osiolle SDA1 - tämän pitäisi antaa parempi turva hallitsemattomaan buuttiin ja levyn osiotaulujen sotkeentumiseen

[tikola]

Toinen rohkea komento jota olen käyttänyt on:

sudo mdadm --assemble --force --invalid-backup --backup-file=foo  --run --verbose /dev/md127 /dev/sd[bcdef]

Eli madadm assemble komennolle kerron, että reshapen backup on invalid ja backup file on olematon, johon viittaan kuitenkin. Tämäkin auttaa tietyssä tilanteessa RAID laitteen herätyksessä rikkomatta dataa. Käytännössä siis silloin jos hallitsematon buutti tuli levypakan uudelleenjärjestyksen aikana ja ongelmaviestit sen jälkeen ovat esim.:
"MD127 has an active reshape - checking if critical section needs to be restored - backup not found"

Kyllä tämä linuxin softaraid laitteiden pelaaminen vaatii hieman rohkeutta ja ajoittain hyviä backuppeja, mutta kun jyvälle hommasta pääsee, niin vaikka mitä voi onnistuneesti tehdä.

timo

[tikola]

Tämä hieman jatkuu edelleen, eli buutissa tahtovat kiintolevyt vaihtaa /dev/sdx nimeään ja siitä seuraa ongelmia.

Nyt paneutumisen alla on seuraavat asiat

1) Miten /dev/sdx laitteen saisi lukittua aina samaksi - ilmeisesti ei ihan helpolla
2) Mikä on Superblock, jolla tunnistaminen kai tyypillisesti tehdään
3) Auttaisiko oikeanmutoinen mdadm.conf tiedosto
4) Entäs UUID pohjainen tunnistaminen
5) joku muu konsti

Eli kaikki toimii ja ongelmatilanteista osaan toipua, mutta kyllä tässä aktiivinen googlailu edellisten kysymysten osalta on käynnissä, jolla raid laitteen käynnistymisongelmia saisi paremmin haltuun. Nykytilanteessa ihan mdadm --assemble --scan /dev/mdX riittää ihan hyvin toipumiseen, eli noita edellisten viestien haastavampia juttuja en ole enää vähään aikaan tarvinnut. Olennainen parannus aiempaan on siirtyminen RAID-6 laitteeseen, jolloin yksittäisen (tai jopa kahden) levyn hukkaaminen ei ole niin dramaattinen tapahtuma.

Ongelmien lähde juontaa juurensa muisteista niipukkaaseen emolevyyn, jossa joudun ajoittain tekemään hallitsemattomia buutteja kun etsin käypäistä muistia. Toistaikseksi ajan yhdellä vakaasti toimivalla 2Gb kammalla, mutta olisihan hyvä että modernissa koneessa olisi pikkuisen enemmän muistia :-)

[nm]

1) Miten /dev/sdx laitteen saisi lukittua aina samaksi - ilmeisesti ei ihan helpolla

Normaalisti se pysyy samana, mutta bios voi vaihtaa järjestystä, jos levyohjainkonfiguraatio muuttuu jollain tavalla. Linuxissa udev saattaa myös aiheuttaa tunnisteiden muuttumisen raidissa, jos levy esimerkiksi irtoaa lennossa ja kytketään takaisin.

2) Mikä on Superblock, jolla tunnistaminen kai tyypillisesti tehdään

https://raid.wiki.kernel.org/index.php/Superblock

3) Auttaisiko oikeanmutoinen mdadm.conf tiedosto
4) Entäs UUID pohjainen tunnistaminen

Jep. Käytä levyn UUID:tä mdadm.confissa: http://serverfault.com/a/460139

Koodia: [Valitse]

# mdadmin --detail /dev/md0
/dev/md0:
        Version : 1.2
 ....
           Name : enterprise:0  (local to host enterprise)
           UUID : 7d2bf7e5:dc6edd5c:3ca12e46:8c9e5d4b
         Events : 48
mdadm.conf:

Koodia: [Valitse]

ARRAY /dev/md/0 metadata=1.2 UUID=7d2bf7e5:dc6edd5c:3ca12e46:8c9e5d4b name=enterprise:0