is there a well known reason why a SATA3.0 HDD supporting NCQ does not have NCQ queue depth configured when mounted from an usb 3.0 case ?
output for hdparm -iI /dev/sda shows NCQ is supported
output for
cat /sys/block/sda/device/queue_depth
31cat /sys/block/sdb/device/queue_depth
1
I cannot change the queue_depth for 1 as it is denied
Best Answer
Yes, this is documented on Wikipedia.
It seems clear that the original UMS can't support command queuing (even if you have SAT); you need UAS.
The simplest suggestion is probably just look at the kernel log (
dmesg
) after plugging in the drive. See if it saysuas
, as opposed to the originalusb-storage
driver.[1]Looking at the
uas
driver it has a number of conditions it needs to work, otherwise it will fail (perhaps silently) andusb-storage
will take over. Apparently the USB controller needs scater-gather support, also some UAS devices could be ignored as unsupported...I think you could check the capability advertised by the USB device using
lsusb -v
. Find your device(s) - search forMass Storage
- and look for thebInterfaceProtocol
values.80 Bulk-Only
is the value for the original UMS.62
is the new value, for UAS. (These are hex values). So if it can do UAS, you should see both.[1]If you have one of the specific
ums-
drivers loaded, that's interesting too. There's brief descriptions of specific USB storage drivers in the Linux kernel build options.SAT (see above), would just come under the generic
usb-storage
. I assumeusb-storage
supports SAT because it'd be trivial.