allo.

 

Heute zeigt mir mein unraid, daß es mich nicht mehr lieb haben will.

 

Seit mehreren Tagen und Neustarts lief unraid.
Ich fülle seit dem Dateien von einem Remoteshare auf das Array per Krusader/ich777 Docker (Array bisher ohne Parity).

 

Gestern habe ich eine weitere Festplatte angeschlossen (Disk17 Seagate 16TB) und per Preclear bereinigt.
Als Preclear heute durch war, habe ich das Array gestoppt, um diese Disk erweitert und gestartet.
Krusader neu gestartet und weiter Daten von remote aufkopiert.

 

Auf einmal meldet sich "Fix Common Problems" mit dem Hinweis, daß mehrere Disks den Writecache abgeschaltet haben.
Dem dort angegebenen Link folgend habe ich es über das terminal versucht zu beheben.

  https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-755621

Kein Erfolg.
Daraufhin habe ich Rebootet, Passphrase angegeben und Array gestartet.
"Fix Common Problems" meldet wieder den Hinweis.
Siehe Bildschirmkopie 1.

 

Es wird auch ein Link mit Infos zum einschalten per Terminal mitgeliefert, doch das funktioniert eben nicht.
Siehe Bildschirmkopie 2.

 

Falls Systeminfos interessant sind siehe Bildschirmkopie 3.

 

Nur die beiden Seagate 16TB stammen aus geöffneten externen USB Gehäusen.
Alle anderen Festplatten sind als normale Platten gekauft worden.

 

Any Idea wie ich den Cahe wieder einschalten kann?
Ich gehe davon aus, daß der Cache vorher aktiv war, da Fix Common Problems die ganze Zeit installiert ist und sich erst jetzt deswegen gemeldet hat.

 

Danke!

 

 

 

 

Ich habe die Aufteilung der Festplatten mal zusammengefasst:
Abgeschalteter Cache:
 5 sdj Toshiba 18 TB an  Adaptec Series 7
 8 sdd Toshiba 16 TB an  Adaptec Series 7
 9 sde Toshiba 16 TB an  Adaptec Series 7
10 sdf Toshiba 16 TB an  Adaptec Series 7
11 sdg Toshiba 16 TB an  Adaptec Series 7
12 sdh Toshiba 16 TB an  Adaptec Series 7
13 sdi Toshiba 16 TB an  Adaptec Series 7
14 sdm Toshiba 16 TB an  Adaptec Series 7
15 sdn Toshiba 16 TB an  Adaptec Series 7
16 sdc Toshiba 16 TB an  Adaptec Series 7
==
nicht als betroffen gelistet:
 1 sdv Seagate 18 TB an an JMB582 M.2 2230
 2 sdu Seagate 18 TB an an JMB582 M.2 2230
 3 sdw Seagate 18 TB an an ASM1064 PCIe x1
 4 sdx Seagate 18 TB an an ASM1064 PCIe x1
 6 sdk Seagate 16 TB an  Adaptec Series 7
 7 sdb Toshiba 16 TB an  Adaptec Series 7
17 sdl Seagate 16 TB an  Adaptec Series 7
PoolSSDa   sdo Crucial SSD 2TB an Intel Chipset Onboard
PoolSSDa 2 sdp Crucial SSD 2TB an Intel Chipset Onboard
PoolSSDb   sdq Crucial SSD 2TB an Intel Chipset Onboard
PoolSSDb 2 sdr Crucial SSD 2TB an Intel Chipset Onboard

Reserviert für spätere Parity:
   sds Toshiba 18 TB an an Intel Chipset Onboard
   sdt Seagate 18 TB an an Intel Chipset Onboard

Edited December 27, 20214 yr by DataCollector
Festplattenauflistung zugefügt

Kann es sein, dass du Write Cache, eine Hardware Funktion einer HDD mit dem Unraid Cache Pool verwechselst?

 

In wie weit das überhaupt relevant ist und ob die Toshiba überhaupt ihren richtigen Status zurückgeben, kann keiner sagen. Müsstest du mal speziell nach diesem Modell und dem Write Cache suchen. Hat nichts mit unRAID zu tun.

1 hour ago, mgutt said:

Kann es sein, dass du Write Cache, eine Hardware Funktion einer HDD mit dem Unraid Cache Pool verwechselst?

 

Hallo @mgutt

Nicht, daß ich wüßte.

Fix Common Problems meldet mir, daß der Writecache der gelisteten Festplatten abgeschaltet ist (ja, das ist eine steuerbare Funktion in der Hardware der Festplatten).

Diese Meldung ist die Tage vorher auch bei mehreren Neustarts nie erschienen, weshalb ich davon ausgehe, daß der Writecache der Festplatten da nie ausgeschaltet war.

Der Cachepool ist in den Shares gar nicht aktiviert, weil ich beim Erstbefüllen die SSDs nicht kaputtschreiben will.

 

 

1 hour ago, mgutt said:

In wie weit das überhaupt relevant ist und ob die Toshiba überhaupt ihren richtigen Status zurückgeben, kann keiner sagen.

Siehe Screenshot unten.

Ich habe als Gegenprobe mal die zwei als nicht betroffen gemeldeten Toshibas und eine Seagate mit dem Befehl angestoßen.

Dort wird der Cache als    on    zurückgemeldet.

Es ist also keine Problem, daß ursächlich in den Toshiba Platten liegt.

 

1 hour ago, mgutt said:

Müsstest du mal speziell nach diesem Modell und dem Write Cache suchen. Hat nichts mit unRAID zu tun.

Erst seitdem die Disk 17 Seagate 16TB Exos hinzugefügt wurde erscheint dieses Problem bei einigen der Toshiba Festplatten.

Bisher habe ich in meiner Suche keine solche Besonderheiten im Netz gefunden.

Mir ist klar, daß unraid das nicht absichtlich gesteuert hat, genau wie unraid bei ECC RAM Fehlern oder CPU Problemen oder so nicht absichtlich abschmiert.

Aber es ist die einzige softwaremäßige Stellgröße an dem PC, die mir einfällt.

Ich werde wohl zum weiteren Einkreisen   Festplatten zwischen den Anschlüssen tauschen und die neu hinzugefügte Seagate (nach der das Problem zum ersten Mal angezeigt wurde) entfernen müssen.

 

Edited December 26, 20214 yr by DataCollector
einige Tippfehler entfernt

28 minutes ago, DataCollector said:

Mir ist klar, daß unraid das nicht absichtlich gesteuert hat

unRAID stellt diese Werte nicht ein. Das hat wie gesagt nichts mit unRAID zu tun.

 

Kann auch gut sein, dass dein HBA Controller diese Werte gar nicht korrekt durchleitet. Genauso gut kann es sein, dass der HBA die Befehle für die Änderung einfach verschluckt.

 

Am besten mal den Status einer betroffenen HDD direkt an einem Onboard SATA Anschluss prüfen. Wenn es da richtig ist, liegt es am HBA.

 

EDIT: Jo. Offensichtlich ein Bug des HBA:

https://forums.unraid.net/topic/94965-adaptec-71605-16i-sata-port-hba-card-for-~50-review-and-how-to-fix-write-cache-disabled/

Hallo @mgutt

12 hours ago, mgutt said:

EDIT: Jo. Offensichtlich ein Bug des HBA:

https://forums.unraid.net/topic/94965-adaptec-71605-16i-sata-port-hba-card-for-~50-review-and-how-to-fix-write-cache-disabled/

 

Ich bedanke mich herzlich bei Dir!

 

Ich weiß nicht, warum ich das bei meiner Suche nicht gefunden habe.

Es hat geholfen.

Siehe Screenshot unten (ich habe es darin ausführlicher dokumentiert, damit ggf. andere das vielleicht schneller finden und verstehen können).

 

Hier nochmal die Befehle in Textform, damit sie jemand auch simpel kopieren kann ohne die anderen Threads aufmachen zu müssen.

 

hdparm -W 1 /dev/sdj
smartctl -s wcache-sct,on,p /dev/sdj

 

Und hier der Screenshot des Terminalfensters:

 

 

 

 

Ergänzung:

Ich Befülle je gerade das Array mit Daten von einem Remoteshare.

Nachdem der WriteCache nun aktiv ist, stieg die angezeigte Schreibgeschwindigkeit im Main Tab bei der selben Festplatte von vorher rund 200MByte/s auf rund 240MByte/s. Auch zeigen das Dashboard und auch htop eine geringere CPU Belastung.

Ich hatte befürchtet, daß durch den abgeschalteten WriteCache die kontinuierlichen Schreibvorgänge der Dateien und das Verzeichnen jeder einzelnen Datei und Position auf dem Datenträger sich gegenseitig negativ beeinflußt und bei langandauernden Schreibvorgängen nicht komplett durch PC RAM abgefedert werden kann (weil ab und zu eingelegte kurze Pausen einen performancesprung brachten).

Ich schätze, die Vermutung war nicht ganz falsch.

 

Edited December 27, 20214 yr by DataCollector
Ergäzung zugefügt