> On May 20, 2019, at 8:01 AM, Robert Mustacchi <[email protected]> wrote: > > On 5/20/19 0:16 , Brian Bennett wrote: >> Is anybody using USB 3.1 mass storage devices with illumos? (FWIW, I'm using >> SmartOS) >> >> I've had a problem with several different multi-bay drive enclosures where >> the enclosure is reported instead of the individual drives. This causes zfs >> to assign the same devid to each drive, and while I can create a zpool if I >> try replacing a drive I can't because it says a different device (the last >> device) is already part of the pool. For example, if I `zpool attach test >> c1t0d0 c1t0d1` the error message says that c1t0d3 is already part of the >> pool. >> >> This happens with multiple manufacturers, and different number of devices in >> the enclosure. The two main units I have for testing right now are a >> four-bay QNAP TR-004 and a dual-bay HornetTek Gemini. These devices use a >> USB-C connector at the device, and a USB-A connection to the computer. Both >> exhibit the same problem. >> >> Using the two HornetTek enclosures, for example gives this output form >> iostat: >> >> # iostat -En | grep Serial >> Vendor: ASMT Product: ASM1352R-PM Revision: 0 Serial No: >> 000000000000000 >> Vendor: ASMT Product: ASM1352R-PM Revision: 0 Serial No: >> 000000000000000 >> Vendor: ASMT Product: ASM1352R-PM Revision: 0 Serial No: >> 000000000000000 >> Vendor: ASMT Product: ASM1352R-PM Revision: 0 Serial No: >> 000000000000000 >> >> And from zdb: >> >> # zdb | grep devid >> devid: 'id1,sd@n5000000000000001/a' >> devid: 'id1,sd@n5000000000000001/a' >> devid: 'id1,sd@n5000000000000001/a' >> devid: 'id1,sd@n5000000000000001/a' >> >> Putting the same disks into a usb 2 enclosure (and using a USB type B >> connector at the device), is entirely different: >> >> # iostat -En | grep Serial >> Vendor: HITACHI Product: HUA723030ALA640 Revision: Serial No: >> Vendor: HITACHI Product: HUA723030ALA640 Revision: Serial No: >> >> And because the serial number is blank rather than a duplicate (though >> obviously invalid) value, the devids aren't duplicated and the pool behaves >> properly. >> >> Has anybody else experienced this? Anybody know what's going on here? >> > > If we're seeing different behavior between using the device as a USB 2.x > and a USB 3.x device there are a few different possibilities that could > be going on that we should at least rule out. What would be useful is to > dump the entire device descriptor tree as a starting point and then see > what's different about what the device is giving us. While I won't be > around for a while to drive this investigation, the simplest way to get > it is in mdb by running: > > ::prtusb > > Which will give a list of devices with indexes then, run ::prtusb -i > <index from above> -v > > Robert
I posted the output here: https://gist.github.com/bahamat/14231d8983a520552c9c4a6cb5817a7e <https://gist.github.com/bahamat/14231d8983a520552c9c4a6cb5817a7e> I have three types of enclosures. None of the enclosures show me the real disk serial number, * usb 2.0 - these seem to work fine, other than not presenting the serial number (SN is blank, all devices are assigned a unique devid). * usb 3.0 - It seems that only a single enclosure is recognized at a time, but each disk is assigned a different devid (I have two of this device, but they're the same mfgr/model, I don't know if this issue is specific to this model or would happen with a different mfgr) * usb 3.1 - I have two different kinds, a single quad-bay, and two dual-bay enclosures. The quad bay presents all serial numbers as 513139334930323. Both dual-bay enclosures present all serial numbers as 000000000000000. Both types of devices cause duplicate devids. -- Brian Bennett Systems Engineer, Cloud Operations Joyent, Inc. | www.joyent.com <http://www.joyent.com/> ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/T400018ace14d8f9b-M683ef9e13fd2a61e6925a289 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
