Solución:
Parece que el controlador de su unidad no admite ese método de consulta, no todos los conjuntos de chips sata usb son iguales. No dice qué modelo de unidad o controlador está utilizando, por lo que es difícil ofrecer más consejos aquí.
Puede probar esto conectándolo a otro controlador USB o usando una unidad diferente con el mismo controlador o mejor aún, directamente a través de SATA.
Las unidades de 3 TB pueden ser demasiado grandes para algunos controladores de la era usb2, por lo que recomendaría obtener un puente sata usb3 de buena reputación en su lugar, también será mucho más rápido.
Este problema generalmente es causado por la implementación del puente USB-SATA y debería ser visible solo con carcasas de disco conectadas por USB.
En el caso de un disco USB externo, el sistema necesita comunicarse con la unidad SATA dentro del gabinete utilizando el protocolo UAS (USB Attached SCSI) sobre SAT (SCSI / ATA Translation) para enviar comandos ATA sobre SCSI sobre USB. La razón por la que esto es tan complejo se debe a razones históricas.
En algún lugar de la cadena USB → UAS → SCSI → SAT → SATA alguna pieza de hardware tiene una implementación incorrecta. Por lo general, todo esto se realiza mediante un solo microchip dentro del gabinete llamado puente USB-SATA y algunas variantes bien conocidas son ASM1051, ASM1053 y ASM1153. De estos, se sabe que el ASM1051 tiene errores y se debe evitar el UAS con cualquier hardware que contenga este chip. ASM1053 y ASM1153 pueden o no funcionar dependiendo del firmware real dentro del chip (el fabricante puede personalizar el firmware, la implementación de referencia funciona correctamente). Por ejemplo, muchos gabinetes fabricados por Seagate usan ASM1153 con firmware personalizado y tienen problemas con algunos comandos ATA incluso si el mismo chip funciona correctamente con firmware de referencia. (Por ejemplo, algunos gabinetes de Seagate funcionan siempre que el sistema operativo nunca envíe comandos de 12 o 16 bits. Linux usb_storage apoya la peculiaridad t para este propósito.) El usuario final generalmente no puede reemplazar el firmware, por lo que si tiene un chip / firmware defectuoso, su única opción es presentar una queja al fabricante. En el caso de Seagate, “solucionan” el problema indicando que son oficialmente compatibles con Windows y OS X únicamente. Seagate está trabajando oficialmente en la actualidad con la comunidad de Linux, por lo que quizás sus productos realmente funcionen en el futuro.
La única forma real de averiguar el chip puente es desmantelar la carcasa e inspeccionar las marcas en los microchips reales.
Actualizar: Los gabinetes “Seagate Backup Plus Hub” tienen un puente USB-SATA que funciona correctamente y el UAS funciona correctamente (¡tenga en cuenta que este es un producto diferente de “Seagate Backup Plus”!) Sin embargo, debido al historial deficiente de los gabinetes Seagate, el kernel de Linux aplica la peculiaridad t de forma predeterminada, lo que evita que este gabinete utilice todas las funciones SATA. Puede habilitar la compatibilidad total con SATA, incluidas las funciones SMART, con el siguiente comando:
echo "0bc2:ab38:" > /sys/module/usb_storage/parameters/quirks
Tenga en cuenta los dos puntos finales y nada después de eso: deshabilita todas las peculiaridades integradas para el proveedor seleccionado: producto. Verifique los identificadores de su proveedor y producto con lsusb si es necesario.
Si su dispositivo tiene suficientes errores, es posible que deba deshabilitar totalmente la compatibilidad con UAS. Esto se puede hacer con el u capricho. Por ejemplo, si quisiera deshabilitar la compatibilidad con UAS en Seagate Backup Plus Hub, ejecutaría lo siguiente como root:
echo "0bc2:ab38:u" > /sys/module/usb_storage/parameters/quirks
Después de eso, el disco externo usará solo funciones de dispositivo de almacenamiento USB más lentas pero que generalmente funcionan y las cosas terminan funcionando … lentamente. Si solo necesita transferir algunos archivos grandes, la diferencia no es tan mala. Si tiene muchos archivos pequeños, la diferencia entre tener soporte UAS en funcionamiento puede ser más de 10 veces la diferencia de velocidad.
Tuve un problema similar con mis unidades SCSI negras de Seagate de respaldo delgado y WD. Y estaba usando hdparm también. Lo que funcionó para mí es elsdparm utilidad.
Instalar con
sudo apt install sdparm
Obtenga todos los parámetros / configuraciones con
sudo sdparm -l -a /dev/sdX
Aquí -a obtiene todos los campos de salida y -l obtiene la salida larga, es decir, la explicación de los campos de salida. /dev/sdX es la unidad en cuestión (similar a /dev/sda).
Obtenga el temporizador de spindown y el STANDBY bandera con:
sudo sdparm -l --get SCT /dev/sdX
sudo sdparm -l --get STANDBY /dev/sdX
El tiempo de spindown SCT aquí está en milisegundos y STANDBY bandera es el interruptor de encendido / apagado (1/0) del temporizador spindown
Si su salida es similar a:
# STANDBY 0 [cha: y, def: 1, sav: 1]
# SCT 4294967286 [cha: y, def:18000, sav:18000]
Esto significa que su dispositivo no está configurado para girar.
Si lo desea, puede cambiar esta configuración para la sesión actual con:
sudo sdparm -l --set SCT=6000 /dev/sdX
sudo sdparm -l --set STANDBY=1 /dev/sdX
Esta configuración se perderá al reiniciar.
Cambiar permanentemente con:
sudo sdparm -l --save --set SCT=6000 /dev/sdX
sudo sdparm -l --save --set STANDBY=1 /dev/sdX
Aquí elegí 6 segundos (6000 milisegundos) pero puede elegir según sus requisitos.
Si por alguna razón no puede guardar su configuración, puede ponerla en su /etc/rc.local para configurar estos en el arranque:
sdparm -l --set SCT=6000 --set STANDBY=1 /dev/sdX
Espero que esto ayude.