Gå til innhold

Har et problem med ReiserFS V.3


Anbefalte innlegg

Problemet består da av utfordringen som ligger i å gjenopprette en krasjet reiserFS partisjon.

 

Vi snakker da i all korthet om "--rebuild-tree" med reiserfsck 3.6.11 (siste versjon fra namesys).

 

Slik ser problemet ut:

reiserfsck --check started at blah blah
###########
Replaying journal..
0 transactions replayed
Checking internal tree..finished
Comparing bitmaps..Bad nodes were found, Semantic pass skipped
164 found corruptions can be fixed only when running with --rebuild-tree
###########
reiserfsck finished at blah blah
###########

 

Jeg har da lekt meg litt med dd ("dd count=2000 bs=10M if=/dev/hdb5 of=fil_kopi_av_partisjon"), og en kopi av partisjonen (som er på totalt 103 GiB) med størrelse 20 GiB, og medfølgende gjenoppretting av denne kopien med "reiserfsck --rebuild-tree fil_kopi_av_partisjon" og mounting med "mount -t reiserfs fil_kopi_av_partisjon -o loop /mnt/temp" gir som resultat ca. 400 MiB filer opprettet, og noen Gig med filer "funnet" i "lost+found". Disse "funnet" filene ser ikke ved første øyekast ut til å kunne brukes til noe, men jeg har ikke kikket så nøye på dem med xxd.

 

Anyway, gode råd og innspill? IBAS? Vente 10 år på at Hans Reiser skal få fingen ut og lage en stabil gjenoppretter? Woot?

Lenke til kommentar
Videoannonse
Annonse
Hvis du har en backup: Hva sier reiserfsck --rebuilt-tree på den ødelagte partisjonen? Jeg har fikset ett par gnøkka filsystem med det tidligere.

 

Off-topic:

Den .sig'en der var en smule ekkel.

Har ikke kjørt backup på fullstendig kopi av partisjonen enda (103 GiB, og det har jeg ikke plass til foreløpig), men spørsmålet går vel foreløpig på om dd lager noe kluss med blocksize, eller om det kun leser i den størrelsen og skriver helt rent.

Vil i utgangspunktet anta det, men syntes det var litt rart at en 20 GiB del av partisjoen kun gav 400 MiB med redda filer.

 

OT:

Hvorfor er det igrunnen tillat å ha politiske signaturer, når dem støter folk?

Selv blir jeg støtt av dem som hevder at Gud velsigner amerika (flashback til "Gott mit uns" som nasistene kjørte på), og at de amerikanske troppene som dreper titusenvis av mennesker for olje skal støttes og velsignes.

 

Da stiller jeg meg heller bak Osama Bin Laden, Al-Quada, og hele hurven av palestinske og andre selvmordsbombere, som ikke rekker amerikanerne / britene opp til knehasene i antall drepte.

 

EDIT:

Staving.

Endret av DrDoogie
Lenke til kommentar
Hvordan skjedde dette egentlig? Helt ut av lufta?

Jeg fikk endel mystiske krasj, og siste gang skjedde det under avspilling av en låt på /dev/hdb5.

Jeg får så ikke mountet denne partisjonen, og sjekker den med reiserfsck. "Surprise, surprise, Hans Reiser is a faggot whose only interest is in putting experimental code into the linux kernel."

 

Eller kanskje det er en annen forklaring på hvorfor et filsystem som hevder å være journal-førende kan fucke opp på tross av at fsck kjører ved oppstart.

 

Nei, ikke vet jeg. Nå var det jo 3 måneder siden jeg sist skreiv til partisjonen da; den har stått mountet rw og jeg har slettet noen filer i ny og ne.

 

Nei heretter blir det XFS for alle penga, så kan reiserFS brenne litt. Det er til opplysning nå 12-13 måneder siden namesys lovte at reiserFS V.4 ville stå klart.

 

Go figure.

Lenke til kommentar

Har ikke kjørt backup på fullstendig kopi av partisjonen enda (103 GiB, og det har jeg ikke plass til foreløpig), men spørsmålet går vel foreløpig på om dd lager noe kluss med blocksize, eller om det kun leser i den størrelsen og skriver helt rent.

Vil i utgangspunktet anta det, men syntes det var litt rart at en 20 GiB del av partisjoen kun gav 400 MiB med redda filer.

 

Det kommer vel litt an på hvor ødelagt filsystemet er. Jeg tror ikke at 20GiB er nok til å avgjøre om det går eller ikke. Er disken fragmentert så antar jeg det dukker mye rart i lost+found, siden filene bare eksisterer i bruddstykker, men det skal jeg ikke si for sikkert. Før du har skaffet deg plass til sikkerhetskopi, eller du tør å kjøre rebuild-tree på partisjonen(jeg vil anbefale backup først), så kan vi vel bare spekulere.

 

Og ikke legg alt håp i XFS. Det er mere ekperimentelt. Filsystemer tryner. Sånn er det bare. "Grunnsolide" ext3 har hatt sine uheldige konsekvenser.

 

Off-topic igjen:

At du ikke liker hva USA m.fl. gjør; greit nok. Du stiller deg likevel bak mennesker som dreper andre uskyldige mennesker. Hvorfor må du velge mellom ekstremister(USA/Bin Laden)? Personlig synes jeg slik Hubba Bubba-ideologi er utrolig barnslig.

 

DrDoogie: Skal vi fortsette denne OffT-dikusjonen så gjør vi det i en passende gruppe. Send en melding med evt. tråd. Jeg styrte Linux-forumet med jernhånd en stund. Dette ville jeg nok slått ned på. :)

Lenke til kommentar

Og ikke legg alt håp i XFS. Det er mere ekperimentelt. Filsystemer tryner. Sånn er det bare.

 

XFS har vel kjørt stabilt på Irix sine servere i flere år før det ble portet til linux? De to siste oppdateringene av XFS (for linux) har vel vært:

1. Flekking ut av gammel, avleggs kode

2. Flekking ut av noe SCO-påstått plagiat dill & dall.

 

Men jeg ser ikke helt hvorfor min eminente plan med:

* Dytte XFS inn på RAID-5

* mounte ro

* ha duplisert transaksjonslogg på to forskjellige disker utenom raid'et

 

skal kunne gå galt.

 

Hvis du her vet om noen svakheter ved XFS, eller ved min fremgangsmåte, ønsker jeg mer enn gjerne å høre fra deg.

 

 

OT:

 

Off-topic igjen:

At du ikke liker hva USA m.fl. gjør; greit nok. Du stiller deg likevel bak mennesker som dreper andre uskyldige mennesker.

 

Til forskjell fra?

 

Personlig synes jeg slik Hubba Bubba-ideologi er utrolig barnslig.

Dette ville jeg nok slått ned på. :)

 

Så lenge det blir slått ned på begge sider av "ekstremismen", så er det en helt grei sak.

Lenke til kommentar

XFS har vel kjørt stabilt på Irix sine servere i flere år før det ble portet til linux? De to siste oppdateringene av XFS (for linux) har vel vært:

1. Flekking ut av gammel, avleggs kode

2. Flekking ut av noe SCO-påstått plagiat dill & dall.

 

Og om det kjørte stabilt på Irix så sier det _ingeting_ om Linux-støtten. Beklager. (Irix i seg selv er nå bare sånn passe spør du meg.)

 

XFS har hatt problemer med å komme seg inn i Linus' kjerner grunnet radikale endringer i hvordan Linux ser på filsystemer. Vet ikke hvordan dette ser ut i dag. Mange sier det er utrolig flott, men da helst på enorme filer. ReiserFS er absolutt best på masse små filer og masse kataloger. ext3 er midt i mellom. JFS ol. vet jeg ikke stort om. (rent bortsett fra at JFS fikk hw.no til å være nede i over en uke for noen år siden.) ;)

 

Men jeg ser ikke helt hvorfor min eminente plan med:

* Dytte XFS inn på RAID-5

* mounte ro

* ha duplisert transaksjonslogg på to forskjellige disker utenom raid'et

 

skal kunne gå galt.

 

Hvis du her vet om noen svakheter ved XFS, eller ved min fremgangsmåte, ønsker jeg mer enn gjerne å høre fra deg.

 

Som for alle andre filsystemer; Det er ingen garantier. Skal stabilitet være pri èn, så anbefaler jeg ext3. ReiserFS har jeg og mange andre kjørt stabilt i mange år. Det er ikke det samme som å si at det på noen måte er "best" eller helt stabilt, men Linus har nå tatt det med(første journaling-filsystem i Linux hvis jeg husker riktig...) og det sier da noe.

 

Hva er galt med ext3?

 

Sikkert masse, men ikke mye jeg kan si.

 

Se på følgende fil:

ftp://ftp.uio.no/linux/kernel/v2.4/linux-...dontuse.tar.bz2

Denne heter dontuse grunnet en ekkel bug i kildekoden til ext3(husker ikke om ext2 også). Ext3 har også hatt problemer og blir sikker å få det igjen.

 

Ext3 var et hack til ext2 som har blitt meget bra. Det er antakelig det beste filsystemet for folk uten sære krav. (siden man kan motere ext3 som ext2 så er det fint å fikse slike filsystemer.) Folk som meg og sikkert DrDoogie bruker andre filsystemer ofte for å teste de, eller fordi man har lest Noe om dette nye, fine filsystemet som man bare _må_ prøve. Det har som regel ingenting å si.

 

Til OffT:

Vi legger diskusjonen død. Vi er i feil forum til dette.

Lenke til kommentar

Reiser gjør så vidt jeg vet ingen forsøk på å redde inoder tapt ved korrupsjon, i motsetning til ext3 hvor disse havner i lost+found. Jeg har opplevd tapte filer med Reiser ca. 3 ganger etter hva jeg kan huske, dette har skjedd etter tvungen restart (frys). På grunn av dette kjører jeg nå kun Reiser på rotsystemet, som jeg jevnlig backer opp og ext3 på /home bla. Har ikke hatt noen problemer med ext3 så lenge jeg har kjørt det (hatt korrupt Reiser i mellomtiden). Har ikke så mye erfaring med rebuild-tree (mener jeg prøvde det en gang uten hell), men det virker ikke som det sikreste alternativet.

 

Edit: Angående XFS; et potensielt problem med dette så vidt jeg forsto er aggressiv caching i RAM, som kan være uheldig ved kræsj.

Endret av A_N_K
Lenke til kommentar

DrDoogie, synes din nye løsning med XFS, RAID5 og trans.logg skal være så sikker som du kan være uten at du skal kjøre tapebackup av alt du har hver time :)

Ang ReiserFS så er jeg veeldig fornøyd med det så lenge jeg ikke har noen hw problemer, men hvis disken begynner å fuske er man ofte fscked (kort og godt). Bruker ReiserFS på alt av desktop pcer, men ikke på servere. jeg lever i håpet om at ReiserFS4 skal ha bedre verktøy for redning av data enn v3.

Lenke til kommentar

Reiser gjør så vidt jeg vet ingen forsøk på å redde inoder tapt ved korrupsjon, i motsetning til ext3 hvor disse havner i lost+found. Jeg har opplevd tapte filer med Reiser ca. 3 ganger etter hva jeg kan huske, dette har skjedd etter tvungen restart (frys). På grunn av dette kjører jeg nå kun Reiser på rotsystemet, som jeg jevnlig backer opp og ext3 på /home bla. Har ikke hatt noen problemer med ext3 så lenge jeg har kjørt det (hatt korrupt Reiser i mellomtiden). Har ikke så mye erfaring med rebuild-tree (mener jeg prøvde det en gang uten hell), men det virker ikke som det sikreste alternativet.

Egenerfaringer er vanskelig å bestride.

 

http://www-106.ibm.com/developerworks/library/l-fs.html og videre utover er anbefalt lesning. Ofte er feil ved ødelagte filsystemer et resultat av feil et sted mellom tastaturet og stolen(jeg sier ikke at det er det i dette tilfellet, men ofte). Ref: Advarselen på Namesys' fremside ang. gcc 2.96 fra RedHat.

 

Googling på lkml er også mye fint lesestoff.

 

Jeg ville vel gjort filsystemrekkefølgen helt motsatt. Ext2/3 på rot og XFS/ReiserFS/ext3 på /home ol.

 

Edit: Angående XFS; et potensielt problem med dette så vidt jeg forsto er aggressiv caching i RAM, som kan være uheldig ved kræsj.

Det vet jeg ingenting om, men kan godt tenkes. Det sliter uansett alle filsystemer med med mindre man setter "force-write" el. som gjør filsystemet utrolig tregt.

Lenke til kommentar

DrDoogie, synes din nye løsning med XFS, RAID5 og trans.logg skal være så sikker som du kan være uten at du skal kjøre tapebackup av alt du har hver time :)

Bortsett fra at ext3 er sett på som et mere stabilt filsystem(i Linux)? Mange filsystemer har problemer med software-RAID(vet ikke om det er det som gjelder her) og ext3 er defacto-standard i Linux. Ext3 er også det desidert mest utbredte filsystemet i Linux(utenom ext2). Det er det en grunn til.

 

SUSE kjører vel ReiserFS per def?

 

Ang ReiserFS så er jeg veeldig fornøyd med det så lenge jeg ikke har noen hw problemer, men hvis disken begynner å fuske er man ofte fscked (kort og godt). Bruker ReiserFS på alt av desktop pcer, men ikke på servere. jeg lever i håpet om at ReiserFS4 skal ha bedre verktøy for redning av data enn v3.

Har du hardware-problemer så kan vel ikke ReiserFS få noen skyld i det. Da er du fscked uansett filsystem. Hvis du med FooFS greier å berge data så har du flaks, det er lite som har med kvalitet på filsystemet. Bare se på hva som blir mest ustabilt grunnet hardware-feil av Linux og Wintendo(Google sig 11). Selvfølgelig hadde det vært fint med et filsystem som taklet diskfeil bedre, men jeg tror ikke engang Veritas har det(kan ikke huske det i alle fall).

Lenke til kommentar

Det er jo det du har på /home som er farlig med. Operativsystemet kan jo uansett reinstalleres!

På desktop-maskinen din kanskje. Ikke alle har alt liggende under /home. De fleste servere har kanskje ingenting liggende under /home. (Eks: Universitetet i Oslo)

Lenke til kommentar

Ofte er feil ved ødelagte filsystemer et resultat av feil et sted mellom tastaturet og stolen(jeg sier ikke at det er det i dette tilfellet, men ofte).

 

Hvis du ikke her mener å implisere at det er hodet mitt som gjør at reiserFS har krasjet, kan du da fortelle oss om du mener det er akseptabelt at et journaling filsystem skal bli inkonsistent?

 

Googling på lkml er også mye fint lesestoff.

 

Der var det vel mye forskjellig, og litt vanskelig å finne noe relevant.

 

Jeg ville vel gjort filsystemrekkefølgen helt motsatt. Ext2/3 på rot og XFS/ReiserFS/ext3 på /home ol.

 

Godt poeng.

 

Det vet jeg ingenting om, men kan godt tenkes. Det sliter uansett alle filsystemer med med mindre man setter "force-write" el. som gjør filsystemet utrolig tregt.

 

XFS skriver journal-oppføringen først, og kan skrive selve data'ene hele 30 sekunder etterpå. Uansett, mounter man read-only, da skal det phaen meg godt gjøres at filsystemet skal fuske.

Lenke til kommentar

Jeg har i alle fall ting jeg vil ta vare på under /home. Men det er uansett en kjensgjerning at Reiser ikke gjør noe for å redde tapte inoder, utover tilbakespilling av journaler. Spørsmålet er da hvor robust Reiser er før det blir inkonsistens i filsystemet. Jeg husker i alle fall en gang at jeg mistet hjemmedir'et mitt, men fant igjen alt innhold i lost+found, men er ikke sikker på om dette var JFS eller ext3. En gang satt jeg med filer som var umulige å slette (enten Reiser eller JFS) :] Men så skal det sies at jeg har brukt utviklings-versjoner av kjernen en stund. Angående XFS og caching: Jeg mener at XFS er spesielt aggressiv på caching, og dette er noe av grunnen til at det er så raskt som det er. Altså ikke nødvendigvis en uting.

 

Edit: Oops, skrivefeil.

Endret av A_N_K
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...