Permalänk
Medlem

laga trasig ext3

Hej,

Jag är i situationen att jag har ett trasigt ext3 filsystem.
Försöker jag montera det som ext3 får jag felmedelandet: "mount: wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or helper program, or other error".
Det går dock utmärkt att montera filsystemet som ext2 (även som rw).
Kollar man på partitionen med ex. parted ser den ut som en ext2, men det är väl bara en "ettikett" i partitionstabellen?
Så är anledningen till att jag inte kan montera som ext3 "ettiketten" på partitionen eller har jag helt enkelt en trasig journal?
Har kört fsck.ext3 ett antal gånger, och den verkar oroväckande nog hitta fel varje gång (med växeln -f).
Hur skall jag gå vidare? Göra en konvertering från ext2 till ext3 med tune2fs?
Eller skall jag ge upp, ta backup, och börja med ett rent filsystem?

//Niklas

*edit* dmesg säger: "ext3: No journal on filesystem on md0" så jag kanske har svart på frågan själv... tune2fs -j ?

Permalänk
Medlem

har du provat o köra fsck.ext3 på den?

Permalänk
Entusiast

--EDIT----------------------------------------------

Ursäkta om det blev lite för detaljerat, men då andra även läser detta kan det vara bra med full förklaring.

Ser nu att det är md0 du försöker jobba med, det är alltså frågan om en raid.
Det verkar som om du har en ogiltig disk-setup i raiden.
Har du ändrat något bland hårddiskarna händer det att block-enheterna möbleras om och du måste på nytt peka om raiden till dem nya block-enheterna.

Kolla upp med mdadm om allt står rätt till.
Exempel:

# mdadm --misc --examine /dev/[s,h]d*

Jämför utdata från kommandot ovan med innehållet i filen /etc/mdadm.conf och se om du har rätt block-enheter signerade till md0

läs vidare om mdadm med man:

# man mdadm

--TIDE----------------------------------------------

Det bästa du kan göra är att börja om på ny kaka om du har en fullgod backup.
Har du data att rädda tror jag det bästa du kan göra är att först säkerhetskopiera hela partitionen i "rådata-form" till en annan disk med minst lika mycket utrymme som hela partitionen i fråga. Detta fixas enkelt med kommandot 'dd'

Angående dd: Växeln "if" står för "input file" och "of" för "output file"

Se först till att partitionen du skall säkerhetskopiera är monterad som "ro" (Read-Only)

I detta exempel:
sdz2 är partitonen som skall säkerhetskopieras.
/mnt/mounted-filesystem/ är punkten där du har tillräckligt med utrymme för backupen.

# mount -o remount,ro /dev/sdz2 # dd conv=notrunc,noerror if=/dev/sdz2 of=/mnt/mounted-filesystem/partition-backup-image.dd

Rad 1: Monterar om partitionen, om den är monterad, i read-only mode.
Rad 2: Kopierar rådata från partitionen sdz2, till fil med namnet "partition-backup-image.dd"

Fördelen med att säkerhetskopiera partitionen i "blindo" är att man sedan kan leka och testa med partitionen utan att riskera att data gårt förlorade ifall något går fel.
Skulle det gå fel är det bara att läsa tillbaka data med dd igen:

dd if=/mnt/mounted-filesystem/partition-backup-image.dd of=/dev/sdz2

Om dd -kommandot ger dig läsfel (io-error) har du en trasig hårddisk, byt ut hårddisken A.S.A.P - Troligen är det försent att rädda data, om det gått så långt att dd inte kan läsa partitionen.

Nästa steg efter "säkerhetskopieringen" är att försöka reparera filsystemet.
Du har redan försökt fsck, men prova dett i alla fall.
Återigen är partition sdz2 bara ett exempel, korrigera till den partition du skall försöka reparera.

# mount -o remount,ro /dev/sdz2 # fsck.ext3 -fvp /dev/sdz2

Rad 1: Monterar om partitionen, om den är monterad, i read-only mode.
Rad 2: Utan frågor, helt automatiskt, så kommer fsck utföra en analys och eventuell reparation av partition sdz2

Kom ihåg att fsck, även med -f, kan bara reparera partitioner som inte är monterade i skrivbart läge, därav remount -växeln i mount -kommandot.

Lyckas du inte trots detta, är det bästa att ta bort partitionen, skapa en ny partition och sedan fomrattera partitionen till valfritt filsystem.
Varför jag rekommenderar att ta bort partitionen och skapa den på nytt är för att skapa om en ny MBR utifall felet beror på en överlappande/ogiltig partition.

Permalänk
Avstängd

"Har du ändrat något bland hårddiskarna händer det att block-enheterna möbleras om och du måste på nytt peka om raiden till dem nya block-enheterna."

Vad betyder detta? Kan du ge exempel?

Permalänk
Entusiast
Citat:

Ursprungligen inskrivet av saddam
"Har du ändrat något bland hårddiskarna händer det att block-enheterna möbleras om och du måste på nytt peka om raiden till dem nya block-enheterna."

Vad betyder detta? Kan du ge exempel?

Jodå!

Block-enhet: Lagringsmedia eller minne. Tilldelas en nod i /dev -trädet.
Exempel på block-enheter:

┌SATA-Hårddisk, kanal 1: /dev/sda │ └ Partition 1: /dev/sda1 │ ├ SATA-Hårddisk, kanal 2: /dev/sdb │ ├ Partition 1: /dev/sdb1 │ └ Partition 2: /dev/sdb2 │ ├ SATA-Hårddisk, kanal 3: /dev/sdc │ ├ Partition 1: /dev/sdc1 │ └ USB-Minne: /dev/sdd . └ Partition 1: /dev/sdd1

En raid består av flera block-enheter.
Till exempel genom att kombinera /dev/sda1 och /dev/sdc1 bildar dessa två block-enheter en ny blockenhet med deras kombinerade lagringskapacitet.

Exempel:

┌SATA-Hårddisk, kanal 1: /dev/sda │ └ Partition 1: /dev/sda1 (raid-flaggad) │ ├ SATA-Hårddisk, kanal 2: /dev/sdb │ ├ Partition 1: /dev/sdb1 │ └ Partition 2: /dev/sdb2 │ ├ SATA-Hårddisk, kanal 3: /dev/sdc │ └ Partition 1: /dev/sdc1 (raid-flaggad) │ ├ USB-Minne: /dev/sdd │ └ Partition 1: /dev/sdd1 │ ├ Raid: /dev/md . └ Raid0 blockenhet 1: ( /dev/sda1 + /dev/sdc1 ): /dev/md/0

Tilldelning av nodnamn såsom sda, sdb och så vidare är tilldelad i dynamisk ordning som enheterna detekteras.

Skulle vi ta bort hårddisken på SATA kanal 2 kommer nod-tilldelningen bli annorlunda:

┌SATA-Hårddisk, kanal 1: /dev/sda │ └ Partition 1: /dev/sda1 (raid-flaggad) │ ├ SATA-Hårddisk, kanal 3: /dev/sdb │ └ Partition 1: /dev/sdb1 (raid-flaggad) │ ├ USB-Minne: /dev/sdc │ └ Partition 1: /dev/sdc1 │ ├ Raid: /dev/md . └ Raid0 blockenhet 1: ( /dev/sda1 + /dev/sdc1 ): /dev/md/0

I sista exemplet ser du nu att block-enheten /dev/md/0 är "trasig" då /dev/sdc flyttades till den lediga noden /dev/sdb, och nu är raiden inte komplett längre.

Försöker man reparera raiden i det här skicket kommer data på USB-minnet att gå förlorade då raid-konfigurationen fortfarande använder den noden som nu tas upp av USB-minnet istället.
Följd till detta är att filsystemet på /dev/md/0 inte är helt längre, då halva filsystemet flyttades till en annan nod.

I det här fallet måste man tala om för raid-konfigurationen att den skall använda /dev/sdb1 istället för /dev/sdc1.
Detta görs i filen /dev/mdadm.conf

När omkonfigureringen har gjorts kommer dem korrekta data att återigen finnas.

Att tänka på:
Försöker man ändra innehållet i en okomplett raid-konfiguration, kan data korrupteras.
fsck ser det som filsystem-fel när halva raiden har flytttats till annan nod.

Permalänk
Avstängd

HAHAHAHA!!! Shit vad du svarar utförligt då! Om det fanns en "tack" funktion här, så skulle jag tackat dig flera ggr om! Tack.

Permalänk
Medlem

Glömde bort denna tråden lite...
Tack för de utförliga svaren, hade hyfsad koll, men ändå intressant!

Ang. problemet så körde jag "tunefs -j" samt efterföljande fsck och det gick fint och rullar fortfarande utan problem, så jag kör nog vidare på det gamla filsystemet!