linux user group brescia

Il 23 febbraio 2010 17.56, Andrea Gelmini <andrea.gelmini a lugbs.linux.it> ha scritto:
> 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?
non ho guardato, ci guardo domani in ufficio, se ho tempo...

>
>> 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.
>
la soluzione è stata di recuperare il backup su un server di riserva
per non tenere le persone troppo ferme.
Se riesco faccio qualche analisi


> 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);
ok.
Visto che il server è in affitto (o in leasing, in ogni caso la
manutenzione hw non è a carico nostro) vedrò di metterlo in memtest
una notte...

> 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.
>
l'hardware verrà scrupolosamente controllato, visto che ora non c'è
più fretta, proprio perché l'ufficio parte con il server nuovo, e
anche per escludere guasti hardware dei quali altri si devono prendere
carico.


> Ciao,
> gelma

ciao e grazie
Andrea
>
> --
>