Depuis quelques temps j'ai un bug sur l'un de mes disque dur et cela m'énerve fortement. Celui ci contient essentiellement des données multimédia dans une partition formaté un reiserfs et lorsque j'accède à certain fichier (toujours les même) l' application utilisé pour accéder a ces fichiers se fige et dmesg me sort :
ata2: translated ATA stat/err 0x51/40 to SCSI SK/ASC/ASCQ 0x3/11/04
[4305305.053000] ata2: status=0x51 { DriveReady SeekComplete Error }
[4305305.053000] ata2: error=0x40 { UncorrectableError }
[4305315.239000] ata2: translated ATA stat/err 0x51/40 to SCSI SK/ASC/ASCQ 0x3/11/04
[4305315.239000] ata2: status=0x51 { DriveReady SeekComplete Error }
[4305315.239000] ata2: error=0x40 { UncorrectableError }
[4305325.401000] ata2: translated ATA stat/err 0x51/40 to SCSI SK/ASC/ASCQ 0x3/11/04
[4305325.401000] ata2: status=0x51 { DriveReady SeekComplete Error }
[4305325.401000] ata2: error=0x40 { UncorrectableError }
[4305335.563000] ata2: translated ATA stat/err 0x51/40 to SCSI SK/ASC/ASCQ 0x3/11/04
[4305335.563000] ata2: status=0x51 { DriveReady SeekComplete Error }
[4305335.563000] ata2: error=0x40 { UncorrectableError }
[4305345.716000] ata2: translated ATA stat/err 0x51/40 to SCSI SK/ASC/ASCQ 0x3/11/04
[4305345.716000] ata2: status=0x51 { DriveReady SeekComplete Error }
[4305345.716000] ata2: error=0x40 { UncorrectableError }
[4305345.716000] sd 1:0:0:0: SCSI error: return code = 0x8000002
[4305345.716000] sdb: Current: sense key: Medium Error
[4305345.716000] Additional sense: Unrecovered read error - auto reallocate failed
[4305345.716000] end_request: I/O error, dev sdb, sector 395567017
en nombreux exemplaires. J'ai fait quelques recherches et j'ai trouvé de nombreuses personnes ayant plus ou moins le même problème nottamment ce mail http://lkml.org/lkml/2006/1/19/196
Apparemment tout les gens atteint par se problème ont un disque SATA (c'est mon cas) et un noyau récent (c'est aussi mon cas, ubuntu Dapper) mais la cause n'est pas identifié et les conséquences ne sont pas les mêmes. Chez certain c'est tout l'ordi qui est figé(ça m'est arrivé deux fois), chez d'autre c'est uniquement les applications qui accéder a cette partition ou a ce disque dur (c'est mon cas le plus souvent) et chez d'autre il ne constatait aucun problème a par ces lignes dans leurs logs.
Mais personne n'a la solution à ce problème, je me demande alors si ça disparaîtrait si je recompilais mon noyau moi même mais j'aimerais en être sur car c'est quand même long la compilation d'un noyau. J'ai aussi remarqué que dans les messages d'erreurs il donnait des numéros de secteurs (sector) et même dès fois des numéros de "logical block" et je me demandais si c'était une erreur matériel (disque dur récent) comment je pouvais interdire l'usage des ces secteurs ?
# pb sata
Posté par Éric (site web personnel) . Évalué à 3.
Perso recompiler un kernel officiel n'y a rien fait et je n'ai vu aucun message comme quoi ça aurait changé quelque chose chez quelqu'un.
J'ai pu croiser deux solutions toutes deux testées avec succès :
- t'assurer que tu ne demandes pas beaucoup de débit à tes disques et surtout pas à deux disques sata simultanément (perso c'était des disques de sauvegardes donc j'ai pu éviter les problèmes en mettant un bwlimit à mon rsync). La solution fonctionne mais bon, ça limite énormément l'utilisation du disque tout de même, du coup je suis passé à la solution suivante.
- utiliser un des driver bien foutu. C'est le cas du 3ware (le constructeur fait son propre driver sous licence libre et il est intégré au kernel). Tu peux trouver des controleurs SATA 3ware avec raid hardware (contrairement à la plupart des controleurs qui font du software) à 150 euro. Je n'ai eu aucun problème depuis que je suis passé sous 3ware.
Désolé, pas d'autres solutions à priori en attendant que les développeurs de la libsata trouvent le problème
# autre solution
Posté par Anonyme . Évalué à 2.
[^] # Re: autre solution
Posté par GCN (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.