Newsgroup: it.comp.os.linux.sys
Titolo: AIUTOOOOO!!!! Ho un grave problema da risolvere in fretta.

Ciao a tutti, spero che qualcuno possa aiutarmi.
Sul server di un cliente si è rovinato un filesystem (ext2) con dati vitali
per il suo studio.
Il tutto è dovuto ad un crash improvviso del server (RH 6.2), che dopo un
fsck completo è ripartito lasciando inconsistenete solo (guarda un po') il
fylesistem piu' importante.
Non riesco ad utilizzare ne e2fsck ne dumpe2fs ne altri diagniostici
inquanto sembrerebbe corrotto il superblock.
Cosa posso fare? Conoscete strumenti piu' potenti? fsck -b block <device>
come va utilizzato?
Ho provato di tutto ma non riesco a risolvere il problema.
Confido nella Vostra solidarietà.
Bye!

 
Da  quando ho fatto in passato
e2fsck -b 8193 (o suoi multipli) /dev/tua-partizione 
altrimenti anche con parted si può fare un check della partizione
-- 
  ______             ____  _      ___  _         
 / ___(_)__ ____    /_  / (_)__  / _ \(_)__  ___ 
/ /__/ / _ `/ _ \    / /_/ / _ \/ ___/ / _ \/ _ \
\___/_/\_,_/\___/   /___/_/\___/_/  /_/_//_/\___/

scusate se mi intrometto, visto anche il problema dell'amico Davide al quale
sono pienamente solidale.
Ho sentito parlare sempre bene dell'ottima stabilità del file system ext2;
anche lui ha, quindi, dei buchi di stabilità?
Ovvero, con l'uso prolungato ed intensivo su un server, può corrompersi e
cioccare?
Ciao, grazie mille!
Francesco Collini

 wrote in message 3A193514...@alfa.it...

Purtroppo ho gia provato quello che mi dici senza risultati.
Se faccio un cat </dev/miofilesystem vedo i dati (ovviamente non sottoforma
di directory) man non trovando il superblock non riesco a montare la
partizione.
Tieni conto che di superblock ne ho provati tantissimi (ho fatto una shell
che li provava tutti incremendandoli di 8193 alla volta).
Sono disperato :-(((


mai successo....
e ti diro di più mai successo su un raid software (2.2.13ac3) con ext2 su tre
dischi da 9.1 giga in raid5.
...
ad ogni modo il journaling dovrebbe risolvere quel tipo di problema...ed essendo
io molto scaramntico non ti dico cosa uso e da quanto tempo.....

 Signature under rework - Shuriken
Grazie Alessandro, purtroppo niente da fare! La situazione č ancora la
seguente:
con cat </dev/miofilesystem vedo il contenuto degli archivi (migliaia di
archivi :-*), ma la macchina non riesce piů a trovare le informazioni sulla
struttura originale del filesystem. Comicio quasi a rassegnarmi.

 
Prova ad utilizzare parted in qualche caso mi ha aiutato
(e usa il reiserfs per i dati importanti ;-)))


>>>>> "FC" == Francesco Collini <f.co...@QUESTONONCIVAinwind.it> writes:
FC> Ho sentito parlare sempre bene dell'ottima stabilità del file
FC> system ext2; anche lui ha, quindi, dei buchi di stabilità?
Eh no! Smettiamola di lanciare anatemi contro questo o quel
filesystem. E poi, è il sistema operativo che gestisce il filesystem e
se questo si blocca il resto del sistema ha buone possibilità di
trovarsi in una condizione ambigua: dalle mie parti si direbbe «tra
l'uscio e il muro». È troppo generico dire "s'è bloccato Linux" e non
aiuta neppure a capire perché; di solito non si vede riportare neppure
un dettaglio, quando già basterebbe: "è stato il gestore ext2 a
bloccare il sistema" oppure "si è bloccato a causa di un errore
provocato dal gestore dello swap".
Un piccolo aiuto nei casi di emergenza può essere il MagicSysReq con
il quale si può tentare il sync del filesystem, dopo un errore di
qualche parte del kernel o di un componente vitale al sistema.
FC> Ovvero, con l'uso prolungato ed intensivo su un server, può
FC> corrompersi e cioccare?
Assolutamente NO. Extended2 è stabile da anni. Ci sono server che
girano ininterrottamente da più di un anno e non hanno avuto mai
problemi; altri che girano da anni con saltuari riavvii `pacifici' e
ancora nessun problema. Sono gli spegnimenti a raffica, senza sync sul
filesystem che possono portare a una situazione inconsistente.
Comunque, senza offesa, è idiota colui che usa un disco con dati
importanti senza fare neppure un backup ogni tanto (ore? giorni?
settimane?), almeno dell'importante appunto. Non date la colpa
al filesystem, ma al vostro comportamento incoscente.
Ciao
Marco polemico

qualche parte del kernel o di un componente vitale al sistema.
Saluti,
potete fornirmi qualche info in piu' sul MagicSysReq ?
A cosa vi riferite precisamente, quali documentazioni devo leggere?
Grazie.
Saluti, Libra.
-- 
     			      << Linux Powered >>	
              <><> e-mail: metti "libero" al posto di "NOSPAM" <><>

 writes:
Libra> Saluti, potete fornirmi qualche info in piu' sul MagicSysReq ?
Libra> A cosa vi riferite precisamente, quali documentazioni devo
Libra> leggere?
/usr/src/linux/Documentation/sysrq.txt
Vanno attivate prima della compilazione del kernel.
Sono combinazioni di tasti che attivano funzionalità di emergenza tipo
reboot, sync, remount-read-only...
Ciao
Marco

 ha scritto nel messaggio
news:3A1A3737...@alfa.it...


Elrond wrote:
Certo che reiserfs lo puoi usare per i dati normali e funziona
benissimo. Quello che ho scritto deriva dal fatto che normalmente
costruisco le partizioni reiser dopo che ho fatto le installazioni
normali e quindi rendo reiser solo i dati che giudico importanti.


 A cosa vi riferite precisamente, quali documentazioni devo leggere?
nella directory Documentation del kernel dovrebbe essergi un file
sysreq.txt o qualcosa di simile
ciao
Kronos
-- 
Home: 
http://kronoz.tsx.org
Ci sono due cose che l'uomo non puo' nascondere:
essere ubriaco ed essere innamorato.