Erreur de disque dur: données de détection mauvaises / manquantes
J'ai récemment essayé de vérifier le temps d'arrêt de mon disque dur avec la commande suivante:
Sudo hdparm -I /dev/sdb | grep level
et j'ai eu l'erreur:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Le lecteur lit et écrit les données correctement et monte également au démarrage. Je ne peux tout simplement pas exécuter cette commande sur ce lecteur sans erreurs
Qu'est-ce que cela signifie et comment puis-je résoudre le problème?
semble que votre contrôleur de lecteur ne supporte pas cette méthode d’enquête, tous les chipsets usb sata ne sont pas créés égaux. Vous ne dites pas quel modèle de variateur ou de contrôleur vous utilisez, il est donc difficile de donner davantage de conseils ici.
Vous pouvez le tester en le connectant à un autre contrôleur USB ou en utilisant un lecteur différent avec le même contrôleur ou, mieux encore, directement via SATA.
Les disques de 3 To peuvent être trop volumineux pour certains contrôleurs de l'ère usb2. Je vous conseillerais donc de vous procurer un pont USB3 sata réputé, ce sera beaucoup plus rapide.
Ce problème est généralement dû à la mise en œuvre du pont USB-SATA et doit être visible uniquement avec les boîtiers de disques connectés par USB.
En cas de disque USB externe, le système doit communiquer avec le disque SATA à l'intérieur du boîtier en utilisant le protocole UAS (USB Attached SCSI) sur SAT (traduction SCSI/ATA) pour envoyer des commandes ATA via SCSI sur USB. La raison pour laquelle cela est si complexe est due à des raisons historiques.
Quelque part dans la chaîne USB → UAS → SCSI → SAT → SATA, une partie du matériel a une implémentation incorrecte. Habituellement, tout cela est effectué à l'aide d'une seule puce à l'intérieur du boîtier, appelée pont USB-SATA, et certaines variantes bien connues sont ASM1051, ASM1053 et ASM1153. Parmi ceux-ci, l'ASM1051 est connu pour être bogué et les UAS doivent être évités avec tout matériel contenant cette puce. ASM1053 et ASM1153 peuvent ou non fonctionner en fonction du micrologiciel réel dans la puce (le fabricant est autorisé à personnaliser le micrologiciel, l'implémentation de référence fonctionne correctement). Par exemple, de nombreux boîtiers fabriqués par Seagate utilisent ASM1153 avec un micrologiciel personnalisé et rencontrent des problèmes avec certaines commandes ATA, même si la même puce fonctionne correctement avec un micrologiciel de référence. (Par exemple, certains boîtiers de Seagate fonctionnent tant que le système d’exploitation n’envoie jamais de commandes 12 ou 16 bits. Linux usb_storage prend en charge l’ancien tà cette fin.) En général, l’utilisateur final ne peut pas remplacer le micrologiciel; la seule option est de se plaindre au fabricant. Dans le cas de Seagate, ils "corrigent" le problème en indiquant qu'ils ne prennent officiellement en charge que Windows et OS X. De nos jours, Seagate travaille officiellement avec la communauté Linux. Par conséquent, leurs produits fonctionneront probablement dans le futur.
Le seul moyen de déterminer la puce du pont consiste à démonter le boîtier et à inspecter les marques figurant sur les micropuces.
Mise à jour: Les boîtiers "Seagate Backup Plus Hub" fonctionnent correctement avec un pont USB-SATA et le système UAS fonctionne correctement (notez qu'il s'agit d'un produit différent de "Seagate Backup Plus"!). Dans les boîtiers, le noyau Linux applique l'excentrique tpar défaut, ce qui empêche ce boîtier d'utiliser toutes les fonctionnalités SATA. Vous pouvez activer la prise en charge SATA intégrale, notamment S.M.A.R.T. Avec la commande suivante:
echo "0bc2:ab38:" > /sys/module/usb_storage/parameters/quirks
Notez les deux-points de fin et rien après cela - cela désactive toutes les bizarreries intégrées pour le fournisseur sélectionné: produit. Vérifiez vos identifiants de fournisseur et de produit avec lsusbsi nécessaire.
Informations supplémentaires pour les systèmes/dispositifs pour lesquels les réglages ci-dessus et/ou modprobe n'ont aucun effet (par exemple, Raspberry Pi 3):
Les quirks doivent être ajoutés aux paramètres de démarrage. Pour RPi 3/Raspbian, les paramètres d’amorçage sont dans le fichier /boot/cmdline.txt.
[other command line parameters...] usb_storage.quirks=YOUR_VENDOR_ID:YOUR_DEVICE_ID:QUIRK_FLAGS
Dans mon cas, je devais effacer l'indicateur des quirks de mon appareil. J'ai donc ajouté ceci à /boot/cmdline.txt:
usb_storage.quirks=0bc2:a0a4:
Cela a résolu mon problème, j'espère que cela aidera quelqu'un d'autre