Freenas support for JMicron USB to ATAATAPI Bridge

[uushaggy]

Hello all,

I been having some problems with my setup.

I have FreeNAS-11.3-U1 (Love the new interface!) running a Intel NUC5CPYB with a Mediasonic PRORAID (HFR2-SU3S2FW) on USB3 port. This RAID unit can run in Single Disk mode and various RAID modes. I know that the Hardware RAID mode is not recommended for FreeNAS so I've been using Single mode (4 individual disks). This unit uses the JMicron USB to ATAATAPI Bridge. I've seen other post with this keyword in them but didn't see any help for my situation.

So my problem is that I can only see one drive, the last drive in cabinet. If I pull out one then I see the next one up. In Windows or in Linux I see all drives fine and can mount and write data, etc.

When I look into what FreeNAS sees its this:

Mar 26 17:18:57 freenas ugen0.3: <JMicron USB to ATAATAPI Bridge> at usbus0 Mar 26 17:18:57 freenas umass0 on uhub0 Mar 26 17:18:57 freenas umass0: <JMicron USB to ATAATAPI Bridge, class 0/0, rev 3.00/2.03, addr 3> on usbus0 Mar 26 17:18:57 freenas umass0: SCSI over Bulk-Only; quirks = 0x0100 Mar 26 17:18:57 freenas umass0:1:0: Attached to scbus1 Mar 26 17:18:57 freenas da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 Mar 26 17:18:57 freenas da0: <H/W DISK 1 0523> Fixed Direct Access SPC-4 SCSI device Mar 26 17:18:57 freenas da0: Serial Number 152D00539000 Mar 26 17:18:57 freenas da0: 400.000MB/s transfers Mar 26 17:18:57 freenas da0: 476940MB (976773168 512 byte sectors) Mar 26 17:18:57 freenas da0: quirks=0x2<NO_6_BYTE> Mar 26 17:18:58 freenas GEOM_MULTIPATH: disk1 created Mar 26 17:18:58 freenas da1 at umass-sim0 bus 0 scbus1 target 0 lun 1 Mar 26 17:18:58 freenas da1: <H/W DISK 2 0523> Fixed Direct Access SPC-4 SCSI device Mar 26 17:18:58 freenas da1: Serial Number 152D00539000 Mar 26 17:18:58 freenas da1: 400.000MB/s transfers Mar 26 17:18:58 freenas da1: 476940MB (976773168 512 byte sectors) Mar 26 17:18:58 freenas da1: quirks=0x2<NO_6_BYTE> Mar 26 17:18:58 freenas GEOM_MULTIPATH: da0 added to disk1 Mar 26 17:18:58 freenas GEOM_MULTIPATH: da0 is now active path in disk1 Mar 26 17:18:58 freenas da2 at umass-sim0 bus 0 scbus1 target 0 lun 2 Mar 26 17:18:58 freenas da2: <H/W DISK 3 0523> Fixed Direct Access SPC-4 SCSI device Mar 26 17:18:58 freenas da2: Serial Number 152D00539000 Mar 26 17:18:58 freenas da2: 400.000MB/s transfers Mar 26 17:18:58 freenas da2: 476940MB (976773168 512 byte sectors) Mar 26 17:18:58 freenas da2: quirks=0x2<NO_6_BYTE> Mar 26 17:18:58 freenas da3 at umass-sim0 bus 0 scbus1 target 0 lun 3 Mar 26 17:18:58 freenas da3: <H/W DISK 4 0523> Fixed Direct Access SPC-4 SCSI device Mar 26 17:18:58 freenas da3: Serial Number 152D00539000 Mar 26 17:18:58 freenas da3: 400.000MB/s transfers Mar 26 17:18:58 freenas da3: 476940MB (976773168 512 byte sectors) Mar 26 17:18:58 freenas da3: quirks=0x2<NO_6_BYTE> Mar 26 17:18:58 freenas GEOM_MULTIPATH: disk2 created Mar 26 17:18:58 freenas GEOM_MULTIPATH: da1 added to disk2 Mar 26 17:18:58 freenas GEOM_MULTIPATH: da1 is now active path in disk2 Mar 26 17:18:58 freenas GEOM_MULTIPATH: disk3 created Mar 26 17:18:58 freenas GEOM_MULTIPATH: da2 added to disk3 Mar 26 17:18:58 freenas GEOM_MULTIPATH: da2 is now active path in disk3

So am I correct to understand that because the disks all show the same serial number that FreeNAS assumes its a multipath scenario? That's what it looks like.
Is there any way to help FreeNAS understand this is 4 separate disk? I know some USB vendors don't do unique serial numbers and that's not a great idea but trying to understand if I can do anything to get this working.

Thanks for any help!

dave

 

[JamesT42]

Hi.
Just today I discovered the same problem with a FANTEC external USB3 4-bay case. Wish I knew that beforehand... Sadly I'm also clueless how to solve this....

 

[sretalla]

There are several things to say here...

I should start by saying I personally explored this road some years ago (knowing I was on my own and expecting no support if things went wrong).

I used an ICY BOX IB-RD3620SU3 (3.5") 2 bay, ICY BOX IB-3680SU3 (3.5") 8-bay and a couple of sharkoon 5 bay enclosures at various points.

Except for the 2-bay box, all 3 of them had controller failures within 6 months of being put into use. (I retired the 2-bay before it failed).

I count the experience with those enclosures as a cautionary tale in how to lose all of the data in your pool.

That said, although it was an expensive way to try something, I did manage to keep all my data and transferred the disks into a proper chassis attached to an HBA (that's another story) without the need for any resilvering.

The trick to getting them to work (if you're still interested in temporarily putting your data at risk in one) is to use gmultipath.

Start with gmultipath list

Then gmultipath destroy <diskname> for each of the disks that were listed. It's not as bad as you might think... even when those multipath disks contain disks that were parts of pools before, destroying the multipath disk does no damage to them and they just go right back into the pools like nothing happened.

To try to prevent this coming back I had added a command as a pre-init for kldunload geom_multipath.ko ... mostly successful.