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
Yes, this is documented on Wikipedia.
Some advanced disk-drive commands, such as Native Command Queuing (which may increase performance), Secure Erase (which allows all data on the drive to be securely erased) and S.M.A.R.T. (accessing indicators of drive reliability) exist as extensions to low-level hard-drive command sets such as SCSI, SATA, or PATA. These features may not work when hard drives are in a disk enclosure supporting a USB mass-storage interface. Some USB mass-storage interfaces are generic, providing basic read-write commands. Although this works well for basic data transfer with hard-drive-based devices, there is no simple way to send advanced, device-specific commands to USB mass-storage devices (although devices may create their own communication protocols over a USB-standard control interface). The USB Attached SCSI (UAS) protocol introduced in USB 3.0 fixes several of these issues, including command queuing, command pipes for hardware requiring them and power management.
Specific USB 2.0 chipsets had proprietary methods of achieving SCSI pass-through, which could be used to read S.M.A.R.T. data from drives using tools such as smartctl (using the -d option followed by "chipset").[6] More recent USB storage chipsets support the SCSI / ATA Translation (SAT) as a generic protocol for interacting with ATA (and SATA) devices.[7]
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 says uas, as opposed to the original usb-storage driver.[1]
Looking at the uas driver it has a number of conditions it needs to work, otherwise it will fail (perhaps silently) and usb-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 for Mass Storage - and look for the bInterfaceProtocol 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 assume usb-storage supports SAT because it'd be trivial.
The real answer is apparently the HDD enclosure is NOT UASP compatible. As such i have an NCQ capable HDD in a non-UASP enclosure which blocks the full force of USB3 in this set-up.
