bug libata dangereux dans le kernel ( fixed 2.6.12 )

Recherche :

Sujet auquel vous répondez

Sujet : bug libata dangereux dans le kernel ( fixed 2.6.12 )

jinkazama a écrit :

Apres pas mal de test de compatibilite en Sata, je peut vous CERTIFIER qu'il ne faut SURTOUT PAS utiliser les drivers libata sous kernel 2.4 ou 2.6 : il y a TOUJOURS un moment ou une corruption de donnees arrive...

Je vous conseille de tourner ce petit Script (Quick & Dirty) pour deceler le probleme :

Code :

#!/bin/sh
dd if=/dev/urandom of=/tmp/dummy01 bs=1M count=5120
md5sum /tmp/dummy01 > /tmp/dummy.md5
cd /tmp
while [ 1 = 1 ]
do
cp -Rf /tmp/dummy01 /tmp/dummy02
rm -Rf /tmp/dummy01
cp -Rf /tmp/dummy02 /tmp/dummy01
md5sum -cv /tmp/dummy.md5
echo "Mega Smurph" >> /tmp/mdc
rm -Rf /tmp/dummy02
echo "Tested over: `cat /tmp/mdc | wc -l`0 GB"
done

Au debut on a "Dummy01 OK" et au bout d'un moment on arrive toujours a FAILED
(ca varie entre ~100GB et 1.7TB avec moi...)

Donc plus de libata en sata : dangereux pour vos donnees (pas teste en IDE). If you wanna go cheap, get the MARVELL card that has proprietary drivers for linux...

effectivements ça fini par planter, je me demande si ça ne serai pas un autre problème qui entrainerai la corruption avec ce script... il faudrai un script sur et certain qu'il fonctionne! :heink:

savez vous si ce problème apparait avec les chipsets nforce3? actuellement j'utilise un chip Sil3112A.

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

XK	super [:zjk]

jinkazama

J'ai installe le 2.6.12 et teste sur 18To et ... Plus de corruption :love:

Les erreurs :

Code :

ataX: status=0x51 { DriveReady SeekComplete Error }
ataX: error=0x84 { DriveStatusError BadCRC }

Sont encore presentes, mais les donnees ne sont plus corrompues - apparement libata ne prennai pas en compte les erreurs CRC... Chose corrige avec le dernier noyau.

Hop, mon serveur home de 1To AMD64 est reparti :pt1cable:

quelqu'un a testé avec le kernel 2.6.12 ? il semble qu'ils aient touché à libata mais je ne sais pas si ça concerne ce problème :??:

édit : j'ai testé plusieurs fois et c'est plutôt concluant :love:
en effet, avec les anciens noyaux au bout de quelques secondes j'avais des erreurs, maintenant je n'ai plus d'erreurs par contre ma partition tmp est assez vite pleine :

Citation :

dd: écriture de `/tmp/dummy01': Aucun espace disponible sur le périphérique
351+0 enregistrements lus.
350+0 enregistrements écrits.
367443968 bytes transferred in 145,776990 seconds (2520590 bytes/sec)

jinkazama

mcfly587 a écrit :

Code :

u'il ne faut SURTOUT PAS utiliser les drivers libata sous kernel 2.4 ou 2.6 :

ok mais alors quels drivers faut-il utiliser ?

Les drivers proprio du constructeur s'ils existent :) :P

jinkazama

dofor a écrit :

J'avoue que j'ai pas trop compris le script

Quand il te dit Tested over: XXX Gb c'est que c'est corrompu?

Si c'est le cas, ça me l'a fait aussi sur un disque qui n'utilise pas libata (ide tout bête)

Le disque est en reiserfs, je ne sais pas si ça joue

C'est corrompue des que tu as "FAILED" a la place de "OK"

mcfly587

Code :

u'il ne faut SURTOUT PAS utiliser les drivers libata sous kernel 2.4 ou 2.6 :

ok mais alors quels drivers faut-il utiliser ?

dofor

jinkazama

mcfly587 a écrit :

Salut :)

Je possède 4 disques Sata sur des controleurs sil 3112.

Je tournais avec les drivers libata je pense :

Code :

- Support for SATA (deprecated; conflicts with libata SATA driver
- <*> Silicon Image chipset support

et j'ai récement changé toute ma config en passant en raid 0 donc j'ai décoché les libata et je suis passé du coté scsi :

Code :

<*> SCSI disk support
Scsi-Low-level-driver->
<*> Silicon Image SATA support

Donc je pense que la je n'utilise plus les drivers libata ( dites moi si je me trompe :) :pt1cable: )
Disque reconnu comme sda et non plus comme hda.

Et résultats je n'ai plus d'erreurs au boot, j'avais parfois au boot une correction d'erreur mais je n'ai jamais preté trop attention ... et depuis ces changements je n'ai plus ce message.

Voila je ne sais pas si il y a un rapport et/ou si c'est bien de çà que vous voulez parler ;)

En tout cas j'ai 4 disques qui tournent sans problème sur du sil3112 sous linux ( Os principal je n'ai plus windows donc j'en ai un usage intensif )

En fait, tu utilises toujours libata. Si tu veut verifier si tout marche bien utilise le script que j'ai mis au dessus... (teste sur au moins 2To)

mcfly587

Salut :)

Je possède 4 disques Sata sur des controleurs sil 3112.

Je tournais avec les drivers libata je pense :

Code :

- Support for SATA (deprecated; conflicts with libata SATA driver
- <*> Silicon Image chipset support

et j'ai récement changé toute ma config en passant en raid 0 donc j'ai décoché les libata et je suis passé du coté scsi :

Code :

<*> SCSI disk support
Scsi-Low-level-driver->
<*> Silicon Image SATA support

jinkazama

Le RAID Soft marche tres bien avec les drivers proprio...
C'est plus un bug libata qui se reproduit aussi quand tu copie d'un disque dur a l'autre...

Si quelqu'un a une config similaire a la mienne et pas de problemes, j'aimerai qu'il poste ici :)
-------------------------
AMD Athlon 64 S939 3000+ / 2Go (4x512) sur Asus nForce 4 Deluxe (8 Sata/2 PCI Express 16x) / Debian Stable (Sarge) avec noyau 2.4.29 ou 2.6.8 ou 2.6.11.? (Sata : nv_sata + siimage)

Pour le moment ca marche sur un Dual Athlon avec 1 carte PCI-X 8 Sata Marvell... (ca ne marche plus si je met du 3114 ou Promise ou autre... libata)

blackm

ok, je pensais faire du raid soft un de ces jours mais avec ce que tu dis, ca va attendre...

jinkazama

Apres avoir effectue enormement de tests, j'ai des erreurs surtout quand je copie sur plusieurs disques en // (genre RAID soft).

Je n'ai plus d'erreurs avec le dernier noyau sur 1 seul disque mais si j'ai des erreurs avec du RAID1 ou RAID5 soft et que basculer de libata vers driver proprio regle le probleme, il y a bien un toujours un probleme avec libata...

blackm

J'ai refais des tests, je n'ai pas eu de pb avec mon 2.6.7 alors j'ai poussé le vice jusqu'à mettre un noyau récent et en "déblacklistant" mon seagate :o

J'ai mis à jour mon bios (tyan tiger K8W) vu qu'il y avait une nouvelle version de rom pour le contrôleur sil 3114, par contre je ne sais pas quelles corrections ont été apportées par rapport à ma version précédente :/

Et ben toujours aucune corruption de données...j'ai dû faire 4 tests depuis mardi dernier et déplacer ~5 To de données.

blackm@blastos ~ $ uname -a
Linux blastos 2.6.12-rc6-git1 #3 SMP Thu Jun 9 02:32:36 CEST 2005 x86_64 AMD Opteron(tm) Processor 242 AuthenticAMD GNU/Linux

XK	c'est inquiétant ce problème, de plus personne dans l'équipe Linux ne semble s'en inquiéter... ce bug a t'il déjà été signalé :??:

jinkazama

J'ai teste les 2.6 depuis le 2.6.2 au 2.6.11
Ainsi que les derniers 2.4

Le bug est toujours la... (il faut parfois attendre 1.X TB)

blackm

T'as commencé à tester les 2.6 depuis quelle version ?

Pour l'instant pas de pb sur un sil 3114/noyau 2.6.7, j'ai testé avec ton script jusqu'à 600Go sur un seul disque, et 1.2To en transférant d'un disque à l'autre.

Avec les versions de noyaux suivantes mon seagate s'est fait blacklisté :o

jinkazama

XK a écrit :

Hello : j'ai cree ce script apres avoir eut des corruptions de donnees en copiant des archives de plusieurs Go.

Ce script me detecte des erreurs sur tout les chip SATA utilisant libata que j'ai essaye (SI3112, SI3114, NV_SATA (nForce3&4), Promise TX4, SataII TX4 etc.)

Lorsque je fait tourner ce script sur une 3Ware, Marvell/Highpoint ou Promise avec drivers proprio, je n'ai pas d'erreurs...

Bien que le script soit tres moche, il est vraiment tres simple : il ne fait que copier en boucle un fichier et verifier sa signature...

jinkazama a écrit :

Code :

#!/bin/sh
dd if=/dev/urandom of=/tmp/dummy01 bs=1M count=5120
md5sum /tmp/dummy01 > /tmp/dummy.md5
cd /tmp
while [ 1 = 1 ]
do
cp -Rf /tmp/dummy01 /tmp/dummy02
rm -Rf /tmp/dummy01
cp -Rf /tmp/dummy02 /tmp/dummy01
md5sum -cv /tmp/dummy.md5
echo "Mega Smurph" >> /tmp/mdc
rm -Rf /tmp/dummy02
echo "Tested over: `cat /tmp/mdc | wc -l`0 GB"
done

alien conspiracy

http://lkml.org/faq/lkmlfaq-3.html#s3-1

jinkazama

Je ne sait pas comment reporter un bug (j'ai essaye de m'inscrire sur la LKML mais j'ai abandonne au bout de 1/2 heure...) :pt1cable: :o

alien conspiracy

Tu as reporter le bug ?

jinkazama

Code :

#!/bin/sh
dd if=/dev/urandom of=/tmp/dummy01 bs=1M count=5120
md5sum /tmp/dummy01 > /tmp/dummy.md5
cd /tmp
while [ 1 = 1 ]
do
cp -Rf /tmp/dummy01 /tmp/dummy02
rm -Rf /tmp/dummy01
cp -Rf /tmp/dummy02 /tmp/dummy01
md5sum -cv /tmp/dummy.md5
echo "Mega Smurph" >> /tmp/mdc
rm -Rf /tmp/dummy02
echo "Tested over: `cat /tmp/mdc | wc -l`0 GB"
done

XK	je ne pense pas que mes disques sont entrain de mourrir, ils ont toujours très bien fonctionné et au scandisk je n'ai aucun secteur défectueux :o je fais du raid 1 sotf avec 2 disques identiques. à mon avis c'est un problème de linux, le driver SATA doit être défectueux :(

jinkazama

J'ai regle mon probleme...

J'ai pris des cartes Sata avec drivers proprio... (Sata PCI-X 8 ports Maxell)

alien conspiracy

Quand il commence à revenir régulierement inquiète toi. :D

m4fiozo

mon diske va tres bien il a toujours tres bien fonctionner ... kan je dit ke jlai souvent je ne l'ai pas toutes les 30 secondes ... mais desfois jle voit passer par hasard comme sa

alien conspiracy

Si tu ne fais pas du raid soft alors c'est le disque qui perds des secteurs fait des sauvegarde régulière parcque tu risques de perdre pas mal de données. ;)

m4fiozo

Ouai je suis sur un nf 4 et je ce message malheureusement trop souvent a mon gout jme suit tjr dit ke ct pas normale au debut jme suit carrement dit que ct peut etre le diske ki avait des partit de secteur linguer ...

alien conspiracy

XK a écrit :

ça en est ou la résolution de ce problème? :??:

j'ai le message qui est apparu plusieurs fois depuis, c'est inquiétant :(

une petite recherche sur google permet de se rendre compte que ce bug est assez répandu et ne touche pas uniquement libata puisque les disques IDE sont aussi touchés. :heink:

Un disque qui meurt (bad sector) sort les mêmes erreurs.

ataX: status=0x51 { DriveReady SeekComplete Error }
ataX: error=0x84 { DriveStatusError BadCRC }

XK	ça en est ou la résolution de ce problème? :??: j'ai le message qui est apparu plusieurs fois depuis, c'est inquiétant :( une petite recherche sur google permet de se rendre compte que ce bug est assez répandu et ne touche pas uniquement libata puisque les disques IDE sont aussi touchés. :heink:

XK	J'ai 100Go de données qui se sont corompues lentement justement, en fait après de multiples tests il s'agissait de la mémoire vive :( Dans mon cas le message d'erreur n'est apparu, enfin je ne l'ai trouvé dans le syslog qu'une seule fois.

jinkazama

Fait attention, j'ai 200Go de donnees qui ont ete corrompues lentement :( (bon, c'etait en test, donc pas trop grave).

Le mieux c'est de faire un script qui copie en boucle un fichier (cree un premier dummy a partir de /dev/urandom par exemple) et de verifier le md5 a chaque fois que le message apparait...

En testant, les erreurs donnent md5 failed a tous les coup.

Generalement le software raid torture la machine (surtout lorsque l'on a plusieurs cartes sata PCI), peut etre que ces erreurs apparaissent plus facilement...

(enfin, je doit copier entre 300Go et 2To avant qu'une erreur apparaissent...)

Je posterai sur la LKML au boulot lundi :P

Ca ne nous gene pas trop pour les gros serveur (8+ disques), nous utilisons maintenant la highpoint 1820a (PCI64) - assez bon marche et bon debit... (et puis pour faire du raid 5/6 soft dessus, c'est largement suffisant)

XK	perso j'ai eu ce message avec libata il n'y a pas très longtemps, j'avais même posté : http://forum.hardware.fr/forum2.ph [...] 0&subcat=0 je n'ai pas repéré le fichier défectueux en question (s'il existe)...

black_lord

+1, détecter ce genre de bug (et sur ce genre de matos) n'est pas donné à tout le monde. Fais en profiter le reste de la communauté :)

elianor

Fait un bug report dans la LKML :jap:

jinkazama

Cela fait quelque mois qu'en testant le 2.6 j'ai des corruptions de donees en utilisant des cartes sata genre Silicon Image 3112A, Silicon Image 3114, Promise Sata150 TX2, Promise Sata150 TX4, Promise SataII 150 TX4...

J'utilise ces cartes en RAID 5/6 soft sous linux (up to 16 drives)

Je me suis apercu qu'en copiant 500Go a 2TB de donnees, j'ai ca qui apparait en continu (toutes les 1/2 heure environ) :
ataX: status=0x51 { DriveReady SeekComplete Error }
ataX: error=0x84 { DriveStatusError BadCRC }

En regardant de plus pres (copiant des donnees pendant des jours et md5sum), je me suis apercu qu'a chaque fois que j'ai cette erreur les fichiers en cours de copies sont corrompus

Je precise que l'erreur ne vient pas d'un cable ou disque defecteux
Sur une machine avec 16 disques, les 16 disques ont fini par faire au moins une erreur.
J'ai aussi teste sur du hard different (de PIII450/IntelBX/3112 au AMD643000+/nForce4)

La seul controleur sata grand public qui ne me sort pas cette erreur, c'est le sata du nforce4...

Enfin, en repassant sous le kernel 2.4, errors are gone and so is data corruption...

Donc avis a ceux qui veulent se faire un NAS a bas prix : restez sous le 2.4 ou utilisez du 3Ware/LSI Logic (enfin pas un truc libata).