Hi there. I'm new to Unraid so I'm looking for some debugging help. My diagnostics zip file is attached.

 

I'm running an array with a single 2TB parity drive, 3 2TB storage disks, and a 250GB SSD cache. I want to add another 2TB parity drive. I physically installed the disk and ran the preclear plugin successfully (as far as I can tell). It ran through a pre-read, write, and read back successfully. The disk now shows as "precleared" in Unassigned Devices (see attached).

 

When I try to assign the precleared 2TB disk to the second parity slot, the Main tab simply refreshes and the disk is not assigned. See attached for a video of the refresh. For the fun of it, I used my browser dev tools to inspect the assignment request - I saw all 200s and nothing in the console. The same behavior occurs when trying to assign it to the array.

 

For my hardware, I'm running a NUC-like device with two USB 3.0 4-disk arrays attached. My cache is internal. I fear the issue somehow lies in the USB controller, though if that were the case I don't think I would have been able to preclear the disk to begin with.

 

At a glance, nothing looks suspicious in the logs to me. I'd appreciate any advice you all might have. Thanks!

 

 

jupiter-diagnostics-20201124-1929.zip simplescreenrecorder-2020-11-24_19.23.20.mkv

Edited November 25, 20205 yr by cameronwp

USB is not recommended for disks in the array or cache. Unreliable connections, non-standard disk sizes, inconsistent or non-unique identifiers, probably some other reasons I'm forgetting.

I agree USB is not ideal, but it's what I'm working with for the time being. Any debugging advice would be appreciated.

Try a different USB - SATA adapter.

 

Honestly though, because of how unreliable USB is under load, I wouldn't recommend using parity at all. You would probably be better off keeping the extra drives for manual backups of important data.

 Unraid requires each array disk to have a unique ‘serial number’ to identify it.    It looks like for the first four drives you may have used a 4-bay dock that has generated pseudo serial numbers rather than passing through the drives true serial number.   How have you attached the 5th drive?   If it another bay of the same type then it may be generating a pseudo serial number that is identical to one of the existing drives and if so this will not work.

@itimpi I think your intuition is on the right track. I've got a second 4-bay dock from the same manufacturer for the 5th drive.

 

@jonathanm Not sure I follow. What do you mean by "how unreliable USB is under load"? I agree that transfer speeds are slow, but I haven't seen any evidence to suggest that USB is actually corrupting information.

 

Does anyone know where can I find information about how Unraid identifies drives?

 

Running `udevadm`, I see that each drive is being assigned a `ID_SERIAL` and `ID_SERIAL_SHORT`. Each drive (including my original 4) have a unique `ID_SERIAL` but the same `ID_SERIAL_SHORT`. It looks both were assigned by the drive bays because they do not match the actual serial number of the drives as shown by `smartctl`, which returns accurate metadata about the drives. The `ID_SERIAL` is the same as what Unraid shows in the GUI. Given the pattern of behavior, it seems likely that Unraid is relying on udev identifiers to identify drives.

 

Once again, I wouldn't be using USB if I had any other options available, but this is the only feasible setup for me at the moment. I don't have a pressing need for more storage right this instant, so I'm more interested in debugging this as a fun way to maybe learn a bit about how hardware devices are managed in linux. Here's my plan of attack. If anyone with expertise wants to chime in on my approach, it would be very much appreciated.

 

0. Test a different drive in the same slot. Test the dock with a different machine

1. Disambiguate exactly how Unraid is differentiating between drives - there appear to be multiple "serial number" type identifiers for each drive.

2. If the issue actually is that drive identifiers are colliding, I'll try to add a new udev rule manually to distinguish them (eg. https://www.andreydba.com/unix-linux/how-change-device-name-with-udev)

3. If identification isn't an issue, it could be a USB controller issue on the host machine.

 

Thanks everyone!

11 minutes ago, cameronwp said:

Does anyone know where can I find information about how Unraid identifies drives?

Unraid identifies drives by their serial number (and it checks the size has not changed).  This should be unique for each drive and set during manufacture.   Many USB docks do not pass this number through to Unraid but generate their own version of a serial.     The true serial should be visible in the SMART report for the dtive.

 

16 minutes ago, cameronwp said:

I agree that transfer speeds are slow, but I haven't seen any evidence to suggest that USB is actually corrupting information.

USB connections can be prone to disconnect. When that happens, the disk will be out-of-sync and have to be rebuilt. This could be a frequent occurrence. That is the reason for recommending not using parity since there is nothing to be out-of-sync with.

I see. Appreciate the feedback. In all likelihood, I'm probably going to give up on this approach.

 

I know this is an edge case for Unraid that I'm unlikely to fix. For what it's worth, if I could give feedback to the Unraid development team it would be that I would have preferred to have seen a big red error somewhere indicating that this drive configuration is invalid. It looks like it's failing silently because the drive cannot be assigned due to its serial number. Maybe a future release could tell users when the reported serial numbers are invalid or are likely to cause problems?

 

To give y'all some more details for the fun of it, here's what I'm seeing for the serial number reported by udev and SMART.

root@Jupiter:~# udevadm info --query=all --name=/dev/sda
P: /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host0/target0:0:0/0:0:0:0/block/sda
N: sda
S: disk/by-id/usb-Hitachi_HDS722020ALA330_152D00539000-0:0
S: disk/by-path/pci-0000:00:14.0-usb-0:3:1.0-scsi-0:0:0:0
E: DEVLINKS=/dev/disk/by-id/usb-Hitachi_HDS722020ALA330_152D00539000-0:0 /dev/disk/by-path/pci-0000:00:14.0-usb-0:3:1.0-scsi-0:0:0:0
E: DEVNAME=/dev/sda
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host0/target0:0:0/0:0:0:0/block/sda
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_INSTANCE=0:0
E: ID_MODEL=HDS722020ALA330
E: ID_MODEL_ENC=HDS722020ALA330\x20
E: ID_MODEL_ID=0567
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=pci-0000:00:14.0-usb-0:3:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_3_1_0-scsi-0_0_0_0
E: ID_REVISION=0125
E: ID_SERIAL=Hitachi_HDS722020ALA330_152D00539000-0:0
E: ID_SERIAL_SHORT=152D00539000
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Hitachi
E: ID_VENDOR_ENC=Hitachi\x20
E: ID_VENDOR_ID=152d
E: MAJOR=8
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=54845711930

root@Jupiter:~# smartctl -i /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Hitachi Deskstar 7K2000
Device Model:     Hitachi HDS722020ALA330
Serial Number:    JK1131YBKA6JWV
LU WWN Device Id: 5 000cca 221e0d349
Firmware Version: JKAOA3EA
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Wed Nov 25 10:13:58 2020 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

It's pretty surprising to me seeing different serial numbers, but I buy that's the reason Unraid is unable to assign this disk.

USB is allowed and some people have successfully used it. But success seems to depend on specific hardware and how it is used, such as not bothering with parity.

 

Another thing I forgot in my list of reasons to not do this, and it can also apply to other external enclosures that don't use USB.

 

Ideally, parity operations happen in parallel. Writes to the parity array, rebuilds, parity checks, requires accessing disks in parallel, in some cases all disks in parallel. If an external enclosure only has one port for multiple disks, performance will suffer greatly.