Other Spin down idle disks with USB SATA/PATA adapter

[geek]

Hello.

I'm planning to set up a Raspberry Pi server and, among other things, use hard disks with USB adapters for NAS with RAID. I want the disks to spin down after some time of inactivity. I experimented with an USB adapter and one SATA disk on my x86_64 desktop, and using ataidle -s /dev/da4 doesn't work, but camcontrol standby da4 does spin the disk down.

dmesg for the disk with USB adapter says:

ugen1.6: <JMicron> at usbus1
umass1: <MSC Bulk-Only Transfer> on usbus1
umass1:  SCSI over Bulk-Only; quirks = 0x4000
umass1:8:1:-1: Attached to scbus8
(probe0:umass-sim1:1:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00
(probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error
(probe0:umass-sim1:1:0:0): SCSI status: Check Condition
(probe0:umass-sim1:1:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(probe0:umass-sim1:1:0:0): Error 22, Unretryable error
da4 at umass-sim1 bus 1 scbus8 target 0 lun 0
da4: <WDC WD32 00BEVS-60VAT0 > Fixed Direct Access SPC-3 SCSI device
da4: Serial Number 000001D918E5
da4: 40.000MB/s transfers
da4: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C)
da4: quirks=0x2<NO_6_BYTE>

I don't know whether I should make another thread for this thing, but I would also like to know whether there is a way to cache write operations while disk is spun down and flush the cached operations to disk when spinning, possibly automatically spinning up the disk after it has been idle for a longer time, say, 24 hours, to prevent loss of much data in the case of power loss, for example.

 

[giorgiob]

I have a similar set up with a rpiB+ using an external 1TB Toshiba disk. During boot I get this error message but afterwards everything works fine. I have another rpiB+ with a 500GB USB Toshiba disk, and on this system the error does not occur. Both are running FreeBSD 11.

 

[ralphbsz]

Icky. Complicated.

Your disk is a SATA disk. It has a SATA connector, and on that it speaks the SATA command set. You have plugged it into a USB-to-SATA converter of some sort. That thing speaks USB protocol to the host, and the USB sub-protocol that is used here is SCSI-over-bulk. In the FreeBSD operating system, the device driver then attaches this device to the SCSI driver, which is why the device name is /dev/daX (the da driver is the scsi driver, look at "man 4 da"). So the problem is that you are speaking in SCSI commands to a SATA device. However, the command set between SATA and SCSI is completely different. Someone has to do that translation. Who is that someone? The little USB-to-SATA gadget.

Unfortunately, the implementation of the translation on those devices tends to range from bad to horrible. The cheaper the adapter, the more horrible it gets. Let's start with the example in the error message above: When the FreeBSD da (SCSI) driver first sees the disk drive da4, it asks it: "Tell me about all the virtual disks you contain", by issuing the "Report LUN" command (a "LUN" is SCSI pidgin for "logical unit", or virtual disk within a disk). Unfortunately, SATA disks don't contain virtual disks (most SCSI disks don't either, but some do, and the SCSI command set allows for it, so it is a reasonable question for FreeBSD to ask). And I think the SATA command set doesn't even have a concept of "LUN", so even asking this question is kind of dumb. So what does the USB-to-SATA translator do in this case? Your error message shows that very clearly: It refuses to execute the "Report LUN" command by replying with "je ne parlez pas francais" (which in SCSI error codes is implemented as "invalid command"). That's kind of a good thing to do: it's a meaningless question, since a SATA disk doesn't have a LUN. And it is kind of an bad thing to do: a SATA disk really does contain a single block device, so a better answer would have been to fabricate a fake but valid answer to "Report LUN" with response that indicates that the disk contains exactly one LUN. Fortunately, the FreeBSD driver is reasonable, and excuses the device for not answering this question. And this is a typical example of the trouble that one gets into with protocol translators.

And this is the root cause for your problem with spinning down disks: Most likely the "ataidle" command wants to send a SATA command directly to the disk. Alas, to speak to the disk you have to send *SCSI* commands to the USB-to-SATA converter. It seems that "camcontrol" knows how to send something that is understood. When using protocol translators, you just have to do trial and error to get these kinds of things to work.