Gentoo Forums

Proprio per l'uso esasperato delle 'tree structures', il filesystem XFS è particolarmente soggetto alla corruzione dei dati in memoria. Ecco quindi che in particolarissime situazioni, molto rare, la corruzione dei dati in memoria si trasforma in una corruzione dei dati fisici presenti in XFS o nella sua struttura (inodes).

Se questo dovesse succedere, XFS genera a video messaggi di warning relativi a problemi di I/O, nei logs vengono generati errori di I/O sulla periferica IDE/SATA/SCSI e tutto l'intero sistema si paralizza. Il reboot della macchina non sortisce nessun effetto, appena il FS viene ri-montato vengono segnalati nuovamente a video i warning di I/O e tutto il sistema operativo si blocca nuovamente.

esempio di errore I/O rilevabile nei logs: Gli user più impavidi si armano di livecd o di altro cd-rescue, e fanno un check della partizione con xfs_check e xfs_repair sperando nel miracolo, ma aimè xfs_repair si fermerà sempre mostrando a video il seguente errore:
Qualsiasi tentativo di riparazione o check del FS tramite i tools presenti in xfsprogs, non sortirà nessun effetto, ne risolverà l'annoso problema. Questa situazione, spesso e volentieri, viene scambiata dall'utente inesperto come una corruzione totale del FS e in genere si procede alla formattazione, sparando poi a zero nei forums e nei ng sul fatto che il 'cattivo XFS gli ha mangiato tutti i dati' (dando vita alle valanghe di flames sui FS).

Eppure, nonostante i fatti dicano il contrario, io affermo con assoluta certezza che: con il filesystem XFS i problemi di corruzione non esistono, ed è impossibile corrompere una partizione XFS

Innanzi tutto, pochi sanno che appena si verifica una corruzione dei dati o della struttura del FS, anche minima, XFS per preservare i dati ed evitare danni maggiori, entra in modalità 'freeze' bloccando ogni successiva scrittura sul disco; ciò genera i messaggi di errore di I/O. la modalità 'freeze' viene tolta solo quando i problemi di corruzione vengono risolti, altrimenti resta sempre attiva. ATTENZIONE: è il freeze di XFS che genera i messaggi di errore, non la corruzione del FS !!

In secondo luogo, pochi sanno che una volta che il filesystem è entrato in modalità 'freeze', i tools di riparazione (xfs_repair) non possono correggere automaticamente le corruzioni in cui si imbattono, e quindi si bloccano perchè attendono un intervento 'manuale' da parte dell'utente, e questo genera il famigerato Error 990. ATTENZIONE: l'errore 990 è generato dal freeze del filesystem, non dalla corruzione !!

Ora, se avele letto attentamente e compreso tutto ciò che ho esposto fino ad ora, la domanda vi dovrebbe sorgere spontanea, ovvero: "come faccio a dire a XFS di ignorare il freeze e correggere gli inode corrotti?"

risposta: man xfs_db

ma siccome tale man è scritto per chi conosce il filesystem nei minimi dettagli, mi rendo conto per tanto che non è di facile comprensione per i comuni mortali, ecco per cui il motivo di questo thread. Ve lo spiegherò passo passo e con parole semplici:

1- c'è solo una cosa da fare, azzerare lo stato dell' inode corrotto, in modo tale che venga riconosciuto da xfs_repair adeguatamente e quindi riparato. per fare questo si usa il comando xfs_db nel seguente modo:
ovviamente dovete sostituire il valore '68934869' con quello riportato da xfs_repair a fine scansione, e procedere nello stesso modo per tutti gli inode corrotti segnalati da xfs_repair con l'errore 990. Quando avrete finito, xfs_repair eseguirà tutto quello che c'è da fare per le riparazioni, e il vostro filesystem tornerà a funzionare come prima, senza perdita alcuna di dati o integrità strutturale, salvo eccezioni(*1). Se xfs_repair durante la ri-generazione dell'inode (con il comando sopra citato si provvede alla sua azzerazione a livello di attributi) trova delle incongruenze, i dati incongruenti in esso contenuti vengono spostati in lost-found (leggere attentamente nota 1) e questo è sintomo di cattivo hardware, soprattutto la RAM(*2).

Spero che questo thread posso essere di aiuto a qualcuno.

(*1) se la corruzione in memoria dei dati è stata provocata da un problema hardware e non software, ci sono altissime probabilità che in seguito alla riparazione delle corruzioni degli inode ci sia anche perdita parziale o totale dei dati in esso presenti (ATTENZIONE: non è colpa di XFS se l'hardware si è guastato, ne può preservare i dati in caso avvengano, nessuno fa i miracoli!!)

(*2) la qualità della RAM incide parecchio sulle corruzioni dei dati in memoria, e queste avvengono molto più facilmente con moduli di bassa qualità. L'uso di XFS in produzione è sempre da abbinare all'uso di moduli di memoria ECC onde ridurre praticamente a zero la possibilità di errori hardware legati alla RAM.

Senza parole

Bellissimo, grazie equilibrium del post

grazie !equilibrium, dritto nei segnalibri, non si sa mai.

a causa di un errore di I/O tipo ho avuto la necessità di lanciare xfs_repair e m'è spuntato l'errore 990.
il problema è che riportando, come suggerisci, nextents e size a 0, l'errore mi si ripresenta sempre sullo stesso blocco: suggerimenti?

PS: il fs è stato formattato con: -d unwritten=0 -l size=32m -b size=512

Peach wrote:il problema è che riportando, come suggerisci, nextents e size a 0, l'errore mi si ripresenta sempre sullo stesso blocco:

ciao,
scusa la lunga attesa per la risposta, ma "tempus fugit".
rispondo velocemente, per caso stai usando il liveCD 2006.* per fare il repair/check?
se sì, allora è normale, nel senso che sul liveCD c'è ancora la versione di sys-fs/xfsprogs-2.6* bacata.
dovresti usare la versione stabile in portage: sys-fs/xfsprogs-2.8.11

!equilibrium wrote:dovresti usare la versione stabile in portage: sys-fs/xfsprogs-2.8.11

beh ho risolto ripartendo dall'ultimo stage4 che avevo fatto.
buono a sapersi del bug
ci può essere la possibilità di compromissione del fs usando quella versione??

tocca aspettare la 2007.*

Peach wrote:ci può essere la possibilità di compromissione del fs usando quella versione??

no assolutamente, a meno che non usi il kernel 2.6.17*
il tool xfsprogs 2.6* semplicemente ti riporta il fix del problema, ma in realtà non l'ha fatto (dal kernel 2.6.18+ c' èstato un cambio di ABI nei driver e nella struttura del fs e vecchi tools non sono in grando di interagire correttamente con il nuovo formato), ma non altera o peggiora in nessun modo il filesystem. stai tranquillo