Problem mit hd-idle mit Rasberry Pi 4 und Icy Box IB-RD3640SU3 3xHDD's WD RED in RAID3

Hi Tim,

hast Du im Forum gesucht? Ich meine mich an einem Thread zu diesem Thema zu erinnern und da waren Troubleshooting Anleitungen drin.

ganz am Ende des HowTo Guides steht der Hinweis

Zitat von auanasgheps

if you need help with hd-idle, please write a post in the original discussion since you can't reply to this guide.

dort wird Dir geholfen

Hallo zusammen!

SanJager Werden die Platten in der IcyBox separat erkannt oder nur als Verbund? Aus dem Screenshot oben schließe ich auf Letzteres. Wenn es trotz HD-Idle nicht funktioniert, dann gibt der USB2Sata-Controller in der IcyBox das Kommando nicht an die Platten weiter.

Manche externe Gehäuse lassen sich Firmware-mäßig umflashen, damit es doch geht. Dazu gibt´s hier auch schon einige Threads, da das leider ein häufiges Ärgernis ist.

Der Guide bezieht sich primär auf Platten, die über SATA angeschlossen sind. Bei Platten in externen Gehäusen kann das funktionieren, muss aber nicht, da wie ich schon geschrieben habe, der dort verbaute Controller noch mitspielen muss.

Wenn du an deinem Setup noch bereit bist etwas zu ändern, dann könntest du versuchen, die Platten so zu konfigurieren, dass sie einzeln in OMV erkannt werden und die Redundanz / Pooling dann mittels der Plugins "snapraid" und "unionfs" herzustellen und eine Erkennung von Datenkorruption bekommst du sozusagen gratis mitgeliefert.

Edit:

Zitat von SanJager

(3x 4Tb WD Red im RAID3 mit USB 3.0 angeschlossen)

Warum ausgerechnet der RAID3-Mode? Das ist ein eher ungewöhnlicher Modus. Ab drei Platten wird meistens RAID5 verwendet, da hier außer den Daten auch die Paritätsinformationen auf alle Disks gleichmäßig verteilt werden.

Zitat von SanJager

Gibt es eigentlich die Möglichkeit über ssh Manuel ein Idle Befehl aus zu geben?

Zu jedem Programm gibt es auch eine Doku

Die sagt zu hd-idle: ja

CLI> hd-idle -t <disk> mit <disk> ohne /dev/-Prefix.

Hab´ ich aber nur aus der Doku und nicht selbst ausprobiert.

Edit:

Nehme mal an, dass diese Doku wohl eher passt, da sie sich auf die aktuellere Version bezieht: adelolmo / hd-idle

Also in meiner Icy Box IB-RD3662-C31 / hardware supported RAID1 funktioniert hd-idle korrekt.

Denke die Ursache/Fix ist nicht im Zusammenhang mit HW RAID

Was ist die Ausgabe von den folgenden Kommandos?

root@nas:~# lsusb -t

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M

|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M

|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

root@nas:~# uname -a

Linux nas 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux

Zitat von SanJager

spuckt er mir 1:1 das gleiche aus wie bei dir.

nicht ganz, es gibt einen subtilen, aber vermutlich entscheidenden Unterschied

bei mir ist es der UAS Treiber 'Class=Mass Storage, Driver=uas, 5000M' bei dir 'Class=Mass Storage, Driver=usb-storage, 5000M'

lsusb hat noch weitere Parameter um mehr Details auszugeben. Kannst Du die richtigen Parameter selbst rausfinden?

Zitat von SanJager

Verstehe ich das richtig das sich die beiden USB-SATA Bords in den Raid system von Icy Box unterscheiden

Das könnte sein und ihr könnt das herausfinden, wenn mi-hol auch mal den ausführlichen lsusb Befehl laufen lässt und dann die dort genannten USB-Bridge Chips verglichen werden. Wenn es in beiden Fällen der Gleiche ist, dann kann es eigentlich nicht am Chip liegen, oder?

Meine IcyBox hat einen anderen chipset von ASMedia

```

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 3.10

bDeviceClass 0

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 9

idVendor 0x174c ASMedia Technology Inc.

idProduct 0x55aa Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

bcdDevice 1.00

iManufacturer 2 ICY BOX

iProduct 3 IB-RD3662-C31

iSerial 1 123456789100

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 0x0079

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 0

bmAttributes 0xc0

Self Powered

MaxPower 0mA

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 2

bInterfaceClass 8 Mass Storage

bInterfaceSubClass 6 SCSI

bInterfaceProtocol 80 Bulk-Only

iInterface 0

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 15

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x02 EP 2 OUT

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 15

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 1

bNumEndpoints 4

bInterfaceClass 8 Mass Storage

bInterfaceSubClass 6 SCSI

bInterfaceProtocol 98

iInterface 0

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 15

MaxStreams 32

Data-in pipe (0x03)

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x02 EP 2 OUT

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 15

MaxStreams 32

Data-out pipe (0x04)

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x83 EP 3 IN

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 15

MaxStreams 32

Status pipe (0x02)

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x04 EP 4 OUT

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0400 1x 1024 bytes

bInterval 0

bMaxBurst 0

Command pipe (0x01)

Binary Object Store Descriptor:

bLength 5

bDescriptorType 15

wTotalLength 0x002a

bNumDeviceCaps 3

USB 2.0 Extension Device Capability:

bLength 7

bDescriptorType 16

bDevCapabilityType 2

bmAttributes 0x0000f41e

BESL Link Power Management (LPM) Supported

BESL value 1024 us

Deep BESL value 61440 us

SuperSpeed USB Device Capability:

bLength 10

bDescriptorType 16

bDevCapabilityType 3

bmAttributes 0x00

wSpeedsSupported 0x000e

Device can operate at Full Speed (12Mbps)

Device can operate at High Speed (480Mbps)

Device can operate at SuperSpeed (5Gbps)

bFunctionalitySupport 1

Lowest fully-functional device speed is Full Speed (12Mbps)

bU1DevExitLat 10 micro seconds

bU2DevExitLat 2047 micro seconds

SuperSpeedPlus USB Device Capability:

bLength 20

bDescriptorType 16

bDevCapabilityType 10

bmAttributes 0x00000001

Sublink Speed Attribute count 1

Sublink Speed ID count 0

wFunctionalitySupport 0x1100

bmSublinkSpeedAttr[0] 0x000a4030

Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus

bmSublinkSpeedAttr[1] 0x000a40b0

Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus

can't get debug descriptor: Resource temporarily unavailable

Device Status: 0x000d

Self Powered

U1 Enabled

U2 Enabled

```

Certain JMicron chipsets have issues affecting OMV

see https://github.com/openmediavault/openmediavault/issues/876

and https://github.com/openmediavault/openmediavault/issues/896

Zitat von mi-hol

Certain JMicron chipsets have issues affecting OMV

see https://github.com/openmediavault/openmediavault/issues/876

and https://github.com/openmediavault/openmediavault/issues/896

Die Sache mit der Meldung von identischen Seriennummern bei unterschiedlichen Drives wurde in einer OMV5-Version bereits gefixt, indem die Laufwerke wieder über die UUID eingebunden werden und nicht mehr über das Label, soweit ich weiß.

Zitat von cabrio_leo

Meldung von identischen Seriennummern bei unterschiedlichen Drives wurde in einer OMV5-Version bereits gefixt

ja schon, aber meiner Meinung zeigt das , dass der Treiber gewisse Probleme hat.

Da der Treiber code einer Familie von chipsets oft am Anfang nur von der vorigen Generation kopiert wird, zeigt die Erfahrung "Findet man eine Problem ist das nächste meist nicht weit"

Zitat von cabrio_leo

Die Sache mit der Meldung von identischen Seriennummern bei unterschiedlichen Drives wurde in einer OMV5-Version bereits gefixt

Das war von mir nur als Hinweis gemeint.

Zitat von mi-hol

ja schon, aber meiner Meinung zeigt das , dass der Treiber gewisse Probleme hat.

Stimmt. Letztlich umgeht die UUID-Methode nur ein Problem, welches der Chipsatz bzw. Treiber hat. Die JMicron Teile werden halt oft eingesetzt und zudem ist es oft schwer herauszufinden, welche Chipsätze in den externen Boxen verbaut sind. Nicht jeder Hersteller gibt es in seinem Datenblatt an.

Zitat von cabrio_leo

Die JMicron Teile werden halt oft eingesetzt

Man sollte mit dem Maintainer des codes in Kontakt treten und mit demjenigen diskutieren, ob eine fix/Verbesserung moeglich ist.

Mit der Aufgabe kann aber mMn nur jemand erfolgreich sein, der im Linux Kernel/ Treiber Umfeld schon gearbeitet hat.

Kennen wir da jemanden mit dieser Erfahrung?

SanJager schreib ihn doch mal an und frag nach seiner Konfiguration fuer hdidle