Newsgroup: it.comp.os.linux.sys
Titolo: XFS: Con me sta chiudendo!

Salve a tutti.
Ho un grosso problema con XFS.
Scenario:
Macchina (che girava da anni) con due processori AMD MP 1800+ con 1GB di
Ram, HD SCSI IBM da 18GB su CTRL ADAPTEC 29160N. Il sistema operativo gira
tutto sull'IBM. Il Kernel č il 2.6.18 di gentoo compilato con le
ottimizzazioni per l'AMD MP. In aggiunta c'e' un MAXTOR EIDE da 200GB; i
dischi sono tutti con partizioni XFS. Qualche giorno fa' il server non
risponde piu senza alcuna causa apparente. Riavvio, parte, ma dopo qualche
minuto vedo comparire tanta roba sullo schermo ed un messaggio ricorrente
che trovo anche nei log:
XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1668 of file
fs/xfs/xfs_alloc.c.  Caller 0xc020f0f0 [...]
xfs_force_shutdown(hdc1,0x8) called from line 4261 of file
fs/xfs/xfs_bmap.c.  Return address = 0xc02642c0
Filesystem "hdc1": Corruption of in-memory data detected.  Shutting down
filesystem: hdc1
Please umount the filesystem, and rectify the problem(s)
Quando si verifica il problema il filesystem non e' piu' accessibile e
qualsiasi comando, a partire da ls, restituisce I/O error!
Dopo i vari tentativi dichiarati 'successfull' da xfs_repair il problema
persiste e decido di riformattare in reiserfs, ripristinare dal backup e
cambiare macchina.
Il disco EIDE da 200GB non presentava alcun problema.
Oggi sull'altra macchina stesso problema, ma solo accedendo al disco da
200GB che ovviamente e' rimasto in XFS. Sulla macchina nuova gira un
Kernel 2.6.21.
xfs_repair -n dice che e' tutto OK.
Suggerimenti?
Saluti e scusate per la lunghezza del POST.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Suggerimenti?
Le macchine hanno sempre avuto i kernel 2.6.18 e maggiori,
oppure sono state installate con i 2.6.17?

 Suggerimenti?
Piu` che un problema di XFS mi sembra un problema hardware... Prova a
fare un test della RAM e del disco
Enrico

 fare un test della RAM e del disco
Mi accodo al consiglio di Enrico.
E' quasi sicuramente un problema hardware.
E i dischi Maxtor non sono noti per essere particolarmente affidabili.
ciao
gl

 oppure sono state installate con i 2.6.17?
La prima (biprocessore) e' stata installata con un 2.6.10 per poi essere
aggiornata nel tempo. Durante i vari processi di aggiornamento ha avuto
anche il 2.6.17, per qualche settimana, ma dopo aver sentito dei possibili
problemi con XFS con quel kernel, sono passato al 2.6.18 che girava ormai
da diversi mesi.
La RAM (Kingston se non erro) e' ECC con controllo della parita', con
moduli specifici per quella motherboard che e' una Tyan 2462.
La seconda e' stata installata direttamente con il 2.6.21.
Saluti.


 Enrico
Sembra abbastanza improbabile che si verifichi lo stesso problema su due
macchine diverse e due dischi diversi. L'unica cosa che le due macchine
hanno avuto in comune e' stato il solo HD Maxtor da 200GB.
Ad ogni modo entrami i dischi li ho verificati con badblocks, e la memoria
con memtest. Sulla biprocessore ho anche fatto girare un processore per
volta estraendo fisicamente l'altro, oltre a togliere i moduli di RAM a
turno.
Il problema era riproducibile se tentavo di cancellare dal disco la
directory dei sorgenti dei kernel. Era praticamente impossibile eliminarli.
Saluti.


 E i dischi Maxtor non sono noti per essere particolarmente affidabili.
Il primo problema si e' verificato sul disco SCSI IBM da 18GB (10000rpm)
Il secondo problema si e' verificato su una macchina completamente
diversa, nuova, con dischi diversi, sulla quale ho installato tutto
dall'inizio, ed alla quale ho successivamente collegato il disco Maxtor
EIDE da 200GB.
E' probabile che il File system fosse gia' compromesso e uando sono
iniziate un po' di operazioni 'intensive' sul disco in XFS, il problema si
e' ripresentato nuovamente, ma perche' xfs_repair dice che non ha
riscontrato errori?
Ma la domanda fondamentale e' perche' il file system si e' corrotto su
entrambi i dischi?
Saluti.
Boh....


 directory dei sorgenti dei kernel. Era praticamente impossibile eliminarli.
Se invece facevi una cosa del tipo:
find /usr/src/kernel -type f -print -exec rm {}; sleep 1 \; 
quindi cancellando i file ma con una pausa di 1 secondo, succedeva lo stesso?

 quindi cancellando i file ma con una pausa di 1 secondo, succedeva lo stesso?
Uhm... interessante.... ma non ho provato... ed ora e' un po' tardi visto
che quella partizione l'ho riformattata in reiserfs, ma e' un tentativo da
mettere nel cassetto.
Ricordo comunque con certezza, di aver cancellato con successo diverse
volte i sorgenti dei kernel vecchi per liberare spazio.
Aggiornamento: sul maxtor da 200GB ho eseguiro xfs_check che ha riportato
qualche 'difetto', quindi ho eseguito xfs_repair, e di nuovo xfs_check che
non ha piu' riportato nulla! 
E' vero che quel file system aveva ormai anni alle spalle, ma non capisco
come si sia potuto compromettere senza ragioni valide apparenti (macchina
sotto UPS e shutdown pochi e regolari).


 sotto UPS e shutdown pochi e regolari).
Con XFS è capitato anche a me con un disco da 160 GB senza ragioni
apparenti con kernel 2.6.8.
Controllati i settori danneggiati e riformattato con EXT3 il disco va
tuttora (sgrat, sgrat)...
Tobe

 Il primo problema si e' verificato sul disco SCSI IBM da 18GB (10000rpm)
ah beh, a me ne sono morti due, uno dopo 3 e uno dopo 4 giorni di vita...
comunque io reiserfs non lo metterei: il 3 non è più sviluppato da
namesys, ditta che non è messa bene con quello che è successo a
Reiser... Sì, ok, c'è il mondo opensource, però....



si ok ... ma il 3.6 e' ultra-ultra-stabile.
IMHO, e' il meglio che oggi per Linux.
che informazioni hai sul 4? Lo sviluppo e' continuato da qualcuno? Dalla 
stessa namesys?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 Saluti e scusate per la lunghezza del POST.
quando hai un problema sul filesystem, su questo NG di diranno 
inevitabilmente e sempre che hai un problema hardware :) E' un classico 
ormai.
Il problema hardware puo' anche esistere.... pero' la storia insegna che 
con questi filesystem avventurosi i problemi sono solitamente software.
Io non ho esperienze dirette con XFS (se non dei test tantissimi anni 
addietro).
Tanto tempo fa usavo EXT3 e ho avuto un problema analogo al tuo, se non 
peggiore: reboot normalissimo, e mi sono ritrovato con una marea di 
directory e file scomparsi. Tutti hanno insistito col dire che il 
problema era sul mio disco ... e' inutile dire che dopo tanti anni quel 
disco e' ancora funzionante e che certe discussioni lasciano il tempo che 
trovano.
Nel mio caso ho risolto con Reiser 3.6.19
Da un paio di anni non ho problemi.... addirittura una volta per errore 
di impostazione del logrotate mi sono trovato una directory con piu' di 
300mila file :) Me ne sono accorto solo quando la partizione si e' 
riempita :) .... lo uso in congiunzione con EVMS, anche se non ho nessun 
mirror o niente di particolare.


 stessa namesys?
dalla namesys, ma hanno fondi solo per una manciata di mesi. C'era un
articolo su kerneltrap. Certo è che sembra proprio una brutta storia.
L'hai letto questo?
http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser



si si .... sapevo gia'. Lui e' in galera e ha dovuto vendere la namesys 
per affrontare le spese legali.
Brutta storia... e fra l'altro mi pare che il corpo della donna non sia 
mai stato ritrovato.
A questo punto sarebbe, ahime', sperabile che qualcuno tipo IBM o Oracle 
si compri tutta la baracca. Sun ha appena partorito zfs e non saprebbe 
cosa farsene. Microsoft potrebbe fare come con RAV antivirus: comprarla 
per distruggerla (tutti ci chiediamo ancora che fine ha fatto RAV 
antivirus).


 Dalla stessa namesys?
http://kerneltrap.org/node/8102
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 antivirus).
sì, però viene fuori come con cups ed apple. Il codice è gpl, quindi nel
caso peggiore verrà forcato, non ritirato.

 
http://kerneltrap.org/node/8102
mmh ...
"It was in disarray well before.  Many of the reiser4 features,
like filesystem plugins, make more technical sense in the Linux
VFS, but made more business sense for Namesys as a reiserfs 4
thing.  That lead to a stalemate."
La questione e' la seguente, se il codice e' buono e se l'idea e' buona 
perche', quindi, non includerlo nel VFS di Linux?
