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

cat /sys/block/sdb/device/queue_depth

I cannot change the queue_depth for 1 as it is denied

  • Does the case support USB attached SCSI (UAS)? – ζ-- Jul 31 '14 at 22:33

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 drive is mounted as /dev/sdb if that is what you mean, how is this relevant to my question ? ( Just curious ) – Saint Crusty Aug 1 '14 at 7:50
  • Thanks. Just to be clear. How do i get this type of information from my system ? hdparm -iI /dev/sdb ? – Saint Crusty Aug 1 '14 at 10:30
  • @SaintCrusty That sounds far too easy to be true :). Answer updated. – sourcejedi Aug 1 '14 at 13:09
  • I've come around to validating it does indeed report 80 instead of 62. But i can say for sure NCQ is supported on the drive, it is just not available using USB 3.0, could it be BIOS or controller causing this ? – Saint Crusty Sep 6 '14 at 22:09
  • UASP USB 3.0 cases are available for sale now. – asd.and.Rizzo Dec 14 '18 at 15:21

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.