Gå til innhold

Har et problem med ReiserFS V.3


Anbefalte innlegg

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?

Les slutten på det jeg sa. Ferdig? Les det en gang til. Svar så på følgende; impliserer jeg at det er hodet ditt som gjør at ReiserFS krasjer? Nei. Ofte er det slik at folk som har filsystemer som blir ødelagte kjører ustabile testversjoner av programvare eller ustabile kjerner. Jeg vet ikke hva du kjører og har da følgelig ikke sagt noe om hva feilen kan være hos deg.

 

Det er helt greit at et filsystem blir inkonsist, så lenge det greier å rydde opp etter seg ved boot. Personlig har jeg gode erfaringer fra ext2/3, ReiserFS og JFS. Har ikke testet XFS. Det hele kommer an på hvor ødelagt filsystemet og disken er. Det er mange som synes reiserfsck suger så det er en legitim grunn til det, men hva som mangler vet jeg ikke.

 

Btw; har du testet debugreiserfs(8) på partisjonen? http://namesys.com/faq.html#rebuild-tree sier også at følger du stegene deres, og ikke får det til, så skal de hjelpe deg. Vet ikke hvor mye jeg stoler på det, men du kan jo forsøke.

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

Sant nok, men med et litt finmasket søk så finner du mye å lese på.

http://www.ussg.iu.edu/hypermail/linux/ker...003.3/0812.html

dette f.eks.

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.

Tenker du på update(8)? Jeg skal ikke si at jeg vet dette med sikkerhet, men det ser da ut til at dette gjelder alle filsystemer.

Lenke til kommentar
Videoannonse
Annonse

Kjekling er kjekt.

 

Les slutten på det jeg sa. Ferdig? Les det en gang til.

 

"Færdig, papaaaa! Kom og tørk!" - Er de retoriske salvene fremdeles morsome?

 

Ofte er det slik at folk som har filsystemer som blir ødelagte kjører ustabile testversjoner av programvare eller ustabile kjerner.

 

Mm. Fett. Hva med "ofte er det slik at filsystemer som tryner er noe dritt.".

 

Jeg ettersøker her ditt grunnlag for å hevde at ting som går i dass kan forklares med (og du har nå vridd forklaringen din subtilt vekk fra "brukerfeil" til "eksperimentel sw", så jeg forholder meg da til det) at "'programvaren' er i en ustabil testversjon".

 

Men jeg må innrømme at jeg blir forvirret. Ser ikke helt hvor du har det ifra at et ustabilt program (eller kjerne, for å være ærlig, all den tid fs'et er kompilert inn som en modul) skal kunne fucke opp en journal-føring.

 

Det er seff mulig at jeg ikke har fått med med hva journal-føring i det hele tatt dreier seg om - eller at jeg ikke skjønner hvordan delegeringen av skrive- / lese-ansvar blir fordelt mellom kjernen og de fs-moduler den bruker.

 

Det er helt greit at et filsystem blir inkonsist, så lenge det greier å rydde opp etter seg ved boot.

 

Da er det ikke inkonsistent (inkonsist er noe annet), ettersom en journal med data og / eller meta-data blir fulgt. Journalen og filsystemet er da i sync, og man kan foreta rollback hvis nødvendig. Samsvar mellom journal og filsystem, med andre ord.

 

Det er mange som synes reiserfsck suger så det er en legitim grunn til det, men hva som mangler vet jeg ikke.

Det ryktes at tidligere versjoner av reiserfsck ikke kunne gjenopprette fs'et. Om det er tilfellet nu, skal jeg teste om 11 dager.

 

Btw; har du testet debugreiserfs(8) på partisjonen? http://namesys.com/faq.html#rebuild-tree sier også at følger du stegene deres, og ikke får det til, så skal de hjelpe deg. Vet ikke hvor mye jeg stoler på det, men du kan jo forsøke.

 

Takker for gode forslag, hadde faktisk ikke tenkt på debugreiserfs. Men jeg tror allikevel jeg venter til jeg har mulighet til å operere med en backup.

Lenke til kommentar

Kjekling er kjekt.

 

Les slutten på det jeg sa. Ferdig? Les det en gang til.

 

"Færdig, papaaaa! Kom og tørk!" - Er de retoriske salvene fremdeles morsome?

Tja. Jeg synes det. Vi har egntlig holdt oss ganske bra uten å ta frem de store flammekasterene, synes jeg. :)

 

Mm. Fett. Hva med "ofte er det slik at filsystemer som tryner er noe dritt.".

 

Jeg ettersøker her ditt grunnlag for å hevde at ting som går i dass kan forklares med (og du har nå vridd forklaringen din subtilt vekk fra "brukerfeil" til "eksperimentel sw", så jeg forholder meg da til det) at "'programvaren' er i en ustabil testversjon".

*sukk* Når har jeg vridd den vekk fra "brukerfeil" til "eksperimentel sw"? Jeg nevner at ofte er feilen med slike problemer personen bak tastaturet, uten å si at det gjelder deg. I tillegg sier jeg at det ofte er ustabil programvare som er skyld i slike feil. Er du ikke enig i at dette ofte er feilen(og for å understreke; dette vet jeg ikke noe om i ditt tilfelle, så jeg uttaler meg ikke om deg)?

 

Men jeg må innrømme at jeg blir forvirret. Ser ikke helt hvor du har det ifra at et ustabilt program (eller kjerne, for å være ærlig, all den tid fs'et er kompilert inn som en modul) skal kunne fucke opp en journal-føring.

 

Det er seff mulig at jeg ikke har fått med med hva journal-føring i det hele tatt dreier seg om - eller at jeg ikke skjønner hvordan delegeringen av skrive- / lese-ansvar blir fordelt mellom kjernen og de fs-moduler den bruker.

 

En ustabil kjerne kan selvfølgelig påvirke andre deler av OS-et ditt. ReiserFS er en del av kjernen så om kjernen er ustabil så kan det godt tenkes ReiserFS også er det. En feil i abstraksjonslaget vil da innvirke på filsystemet. Valget å kompilere reiserfs som modul eller rett inn i kjernen har sikkert noe å si, men er koden eksperimentell så har du færre garantier. Ser du på ext3 så ser du også feil som har sneket seg inn i stabile kjerner så noen ganger er det bare sånn. Det er ikke stort å gjøre med det, med mindre du kjører en velutprøvd, stabil distro. Å gi bleeding-edge software litt tid før du installerer kan spare deg for mye blod, svette og tårer(men dette vet du vel).

 

Da er det ikke inkonsistent (inkonsist er noe annet), ettersom en journal med data og / eller meta-data blir fulgt. Journalen og filsystemet er da i sync, og man kan foreta rollback hvis nødvendig. Samsvar mellom journal og filsystem, med andre ord.

Beklager. Min feil. Glemte en -ent.

 

Journalen og filsystemet trenger _ikke_ å være i synk. Det er hele vitsen med journalen. Når du har hatt et tryn, så går fsck gjennom journalen og prøver å rydde opp i ugyldige data. Det er i dag ikke mulig å få en ekte rollback med ReiserFS v3, da det bare en en meta-data journal.

Det ryktes at tidligere versjoner av reiserfsck ikke kunne gjenopprette fs'et. Om det er tilfellet nu, skal jeg teste om 11 dager.

Tidligere reiserfsck var sørgelige greier, men det har bedret seg. Jeg har fått det til, men jeg tør ikke si noe om hvordan det vil fungere for deg.

Takker for gode forslag, hadde faktisk ikke tenkt på debugreiserfs. Men jeg tror allikevel jeg venter til jeg har mulighet til å operere med en backup.

Det ser ikke ut som debugreiserfs(8) skriver noe til partisjonen så det ser trygt ut å teste før du har backup. Men du gjør nok ikke et dumt valg i å vente...

 

Namesys påstår de ikke lenger får feilmeldinger på ReiserFS v3. Enten må det være løgn, eller så har de et stabilt filsystem. Jeg gleder meg uansett til v4.

Lenke til kommentar
Masse punkter.

Ja, jeg tror vi stort sett er enige.

 

Min oppsummering er uansett at man skal forsøke å eliminere avhengigheten av å stole på "ting og tang", slik at man blir stående med minst mulig 'svake ledd' i resonnementet.

 

Mitt resonnement er da foreløpig:

* Dytt all data inn på et hardware raid (Promise SX-6000)

- Grunnleggende beskyttelse mot harddisk-feil

* Bruk XFS med to log-journaler

- Beskytter sånn noenlunde 'hjalla' mot journal-feil, uten at jeg trenger å sette meg sånn ugudelig grundig inn i ting.

* Mount read-only.

- Vel. Her vil jeg hevde at det ligger mye visdom. Det skal godt gjøres, etter mitt syn, å påvise svakheter ved dette. Ingenting er mer stabilt enn det som er dødt. ;)

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...