Newsgroup: it.comp.os.linux.sys
Titolo: XFS filesystem BUG?

Ciao a tutti,
mi ritrovo con un problema piuttosto noioso, su svariate piattaforme
dove utilizzo XFS su partizioni >= 200Gb.
Le piattaforme sono quasi tutte cluster Heartbeat (2.1.2 / 2.1.3) a 2
nodi, su macchine Compaq DL380 (G4/G5) e DL360 (G4/G5), in un paio di
casi con storage SAS esterno e in alcuni casi con disco DRBD (0.8)
condiviso (con privata dedicata a 1Gb); gli OS utilizzati sono CentOS
5.x e Red Hat 5.x (come XFS utilizzo la versione fornita con il
sistema operativo).
Il problema è che, quasi sistematicamente, dopo alcuni giorni di
lavoro le macchine vanno in hang, freezandosi inesorabilmente senza
mezza riga di log.
Inizialmente davo la colpa a problemi hw e al DRBD, ma non sono più di
questa idea dato che EXT3 (a parità di configurazione) non mi dà alcun
problema.
Qualcuno sa se ci sono problemi con XFS (mi risultava avesse problemi
sopra svariati TB)?
Ogni idea è ben accetta.
Ciao&Grazie


Allora eccoti la mia idea:
IMHO, la discussione su NG di una cosa del genere non ti aiuterà
tantissimo.
Dovresti riportare tutto su 
http://oss.sgi.com/bugzilla/
Qui non ci sono le competenze ad alto livello per poter discutere
questa cosa.
A me è successa una cosa del genere, ma non per quanto riguarda il
problema della dimensione delle partizioni, poiche' adesso sto usando
XFS su una partizione di 450 GB.
Il problema nel mio caso era causato dall'utilizzo di un driver
generico "sata", che con ext3 non creava problemi, ma con XFS dava
problemi.
Il problema si è risolto non appena è uscito fuori il modulo kernel,
specifico per il mio controller SATA.
Ripeto il mio consiglio: apri la segnalazione su 
http://oss.sgi.com/bugzilla/
... e riporta qui il numero di ticket, perché anche io sono
interessato a capire il problema, in quanto utente di XFS.

 interessato a capire il problema, in quanto utente di XFS.
tanto per la cronaca:
se tu stai usando un driver "ata_generic", o comunque, ti ritrovi nel
seguente problema:
http://oss.sgi.com/bugzilla/show_bug.cgi?id=779
riaprilo, poiché io non ho più avuto modo di continuare i test
(essendo uscito il driver specifico e avendo risolto il problema in
quel modo).

Ciao Massimiliano e grazie per la dritta.
Quello che dici mi ha fatto venire in mente un paio di controlli in
più da fare; mi metto a ravanare un pò con bonnie++ e iostat sperando
di ricavare qualcosa.
Grazie mille

 Ogni idea è ben accetta.
Questa e` la mia situazione a casa:
ebianchi@montgomery:~$ df -hPT|grep vg01-home
/dev/mapper/vg01-home xfs  291G  196G   95G  68% /home
ebianchi@montgomery:~$ lsmod |grep ata
ata_generic            10116  0
ata_piix               22660  2
libata                165472  2 ata_generic,ata_piix
scsi_mod              160760  2 sd_mod,libata
dock                   14112  1 libata
ebianchi@montgomery:~$
Il chipset secondo lspci e` un 82801GB/GR/GH (ICH7 Family) ed il kernel
e` un 2.6.26. Ovviamente, nessun problema. Una situazione simile ce l'ho
a lavoro con un kernel 2.6.18 ma, a differenza del pc di casa, viene
usato un driver specifico (se non ricordo male, sata_sil). La
distribuzione in entrambi i casi e` Debian (etch a lavoro, prima lenny e
poi sid a casa)
Enrico
P.S. si, tutti e due i sistemi sono parecchio stressati (scritture,
letture, crash improvvisi...)

On 12 Gen, 20:51, Enrico 'Henryx' Bianchi

comunque nel tuo caso (con il chipset 82801GB/GR/GH) il driver
"ata_generic" e' perfettamente usabile.
Nel mio caso invece (con il chipset nVidia Corporation MCP67 AHCI
Controller), con il driver "ata_generic", il sistema era completamente
inutilizzabile.
Purtroppo, dopo aver reinstallato il sistema, 5 volte in un solo
giorno, non ho piu' avuto voglia e tempo di fare i test e dopo la
bellezza di 9 mesi il ticket e' stato chiuso.
p.s.: non ho capito una cosa dal tuo messaggio. Prima scrivi
"Ovviamente, nessun problema.". Poi parli di "crash improvvisi".
Intendi dire che si verificano crash per altre ragioni, ma che questi
crash non creano comunque alcun problema al filesystem ??
pp.ss.: qui si puo' procedere in modo un po' empirico. Per fare
debugging di una cosa del genere bisogna analizzare log e contro-log.
ppp.sss.: hai mai provato a installare XFS sulla /boot ?? C'e' un
workaround che fa abbastanza ridere:
dal primo terminale lanciare grub-install /dev/sdaxxx
da un altro terminale lanciare contemporaneamente e in continuazione:
xfs_freeze -u /boot fin quando il comando dell'altro terminale non ha
finito
:-)
Io ho preferito fare uno script expect che lancia "grub", poi lancia
"root (hd0,5)", poi lancia "setup (hd0)", e poi lancia "quit" :)

 ppp.sss.: hai mai provato a installare XFS sulla /boot ??
No, sinceramente non me ne e` mai importato molto
Enrico


aggiungo una cosa degna di nota: in questo momento con un chipset
identico al tuo (82801GB/GR/GH) il driver ata_generic con XFS non mi
sta creando alcun problema.

 solito (sgrat sgrat) non compromenttono i dati sul file system
fino a oggi (sgrat sgrat pure io) mai perso un byte. Posso connettere
e disconnettere il cavo di alimentazione quante volte voglio. Forse
rompo prima i dischi, ma dati non se ne perdono in alcun caso.
Per la cronaca: sta uscendo l'ennesimo filesystem per linux. Si tratta
del porting su Linux del filesystem di Digital: advfs
Molti dicono che e' roba vecchia del 1990, pero' ha alcune
caratteristiche molto interessanti (nonostante l'eta'):
    * No need to take file systems off-line to expand, shrink or
reconfigure (sarebbe l'unico FS su linux che ti consente di fare
tanto, a parte vxfs).
    * Snapshots for consistent backups while applications are online
(senza VM, su linux era impossibile)
    * Ability to recover deleted files (con i FS journaled su linux e'
impossibile)
eccetera eccetera...
il VM e' un po' strano (i domini sono dei pool di storage..)
... questa cosa del filesystem journaled, che offre la possibilita' di
recuperare dati cancellati mi pare interessante. E non e' finita.
L'impostazione predefinita prevede il solo journaling dei metadati
(come XFS), ma offre anche la possibilita' del journaling dei dati.
Usa pure gli extent (ad oggi in Linux solo XFS e forse JFS usano gli
extent... e in futuro ext4).

 tanto, a parte vxfs).
Eh? Ext3 mi permette di fare queste operazioni online senza problemi
(l'unica operazione che richiede di essere fatta offline e` lo shrink,
ma la cosa e` stata sistemata in ext4). Per quanto riguarda
l'undelete, la cosa e` possibile, ma con molta, molta pazienza.
L'implementazione della funzionalita` di undelete e` stata proposta
per ext4, ma non e` stata portata avanti (e` probabile che verra`
implementata in futuro)
Enrico

 implementata in futuro)
e' già... e pure i pool di storage e tutto il resto verranno
implementati sempre nel futuro?
Nel presente, per intanto, quello che vedo è il PC del mio collega che
questa mattina ha fatto fsck su ext3 perché ha perso un botto di
files.....

 
ed una compilation di "chissene" ce la vogliamo mettere?
stai proponendo la stessa identica solfa in tutti i 3ad..
per cortesia, mettitela come sign che almeno lo sappiamo..
ripeto il concetto: chissenefrega
Stefano


ed una contro-compilation di "chissene del tuo chissene" non ce la
mettiamo anche? ;)