linux user group brescia

Il 23 febbraio 2010 17.19, Andrea Occhi <camicius a gmail.com> ha scritto:
> Il check è durato qualche ora (sono 147 GB di disco abbastanza pieno),
sì, tieni presente che incidono fortemente i numeri di file e il
numero di blocchi usati.

> e ha trovato una marea incalcolabile di errori (i più tanti di
> i_blocks e di i_acl).
hai trovato qualcosa in /lost+found?

> Poi sono riuscito a montare il filesystem e a tirar fuori i dati senza
> problemi.
Se hai modo fai comunque un raffronto a campione con un backup.

> Mi sembra impossibile che i gli errori si siano causati nello shutdown
> brutale. Può darsi che mesi di utilizzo abbiano man mano "danneggiato"
> il filesystem, percui ci si possa giovare da un periodico reboot (o
> dallo smontaggio-fsck-rimontaggio della partizione)?
In linea di principio no. Anzi, alcune parti dei metadata piu' critici
vengono pure checksummate per avere subito evidenza di un'eventuale
corruzione a runtime.
Pero':
a) RAM bacata/rovinata puo' comportare situazioni del genere (il
kernel scrive 0, ma sul filesystem ci finisce un 1);
b) Hard disk che fanno i furbi con la cache in scrittura e che non
onorano i sync() possono comportare quanto da te lamentato; un fsck
così lungo mi fa pensare a un caso del genere, visto che a quel punto
hai necessita' di un controllo ripetuto per essere sicuro di non
lasciare blocchi a zonzo;
c) vuoi ridere? questo puo' essere uno dei casi in cui la mancanza di
un journal ti da' piu' velocita' (il sistema scrive meno, con meno
generazione di seek), e piu' affidabilita', perchè l'interazione FS
<-> journal non viene compromessa da un eventuale hardware bugiardo.

Ciao,
gelma