XFS e il fantomatico Error 990

Message

!equilibrium · Post by **!equilibrium** » Sun May 21, 2006 7:35 pm

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:

Code: Select all

May 21 16:14:39 [kernel]  [<c01be0f8>] xfs_iget_core+0x17f/0x408
May 21 16:14:39 [kernel]  [<c01be3e5>] xfs_iget+0x64/0xe1
May 21 16:14:39 [kernel]  [<c01d3239>] xfs_dir_lookup_int+0x53/0xaa
May 21 16:14:39 [kernel]  [<c01d7b3c>] xfs_lookup+0x48/0x71
May 21 16:14:39 [kernel]  [<c01e1134>] linvfs_lookup+0x2b/0x60
May 21 16:14:39 [kernel]  [<c014cdc7>] real_lookup+0x53/0xad
May 21 16:14:39 [kernel]  [<c014cfe4>] do_lookup+0x49/0x78
May 21 16:14:39 [kernel]  [<c014d5dc>] __link_path_walk+0x5c9/0x93b
May 21 16:14:39 [kernel]  [<c014d98f>] link_path_walk+0x41/0xaa
May 21 16:14:39 [kernel]  [<c0136cbe>] do_anonymous_page+0xa8/0x109
May 21 16:14:39 [kernel]  [<c0136fe4>] __handle_mm_fault+0xa6/0x167
May 21 16:14:39 [kernel]  [<c01f5a2c>] strncpy_from_user+0x2d/0x4c
May 21 16:14:39 [kernel]  [<c014dce2>] do_path_lookup+0x182/0x19d
May 21 16:14:39 [kernel]  [<c014df12>] __user_walk_fd+0x29/0x3f
May 21 16:14:39 [kernel]  [<c0149b7e>] vfs_lstat_fd+0x12/0x39
May 21 16:14:39 [kernel]  [<c0136cbe>] do_anonymous_page+0xa8/0x109
May 21 16:14:39 [kernel]  [<c0136fe4>] __handle_mm_fault+0xa6/0x167
May 21 16:14:39 [kernel]  [<c014a103>] sys_lstat64+0xf/0x23
May 21 16:14:39 [kernel]  [<c0111df3>] do_page_fault+0x17b/0x4cb
May 21 16:14:39 [kernel]  [<c0111c78>] do_page_fault+0x0/0x4cb
May 21 16:14:39 [kernel]  [<c01028cb>] sysenter_past_esp+0x54/0x75
May 21 16:15:14 [kernel] Filesystem "hdc2": corrupt dinode 68934869, extent total = 1, nblocks = 0.  Unmount and run xfs_repair.
May 21 16:15:14 [kernel] 0x0: 49 4e 81 a4 01 02 00 01 00 00 00 00 00 00 00 00
May 21 16:15:14 [kernel] Filesystem "hdc2": XFS internal error xfs_iformat(1) at line 415 of file fs/xfs/xfs_inode.c.  Caller 0xc01bfe12
May 21 16:15:14 [kernel]  [<c01bf02c>] xfs_iformat+0x1be/0x48e
May 21 16:15:14 [kernel]  [<c01bfe12>] xfs_iread+0xbd/0x19d

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:

Code: Select all

Filesystem "hdc2": corrupt dinode 68934869, extent total = 1, nblocks = 0.  Unmount and run xfs_repair
fatal error -- couldn't map inode 68934869, err = 990

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:

Code: Select all

xfs_db -x -c 'inode 68934869' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX

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.

.:deadhead:. · Post by **.:deadhead:.** » Mon May 22, 2006 9:14 am

Senza parole

Bellissimo, grazie equilibrium del post

Luca89 · Post by **Luca89** » Mon May 22, 2006 9:36 pm

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

Peach · Post by **Peach** » Tue Mar 06, 2007 10:40 am

a causa di un errore di I/O tipo

Code: Select all

[<c0102c22>] sysenter_past_esp+0x5f/0x85

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:

Code: Select all

corrupt inode 33805919, extent total=30, nblocks=1.
fatal error -- couldn't map inode 33805919, err=990

suggerimenti?

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

!equilibrium · Post by **!equilibrium** » Sat Mar 10, 2007 7:32 pm

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

Peach · Post by **Peach** » Sun Mar 11, 2007 12:44 am

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

!equilibrium · Post by **!equilibrium** » Mon Mar 12, 2007 9:06 am

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