Newsgroup: it.comp.os.linux.sys
Titolo: EXT3-FS ERROR

Salve a tutti,
oggi il dmesg su uno dei server mi ha restituito una cinquantina
di questi mex:
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071680
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071681
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071682
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071683
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071684
EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for
block 19071685
Ho provato a capire in tutti i modi possibili (google) a cosa fossero
dovuti ma nisba non ne sono venuto a capo el'unica spiegazione
potrebbe essere il cavo scsi guasto ( ma non mi ritroverei solo con
questi errori ma ben altri se non ricordo male).
Ho fatto un bel fsck su tutte le partizioni nessun errore riscontrato,
insomma non ne riesco a venire fuori il server continua a funzionare
senza problemi, apparentemente, ma il numero di errori continua
ad aumentare.
S.O. CentOS
Kernel  2.4.21-15.0.4.EL
hw proliant ml 370 G2 2GBram
/dev/sda  seagate cheetah 18GB SCSI sul quale è installato il S.O.
/dev/sdb controller 3ware 7000-6 con 2 dischi  SAMSUNG da 160GB Raid1
Grazie a chiunque può illuminare la mia buia strada
maurizio

 /dev/sdb controller 3ware 7000-6 con 2 dischi  SAMSUNG da 160GB Raid1
brw-rw----    1 root     disk       8,  17 Mar 14  2002 /dev/sdb1
sdb1 come partizione ha qualche inconsistenza.
leggi qui.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/0277.html
Per la causa c'č da indagare abbastanza... 
In bocca al lupo.
Max

 In bocca al lupo.
Speriamo crepi
Ciao e grazie di nuovo
maurizio

 
Guarda, la sparo li...
1) o il raid non č sincronizzato bene
2) piů probabilmente uno dei dischi č "andato a donne facili"
Se il server non č in produzione, potresti provare ad estrarre un disco e
lavorare solo con uno. Se i problemi si ripresentano, riallinea i dischi e
estrai l'altro.
Se i problemi si ripresentano, NON sono i dischi quindi č presumibile che
sia qualcos'altro.
Ovvio che con woody andava. Debian r0x !!!
Ad ogni modo, inconsistenze sul disco sono capitate anche a me e avevo una
volta il processore che dava i numeri. Potrebbe altresě essere la ram che
ha qualcosa di rotto.
Dubitando che tu abbia un processore "spare", puoi effettuare gli stessi
tests sulla memoria, levando tutte le dimm e lasciandone una sola a
rotazione, cercando di ritrovare il problema.
Per me questo tentativo vale la pena farlo.
Ulteriore caso estremo. Un mio cliente ha aggiunto 1Gb di memoria ad un
server in produzione. di punto in bianco ci sono stati problemi di segfault
e di disco. Il problema era il tipo di memoria che aveva aggiunto (dual
channel invece che single channel) e quindi si scatenavano una serie di
errori e per scoprirlo sono dovuto andare a spulciarmi il manuale della
motherboard.
Della serie: puň essere tutto ed il contrario di tutto in questi casi...
bisogna indagare a tutto tondo, possibilmente utilizzando l'ultimo kernel
disponibile.
MAx

 disponibile.
Francamente ancora non me la sento di mettere un 2.6 in produzione
sarò antiquato ma per un po' mi tengo il caro 2.4 ( poi lo stesso di woody
del resto)
Ciao e grazie dei suggerimenti
maurizio

 del resto)
Su questo te lo appoggio completamente.
Io il 2.6 non lo ho ancora messo in produzione e se gli sviluppatori
continueranno a cambiare le carte in tavola, non lo farò per un bel pò.
(a titolo informativo, fate dei test intensivi con mysql o postgres tra il
2.4 e il 2.6...)
Max

 Max
Ho trovato in giro dei bench fra una pre del 2.6 ed una 2.4 ed il 
confronto è impari.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

confronto è impari.
A favore di chi dei due? 2.4 o 2.6?
A prop per il prb segnalato ho ricompilato i driver del controller
e tutto è tornato miracolosamente a funzionare.
Boh? Va a sapere che cosa gli aveva preso ... credo che non
lo scoprirò mai.
Ciao
maurizio

 A favore di chi dei due? 2.4 o 2.6?
Del 2.6:
http://bulk.fefe.de/scalability/



	[PATCH] Concurrent O_SYNC write support
 
	In databases it is common to have multiple threads or processes performing
	O_SYNC writes against different parts of the same file.
 
	Our performance at this is poor, because each writer blocks access to the
	file by waiting on I/O completion while holding i_sem: everything is
	serialised.
 
	The patch improves things by moving the writing and waiting outside i_sem.
	So other threads can get in and submit their I/O and permit the disk
	scheduler to optimise the IO patterns better.
 
	Also, the O_SYNC writer only writes and waits on the pages which he wrote,
	rather than writing and waiting on all dirty pages in the file.
 
	The reason we haven't been able to do this before is that the required
walk
	of the address_space page lists is easily livelockable without the i_sem
	serialisation.  But in this patch we perform the waiting via a radix-tree
	walk of the affected pages.  This cannot be livelocked.
 
	The sync of the inode's metadata is still performed inside i_sem.  This is
	because it is list-based and is hence still livelockable.  However it is
	usually the case that databases are overwriting existing file blocks and
	there will be no dirty buffers attached to the address_space anyway.
etc....
In conclusione...
se sfogli l'archivio della ml linux-kernel troverai qualcosa in merito.
In particolare, come prestazioni pure il 2.6 è migliore (leggo un file da
100Mb, scrivo un file da 100Mb, rispetto al 2.4 va meglio). Ma se fai tanto
IO assieme, suxa di brutto.
Max

 	In databases it is common to have multiple threads or processes performing
Dimenticavo.
Questa patch ha peggiorato la situazione e non ha risulto nulla.
Sono molto interessato alle prestazioni con i DB e assolutamente con IO
alti il 2.6 è tuttora da sconsigliare rispetto ad un 2.4 (patchato con le
-lck che sono fondamentali)
Max

 
[snip]
Ok, mi toccherà leggermi anche la ml del kernel :-(
Il bvencho comunque era sulla parte network.
