AIX mount hiba - S.O.S.

Naplózó filerendszerek (journaling)

Hello!

Kaptunk egy jopofa aramszunetet, ami az UPS-t is hazavagta (meg nyomozzuk)

Nem tudok mount-olni egy particiot, mert:

# mount /dev/fslv00 /dba
Replaying log for /dev/fslv00.
open: Device busy
mount: /dev/fslv00 on /dba: Unformatted or incompatible media
The superblock on /dev/fslv00 is dirty. Run a full fsck to fix.

FSCK-ra:

fsck /dev/fslv00

The current volume is: /dev/fslv00
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
File system inode map is corrupt; FIX?

Merjek Y-t nyomni?

AIX Version 5.3 with Oracle 9.2.0.7 a kornyezet.

  • 4211 megtekintés

( Zahy v | 2009. 08. 11., k – 16:02 )

Persze. (*)

(*) Kibicnek semmi se drága.

( frottirtigris | 2009. 08. 11., k – 16:08 )

Hmmm... azt hiszem, hogy a kérdés eléggé filozófikus. Io:
Ha nem próbálod meg kijavítani a filesystemet, nem tudod mountolni.
Az, hogy bele kell túrni az i-node map-be, viszont semmi jót nem jelöl.

Én a helyedben előkészíteném a backupot.
Másrészt, ha tudok olyan embert (vagy a supportot talán?) aki kézzel ki tudja bogozni az i-node táblát (amit azért kétlek) akkor cplv -vel lementeném az egész lv-t.
Amúgy meg nyomnék egy "y"-t, vennék egy mély levegőt.
A DB start során többnyire kiderül merre volt a hiba. Ha mázlid van az egyik control file sérült a sokból.

( dasync | 2009. 08. 11., k – 16:36 )

Hogy miért kell ennek fórumtémát nyitni... Backup ha fontos ugyis van belőle, nem (talán daily)? Yes, aztán hadd szóljon, most pillanatnyilag egyhelyben ücsörögsz, a szervíz meg nem megy, ha jól sejtem... a tököléssel néha több idő elmegy, mint a tényleges probléma megoldással....

( LGee | 2009. 08. 11., k – 17:36 )

errpt -ban esetleg valami relevans?

Olvastam egy-ket helyen, hogy a log device-ra lehetne nyomni egy logform-ot, peldaul ebben a technote-ban (igaz, az 5.2-re vonatkozik).

Amugy mi hasonlo esetben vagy felhivjuk a supportot (hiszen ezert fizetunk), akik altalaban kernek egy snap-et, vagy bevallaljuk a -y hasznalatat.

Ha a logform-ot ebben az esetben kiadod, akkor valszeg tényleg elbuktad a filerendszert!
Jelenleg ugyanis van egy crashelt rendszer egy closed FS, ami ráadásul sérült, a logform-mal pedig a befejezetlen tranzakciók logjait is elhagyod.
S onnantól biztosan rmfs, mklv, crfs, restore történet.

( Huncraft v | 2009. 08. 11., k – 19:45 )

Én azért amiatt az "open: Device busy" miatt megkérdezném, hogy az LV lokális, vagy remote elérhető? Mert ha ne addj isten valami lock szopat csak be titeket storage oldalról, akkor lehet jobb lenne azt kigyilkolni első körben, mielőtt még a mount hülyesége előtt szétvágjátok az FS-t :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Attól függ.. Elképzelhetőnek tartok egy olyan szituációt, ahol a Storage-tól kapott LUN-ok közül 1-2 nem elérhető. Ebben az esetben elméletileg még az AIX képes lehet varyon-olni a VG-t, de ha pont azokon a LUN-okon van az adott LV, akkor ez a hibalehetőség még belefér..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

errpt akkor igazán vicces, ha a /var FS-ed is besérült :DDDD Mert akkor aztán errpt az nincs :)) Amúgy lsvg-t is láttam már hülyeséget mondani, ahogy lspv-t is ( volt olyan eset, hogy nem konkurens VG esetében az AIX váltig állította, hogy egy VG (azonos LUN kiosztással ) mind2 oldalon aktív.. Persze, hogy az 1ik oldalon nem tudta használni, és telehányta az errpt-t..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..