Cache verhält sich seltsamm, bitte um einen Rat

[dyVinter]

Hallo zusammen!

 

Eine Frage in die Runde:

 

Der Cache am UnraidServer verhält sich seltsam oder ich versehe etwas nicht richtig.

 

Vor ein paar Tagen habe ich ein Share erstellt und wollte dort hin ein paar Daten hochladen, der Transfervorgang wurde wegen Schreibschutzrechte nach ca. 280Gb unterbrochen. Die Daten (280Gb) waren im Cache, da die Einstellungen von Shares „Benutze den Cache-Pool“ auf „Ja“ eingestellt sind. Danach ist der Cache vermutlich eingestürzt, da kein Dockes und keine VM mehr zu erreichen waren, wegen "appdata, system" Ordner, die waren auf einmal nicht mehr da.

 

Danach sind zwei Cachefestplatten unter „Unassigned Devices“ aufgetaucht, mit der Kennzeichnung 🚫ARRAY. Ich verstehe nicht, was das bedeutet.

 

Kann mir jemand sagen, was das ist?

 

 

Vielen Dank!

 

 

[mgutt]

Poste deine Diagnostics. Das ist nicht normal. Sind die SSDs direkt am Mainboard angeschlossen?

 

Unabhängig davon musst du einen Minimum Free Space beim Cache einstellen, der größer ist als die größte Datei, die du auf den Server hochladen willst. Dadurch wird verhindert, dass dieser voll laufen kann und es gibt auch keine Kollision mit Docker / VM.

 

Aber sie gesagt ist das nicht normal, was dir passiert ist.

 

Hast du New Config gemacht oder ausgewählt, dass du ohne Pool das Array starten möchtest?!

[DataCollector]

9 hours ago, dyVinter said:

Der Cache am UnraidServer verhält sich seltsam oder ich versehe etwas nicht richtig.

...

Danach sind zwei Cachefestplatten unter „Unassigned Devices“ aufgetaucht, mit der Kennzeichnung 🚫ARRAY. Ich verstehe nicht, was das bedeutet.

Kann mir jemand sagen, was das ist?

Mir sieht es aus. als wenn Dein Cache/Pool BTRFS (mutmaßlich alt Raid1) auseinander gefallen ist und das System die SSDs nun einzeln ansieht, aber dennoch erkennt, daß die mal zusammen gehörten.

 

Wenn meien Annahme stimmt, daß es BTRFS Raid1 mit den 2 SATA SSD war:

Wenn Du seperate Backups der Daten auf den SSDs hast würde ich die SSDs einfach clearen, per 'new config' den Pool löschen, neu zusammenstellen. neu formatieren und dann weiter nutzen.

 

Wenn Du keine Backups hast, würde ich unraid ausschalten und versuchen die Daten von den SSDs spätestens jetzt auszulesen und als Backup irgendwo hin kopieren.

 

Edited July 1, 2022 by DataCollector
Typos

[dyVinter]

15 hours ago, mgutt said:

Poste deine Diagnostics. Das ist nicht normal. Sind die SSDs direkt am Mainboard angeschlossen?

 

Unabhängig davon musst du einen Minimum Free Space beim Cache einstellen, der größer ist als die größte Datei, die du auf den Server hochladen willst. Dadurch wird verhindert, dass dieser voll laufen kann und es gibt auch keine Kollision mit Docker / VM.

 

Aber sie gesagt ist das nicht normal, was dir passiert ist.

 

Hast du New Config gemacht oder ausgewählt, dass du ohne Pool das Array starten möchtest?!

 

die Festplatten sind über einen Adapter an das Mainboard angeschlossen, aber vorher war keine Probleme damit, der Server läuft seit ca. 8-9 Monaten. Ich teste gerade allen. Ich bin kein Unraid Auskenner, deswegen mache ichlearning by doing

nbei die Diagnistic

New Config habe ich noch nicht gemacht, werde ausprobieren.

 

Der Post von @DataCollector beschreibt sehr nah dieses Problem

serverds-diagnostics-20220702-1044.zip

Edited July 2, 2022 by dyVinter

[dyVinter]

14 hours ago, DataCollector said:

Mir sieht es aus. als wenn Dein Cache/Pool BTRFS (mutmaßlich alt Raid1) auseinander gefallen ist und das System die SSDs nun einzeln ansieht, aber dennoch erkennt, daß die mal zusammen gehörten.

 

Wenn meien Annahme stimmt, daß es BTRFS Raid1 mit den 2 SATA SSD war:

Wenn Du seperate Backups der Daten auf den SSDs hast würde ich die SSDs einfach clearen, per 'new config' den Pool löschen, neu zusammenstellen. neu formatieren und dann weiter nutzen.

 

Wenn Du keine Backups hast, würde ich unraid ausschalten und versuchen die Daten von den SSDs spätestens jetzt auszulesen und als Backup irgendwo hin kopieren.

 

 

ich denke ja, so ist das.

Cache Pool habe ich gelöscht und neu erstellt, die Festplatten habe ich alle neu BTRFS formatiert. Sobald ich den Server neu starte, läuft der ca. 30 min. danach gehen zwei der Cachefestplatten in 🚫ARRAY Modus.   

 

Ich teste den Server seit 8-9 Monate, bis ich die große Menge von Daten hochgeladen habe, ist der gut gelaufen. Vielleicht ist der Cache voll gelaufen!?

Soll ich die Cachefestplatten in anderes Format formatieren?

[mgutt]

33 minutes ago, dyVinter said:

New Config habe ich noch nicht gemacht, werde ausprobieren

Das habe ich nicht gesagt. Mach das nur, wenn du weißt welche HDD in welchem Array Slot war (Screenshot)!

 

27 minutes ago, dyVinter said:

Soll ich die Cachefestplatten in anderes Format formatieren?

Ich vermute du hast ein physisches Problem, denn ein BTRFS RAID geht eigentlich nur kaputt, wenn eine Disk die Verbindung verliert. In deinem Fall vermute ich beide gleichzeitig.

 

EDIT: Aus den Logs

 

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 117, rd 0, flush 24, corrupt 0, gen 0

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 118, rd 0, flush 24, corrupt 0, gen 0

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 118, rd 0, flush 25, corrupt 0, gen 0

 

 

Da ist allgemein was nicht in Ordnung, denn sdf und sdh sind auf dem Foto ja noch Teil des Pools.

 

Sind die Daten auf dem Pool wichtig? Wenn ja, dann brauchst du jetzt ein neues System mit garantiert funktionsfähigen SATA Ports und musst eine Reparatur versuchen. Der aktuellen Hardware kann man meiner Ansicht nach nicht vertrauen.

 

Oder nutzt du irgendwelche Stromspar-Mechanismen wie powertop, die evtl den Controller selbst abschießen?

 

 

[dyVinter]

25 minutes ago, mgutt said:

Das habe ich nicht gesagt. Mach das nur, wenn du weißt welche HDD in welchem Array Slot war (Screenshot)!

 

Ich vermute du hast ein physisches Problem, denn ein BTRFS RAID geht eigentlich nur kaputt, wenn eine Disk die Verbindung verliert. In deinem Fall vermute ich beide gleichzeitig.

 

EDIT: Aus den Logs

 

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 117, rd 0, flush 24, corrupt 0, gen 0

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 118, rd 0, flush 24, corrupt 0, gen 0

Jul 1 17:00:37 serverds kernel: BTRFS error (device sdf1): bdev /dev/sdh1 errs: wr 118, rd 0, flush 25, corrupt 0, gen 0

 

 

Da ist allgemein was nicht in Ordnung, denn sdf und sdh sind auf dem Foto ja noch Teil des Pools.

 

Sind die Daten auf dem Pool wichtig? Wenn ja, dann brauchst du jetzt ein neues System mit garantiert funktionsfähigen SATA Ports und musst eine Reparatur versuchen. Der aktuellen Hardware kann man meiner Ansicht nach nicht vertrauen.

 

Oder nutzt du irgendwelche Stromspar-Mechanismen wie powertop, die evtl den Controller selbst abschießen?

 

 

Quote

Sind die Daten auf dem Pool wichtig?

die Daten auf dem Pool sind nicht wichtig, aber den Poll habe ich bereits gelöscht und neu erstellt. Von die beiden Festplatten kam eine Meldung, das diese  BTRFS Format "nicht finden" und danach tauchen diese in "Unassigned Devices" auf.

 

Quote

Oder nutzt du irgendwelche Stromspar-Mechanismen wie powertop, die evtl den Controller selbst abschießen?

ich benütze keine Stromspar-Mechanismen, vor kurzem USV angeschlossen und NUT Setting eingestellt. Dann hatte ich "ethtool -s eth0 wol d" auf "ethtool -s eth0 wol g" umgestellt, zweimal hatten wir Stromausfall, aber die Batterie lief nicht leer, kurz danach kamen diese Probleme, ob das alles damit zu tun hat!? 

Edited July 2, 2022 by dyVinter

[mgutt]

24 minutes ago, dyVinter said:

ob das alles damit zu tun hat!? 

Denke ich nicht.

 

Dein Problem ist in jedem Fall, dass du SATA Link down Meldungen in den Logs hast. Sobald das passiert, ist das BTRFS RAID quasi sofort kaputt, weil alle Platten, die die Verbindung verlieren, aus dem RAID geworfen werden.

 

Deswegen mögen manche BTRFS RAID5 nicht. Das kann nämlich schnell den totalen Datenverlust bedeuten. Daher lieber zwei große SSDs im BTRFS RAID1 betreiben. Wobei neu kaufen macht SATA eigentlich eh keinen Sinn mehr. Dann würde ich lieber NVMe nehmen.

 

 

 

[dyVinter]

11 minutes ago, mgutt said:

Denke ich nicht.

 

Dein Problem ist in jedem Fall, dass du SATA Link down Meldungen in den Logs hast. Sobald das passiert, ist das BTRFS RAID quasi sofort kaputt, weil alle Platten, die die Verbindung verlieren, aus dem RAID geworfen werden.

 

Deswegen mögen manche BTRFS RAID5 nicht. Das kann nämlich schnell den totalen Datenverlust bedeuten. Daher lieber zwei große SSDs im BTRFS RAID1 betreiben. Wobei neu kaufen macht SATA eigentlich eh keinen Sinn mehr. Dann würde ich lieber NVMe nehmen.

 

 

 

Quote

Dein Problem ist in jedem Fall, dass du SATA Link down Meldungen in den Logs hast. Sobald das passiert, ist das BTRFS RAID quasi sofort kaputt, weil alle Platten, die die Verbindung verlieren, aus dem RAID geworfen werden.

das seltsame ist, dass das Problem nach Datentransfer aufgetaucht, zumindest sehe ich das so.

 

Ich werde weiter testen.

 

Was soll ich am besten bei Cache für "appdata und "system" Orner einstellen? Weil die zwei Ordner "appdata" und "system" sind nach dem Cache Absturz auch verschwunden, deswegen hab ich das Ganze entdeckt, weil VM und Docker nicht mehr zu erreichen waren.

 

Aktuell ist "Bevorzugt" eingestellt.

 

Vielen Dank!

[mgutt]

16 minutes ago, dyVinter said:

Aktuell ist "Bevorzugt" eingestellt.

Deine Cache Einstellung ist in Ordnung. Die ist auch nicht dein Problem. Wie gesagt hast du ein physisches Problem. Sei es Kabel, Controller, Strom, Motherboard oder Netzteil. Da du keine CRC Fehler im SMART der SSD zu beklagen hast (?), können wir die Kabel als Ursache eigentlich schon ausschließen. Also eher was Richtung Strom/Controller. 

 

Eventuell hilft es ASPM per Kernel Option zu deaktivieren. 

 

Also und den USB Stick klicken und in der unRAID OS Zeile "pcie_aspm=off" ergänzen wo ich hpet=disable stehen habe:

 

https://forums.unraid.net/topic/114852-b365m-package-c-states-strom-sparen/?do=findComment&comment=1078534

 

Dann neu starten.

 

Damit wird verhindert, dass jegliche PCI Geräte wie auch der SATA Controller schlafen gehen können.

[dyVinter]

6 minutes ago, mgutt said:

Deine Cache Einstellung ist in Ordnung. Die ist auch nicht dein Problem. Wie gesagt hast du ein physisches Problem. Sei es Kabel, Controller, Strom, Motherboard oder Netzteil. Da du keine CRC Fehler im SMART der SSD zu beklagen hast (?), können wir die Kabel als Ursache eigentlich schon ausschließen. Also eher was Richtung Strom/Controller. 

 

Eventuell hilft es ASPM per Kernel Option zu deaktivieren. 

 

Also und den USB Stick klicken und in der unRAID OS Zeile "pcie_aspm=off" ergänzen wo ich hpet=disable stehen habe:

 

https://forums.unraid.net/topic/114852-b365m-package-c-states-strom-sparen/?do=findComment&comment=1078534

 

Dann neu starten.

 

Damit wird verhindert, dass jegliche PCI Geräte wie auch der SATA Controller schlafen gehen können.

alles klar, werde ich machen, vielen Dank und ein schönes Wochenende!!!

[DataCollector]

3 hours ago, dyVinter said:

die Festplatten sind über einen Adapter an das Mainboard angeschlossen,

1, Frage meinst Du hier mit Festplatten die beiden betroffenen SSD oder wirklich an dem Poolcrash unbeteiligte Festplatten?

2. Frage: Was für ein Adapter?

3. Frage: Nutzt Du Powertop aus dem nerdpack?

 

(Sorry, ich bin noch zu neu, als dass ich die 'Diagnostics' dahingehend verstehe, aber ich habe da so die eine oder andere Vermutung.)

 

[dyVinter]

2 hours ago, DataCollector said:

1, Frage meinst Du hier mit Festplatten die beiden betroffenen SSD oder wirklich an dem Poolcrash unbeteiligte Festplatten?

2. Frage: Was für ein Adapter?

3. Frage: Nutzt Du Powertop aus dem nerdpack?

 

(Sorry, ich bin noch zu neu, als dass ich die 'Diagnostics' dahingehend verstehe, aber ich habe da so die eine oder andere Vermutung.)

 

Quote

1, Frage meinst Du hier mit Festplatten die beiden betroffenen SSD oder wirklich an dem Poolcrash unbeteiligte Festplatten?

das Mainboard verfügt über 4 x SATA, den Rest habe ich gemischt (SSD und Array-Platten) über einen Adapter, Controller gelöst, insgesamt 8 Festplatten

 

Quote

2. Frage: Was für ein Adapter?

M.2 auf Sata3.0 Adapterkarte M.2 PCIE 16Gbps Sata 6G 5 Port

 

Quote

3. Frage: Nutzt Du Powertop aus dem nerdpack?

ich habe "NerdPack GUI" installiert

 

und da ist nur perl an

 

Edited July 2, 2022 by dyVinter

[mgutt]

7 minutes ago, dyVinter said:

M.2 auf Sata3.0 Adapterkarte M.2 PCIE 16Gbps Sata 6G 5 Port

Welcher Controller? Sollte bei Tools > System Devices zu sehen sein. Bei 5 Port könnte es ein JMB585 sein. Oder irgendein Marvel?!

[mgutt]

8 minutes ago, dyVinter said:

gemischt (SSD und Array-Platten) über einen Adapter,

Nenn mal bitte die Bezeichnungen (sdX, sdY..) von den Datenträgern, die alle an der Karte hängen.

 

[dyVinter]

1 hour ago, mgutt said:

Welcher Controller? Sollte bei Tools > System Devices zu sehen sein. Bei 5 Port könnte es ein JMB585 sein. Oder irgendein Marvel?!

ja, das ist ein JMB585

 

Quote

Nenn mal bitte die Bezeichnungen (sdX, sdY..) von den Datenträgern, die alle an der Karte hängen.

 

das sind die Bezeichnungen, die an der Karte hängen

 

 

 

ausgefallen aktuell

 

 

 

das sind die restlichen

 

 

 

warum ist die Bezeichnung von einer Platte anders, ist unbekannt!?

Edited July 2, 2022 by dyVinter

[dyVinter]

übrigens:

Quote

Also und den USB Stick klicken und in der unRAID OS Zeile "pcie_aspm=off" ergänzen wo ich hpet=disable stehen habe:

 

ich habe nach Deiner @mgutt Empfehlung Zeile "pcie_aspm=off" ergänzt, neu gestartet und jetzt ist nur eine SSD ausgefallen, vorher waren zwei

Edited July 2, 2022 by dyVinter

[DataCollector]

29 minutes ago, dyVinter said:

ja, das ist ein JMB585

das sind die Bezeichnungen, die an der Karte hängen

ausgefallen aktuell

Sollte das Problem noch bestehen: Ich würde die SSD des Pool/Cache exklusiv an den onboard SATA Kontroller hängen und alles weitere dem JMB585 überlassen.

 

[dyVinter]

59 minutes ago, DataCollector said:

Sollte das Problem noch bestehen: Ich würde die SSD des Pool/Cache exklusiv an den onboard SATA Kontroller hängen und alles weitere dem JMB585 überlassen.

 

danke für den Rat! 

Ich hoffe, dass dieses Problem nur die Cachefestplatten betrifft, wenn diese im Cache sind. Ich überlege die vier Cachplatten zu Array zuzufügen und für den Cache eine 1 TB NVMe Sata III zukaufen, ein NVMe Sata III Anschluss am Mainboard ist noch frei.

 

da habe ich noch ein paar Daten gefunden, ob die für das Problem relevant sind!?

 

 

 

Edited July 2, 2022 by dyVinter

[DataCollector]

32 minutes ago, dyVinter said:

Ich hoffe, dass dieses Problem nur die Cachefestplatten betrifft, wenn diese im Cache sind.

Ich nutze 4 Stück MX500 2TB als Extracache/Extrapool Raid0 an OnBoard SATA (siehe mein 1st System Signatur).

Das mache ich zwar erst seit Kurzem, aber bisher *klopf auf Holz* habe ich keine solchen Probleme.

(eher, daß zwei der MX500 Smartauffälligkeiten anzeigen, die kurz danach sofort weder verschwinden, aber das ist ein anders Thema.)

 

32 minutes ago, dyVinter said:

Ich überlege die vier Cachplatten zu Array zuzufügen und für den Cache eine 1 TB NVMe Sata III zukaufen, ein NVMe Sata III Anschluss am Mainboard ist noch frei.

Im Array wird kein Trim unterstützt. Du kannst die MX500 dort nutzen, aber es könnte Performanceverlust bedeuten.

Solltest Du im Array Parity nutzen, werden die SSD sowieso stark gebremst.

 

Zu der NVMe: Hier zeigt sich wieder, daß ich in den Diagnostics nicht firm bin.

Ich habe darin noch nicht gefunden welches Mainboard Du hast/hier für unraid nutzt.

Deshalb nur generell:

Entweder NVME (das ist dann PCIe) oder SATA III.

Es gibt auf Mainboards zwar M.2 Kombinationsslots, die beides aufnehmen können, aber eine M.2 SATA SSD zu kaufen macht keinen Sinn (sofern kan sie nicht für extreeeeeeeeem wenig Geld nachgeworfen bekommt). Auch bedeutet die benutzung von SATA M.2 SSD in solchen Slots oft, daß OnBord SATA ports abgeschaltet werden.

Auch deshalb stimme ich mgutt zu: Ja, eine NVMe SSD ist flott und gut als Cache (auch für Docker etc...) nutzbar.

Er empfiehlt bei NVMe gerne die Samsung 970 Evo plus, weil die wohl im Gegensatz zu einigen unrühmlichen anderen Varianten weniger Probleme in unraid verursachen.

Da ich in unraid nur diese Type (970 Evo Plus in 2TB Variante) oder eine alte 960 einsetze kann ich im Detail nur dafür sprechen: gute SSD, aber alle meine 970 Evo Plus werden unter last sehr warm.

Zwar alles noch innerhalb der erlaubten max. Temperatur doch mich stören die Warnungen, wenn 70+ Grad erreicht werden (ja, die kann man anpassen/abstellen). Da SSD bei steigenden/zu hohen Temperaturen ihre Geschwindigkeit drosseln und sich somit selbst vor Zerstörung schützen ist das alles kein Beinbruch. Ich packe da lieber noch M.2 Kühlkörper drauf, die dann in einem Luftstrom die Wärme reduzieren helfen um länger die Performance zu halten. Das ist aber Ansichtssache.

 

32 minutes ago, dyVinter said:

da habe ich noch ein paar Daten gefunden, ob die für das Problem relevant sind!?

Zum Bild des JMB Kontrollers:

Die technischen Eckwerte des JMB585 sind bekannt, bzw. sind leicht zu recherchieren. Grundlegend ist das ein gut brauchbarer Kontroller für unraid.

Deswegen auch die Frage(n) nach Powertop, weil bei mir Powertop vor kurzem alles durcheinander gebracht hat und auch Datenträger ausgestiegen sind.

alles sah mir aus, als wenn die Kontroller oder Festplatten da Probleme hatten, aber anscheinend hatte Powertop die einfach nur durcheinander gebracht, was dennoch zu ähnlichen Symptomen führte, wie bei Dir. Aber ich nutze ASM basierte Karten in meinem betroffenen System.

Aber powertop scheinst Du ja nicht zu nutzen.

 

Zum Bild des Intel ICH (Intel Controller Hub = OnBoard Schnittstellen):

Auch keine Überraschung. In der Regel sollten die OnBoard Schnittstellen die zuverlässigsten sein.

(Ausnahme: bei dem alten Chipsatz Sandy Bridge gab es SATA 3.0 Ports die mit der Zeit ausfielen. Aber das ist ja nun doch schon eien Dekande her.)

 

Zu dem Bild der Disk Log Info:

Schön zu sehen ist dort

14:44:40 Uhr: SATA link down (Ich interpretiere es als Info, daß (aus unbekanntem Grund) die SATA Verbindung abgebrochen ist).

:42 Uhr Detaching = abgekoppelt

:45 Danach wird die Schnittstellengeschwindigkeit auf SATA 1 (1,5GBit/s) reduziert

:46 und Überraschung auf einmal reden SSD und Kontroller wieder miteinander

:47 Und hier (gelbe meldung) wird es komisch. Es erkennt. dass es das device doppelt zu geben scheint (einmal mutmaßlich emuliert durch Cache Raid) und einmal real die nun wieder erreichbare SSD.

Da das System damit nichts anzufangen weiß wird die SSD dann wohl den UD zugeordnet, die sich ja alle Datenträger greifen, die vorhanden sind, aber nirgens in Benutzung/Zuordnung.

 

Es sieht also sehr danach aus, dass irgendetwas in der Kommunikation zwischen Kontroller und SSD nicht stabil ist.

Beachtenswert ist auch, daß die Probleme fast nach genau 5 Minuten anfangen.

   14:39:51 sieht alles noch gut aus...
   14:44:40 Es geht los

Das klingt für mich irgendwie nach einem Stromspartimeout oder so.

Aber da der JMB585 kein UEFI/BIOS hat, in dem man simpel etwas einstellen kann, bleibt eben nur zu schauen ob da eben irgendeien andere Maßnahme rein funkt (und da wäre ich wieder bei Powertop oder diversen anderen Stromsparideen, die man im Forum und Youtube finden kann).

 

Andere Ideen:

Werden die SSDs oder der JMB585 vielleicht zu heiß?

Oder sind die Kabel miserabel/zu alt?

Das sie wieder miteinander reden, sobald die Linkgeschwindigkeit auf das Minimum (SATA 1 = 1,5GBit/s) abgesenkt wird (und somit die Leistung etwas abnimmt) könnte entweder etwas mit der Temperatur oder gar überforderten/schlechten Kabeln zu tun haben.

 

Auf lange Sicht bleibt Dir wohl nur Stück für Stück zu verändern, bis das System wieder stabil ist und damit den Fehler einzugrenzen.

 

In jedem Fall: Backups Deiner relevanten/wichtigen Daten anfertigen.

 

[jj1987]

1 hour ago, DataCollector said:

(eher, daß zwei der MX500 Smartauffälligkeiten anzeigen, die kurz danach sofort weder verschwinden, aber das ist ein anders Thema.)

Das ist ein bekanntes Problem. Habe ich mit meinen mx500 auch und irgendwer hier im Forum hat noch davon berichtet.

[dyVinter]

20 hours ago, DataCollector said:

Ich nutze 4 Stück MX500 2TB als Extracache/Extrapool Raid0 an OnBoard SATA (siehe mein 1st System Signatur).

Das mache ich zwar erst seit Kurzem, aber bisher *klopf auf Holz* habe ich keine solchen Probleme.

(eher, daß zwei der MX500 Smartauffälligkeiten anzeigen, die kurz danach sofort weder verschwinden, aber das ist ein anders Thema.)

 

Im Array wird kein Trim unterstützt. Du kannst die MX500 dort nutzen, aber es könnte Performanceverlust bedeuten.

Solltest Du im Array Parity nutzen, werden die SSD sowieso stark gebremst.

 

Zu der NVMe: Hier zeigt sich wieder, daß ich in den Diagnostics nicht firm bin.

Ich habe darin noch nicht gefunden welches Mainboard Du hast/hier für unraid nutzt.

Deshalb nur generell:

Entweder NVME (das ist dann PCIe) oder SATA III.

Es gibt auf Mainboards zwar M.2 Kombinationsslots, die beides aufnehmen können, aber eine M.2 SATA SSD zu kaufen macht keinen Sinn (sofern kan sie nicht für extreeeeeeeeem wenig Geld nachgeworfen bekommt). Auch bedeutet die benutzung von SATA M.2 SSD in solchen Slots oft, daß OnBord SATA ports abgeschaltet werden.

Auch deshalb stimme ich mgutt zu: Ja, eine NVMe SSD ist flott und gut als Cache (auch für Docker etc...) nutzbar.

Er empfiehlt bei NVMe gerne die Samsung 970 Evo plus, weil die wohl im Gegensatz zu einigen unrühmlichen anderen Varianten weniger Probleme in unraid verursachen.

Da ich in unraid nur diese Type (970 Evo Plus in 2TB Variante) oder eine alte 960 einsetze kann ich im Detail nur dafür sprechen: gute SSD, aber alle meine 970 Evo Plus werden unter last sehr warm.

Zwar alles noch innerhalb der erlaubten max. Temperatur doch mich stören die Warnungen, wenn 70+ Grad erreicht werden (ja, die kann man anpassen/abstellen). Da SSD bei steigenden/zu hohen Temperaturen ihre Geschwindigkeit drosseln und sich somit selbst vor Zerstörung schützen ist das alles kein Beinbruch. Ich packe da lieber noch M.2 Kühlkörper drauf, die dann in einem Luftstrom die Wärme reduzieren helfen um länger die Performance zu halten. Das ist aber Ansichtssache.

 

Zum Bild des JMB Kontrollers:

Die technischen Eckwerte des JMB585 sind bekannt, bzw. sind leicht zu recherchieren. Grundlegend ist das ein gut brauchbarer Kontroller für unraid.

Deswegen auch die Frage(n) nach Powertop, weil bei mir Powertop vor kurzem alles durcheinander gebracht hat und auch Datenträger ausgestiegen sind.

alles sah mir aus, als wenn die Kontroller oder Festplatten da Probleme hatten, aber anscheinend hatte Powertop die einfach nur durcheinander gebracht, was dennoch zu ähnlichen Symptomen führte, wie bei Dir. Aber ich nutze ASM basierte Karten in meinem betroffenen System.

Aber powertop scheinst Du ja nicht zu nutzen.

 

Zum Bild des Intel ICH (Intel Controller Hub = OnBoard Schnittstellen):

Auch keine Überraschung. In der Regel sollten die OnBoard Schnittstellen die zuverlässigsten sein.

(Ausnahme: bei dem alten Chipsatz Sandy Bridge gab es SATA 3.0 Ports die mit der Zeit ausfielen. Aber das ist ja nun doch schon eien Dekande her.)

 

Zu dem Bild der Disk Log Info:

Schön zu sehen ist dort

14:44:40 Uhr: SATA link down (Ich interpretiere es als Info, daß (aus unbekanntem Grund) die SATA Verbindung abgebrochen ist).

:42 Uhr Detaching = abgekoppelt

:45 Danach wird die Schnittstellengeschwindigkeit auf SATA 1 (1,5GBit/s) reduziert

:46 und Überraschung auf einmal reden SSD und Kontroller wieder miteinander

:47 Und hier (gelbe meldung) wird es komisch. Es erkennt. dass es das device doppelt zu geben scheint (einmal mutmaßlich emuliert durch Cache Raid) und einmal real die nun wieder erreichbare SSD.

Da das System damit nichts anzufangen weiß wird die SSD dann wohl den UD zugeordnet, die sich ja alle Datenträger greifen, die vorhanden sind, aber nirgens in Benutzung/Zuordnung.

 

Es sieht also sehr danach aus, dass irgendetwas in der Kommunikation zwischen Kontroller und SSD nicht stabil ist.

Beachtenswert ist auch, daß die Probleme fast nach genau 5 Minuten anfangen.

   14:39:51 sieht alles noch gut aus...
   14:44:40 Es geht los

Das klingt für mich irgendwie nach einem Stromspartimeout oder so.

Aber da der JMB585 kein UEFI/BIOS hat, in dem man simpel etwas einstellen kann, bleibt eben nur zu schauen ob da eben irgendeien andere Maßnahme rein funkt (und da wäre ich wieder bei Powertop oder diversen anderen Stromsparideen, die man im Forum und Youtube finden kann).

 

Andere Ideen:

Werden die SSDs oder der JMB585 vielleicht zu heiß?

Oder sind die Kabel miserabel/zu alt?

Das sie wieder miteinander reden, sobald die Linkgeschwindigkeit auf das Minimum (SATA 1 = 1,5GBit/s) abgesenkt wird (und somit die Leistung etwas abnimmt) könnte entweder etwas mit der Temperatur oder gar überforderten/schlechten Kabeln zu tun haben.

 

Auf lange Sicht bleibt Dir wohl nur Stück für Stück zu verändern, bis das System wieder stabil ist und damit den Fehler einzugrenzen.

 

In jedem Fall: Backups Deiner relevanten/wichtigen Daten anfertigen.

 

vielen Dank, sehr ausführlich!

Jetzt habe ich die MX500 direkt an das Mainboard angehängt, die anderen Platten an Adapter.

 

Das System startet ewig, wenn überhaupt, keine Ahnung was jetzt los ist, keine Verbindung zu WebGui, der Server ist per ssh erreichbar (Connection closed by 192.168.178.128 port 22). Wenn ich das WebGui erreiche, dann kann ich kein Array startet, gar nichts kann ich startet, auch Pool kann ich nicht löschen, obwohl die Platten nicht im Pool sind. 

 

Werden nur drei MX500 erkannt, obwohl im Gerätemanager alle 4x zusehen sind.

 

 

Wie kann ich alles zurücksetzen, das gesamte System, "neu Konfiguration" geht auch nicht.

Edited July 3, 2022 by dyVinter

[dyVinter]

System Diagnostik hatte ich machen können

serverds-diagnostics-20220703-1622.zip

Edited July 3, 2022 by dyVinter

[dyVinter]

On 7/2/2022 at 9:25 PM, jj1987 said:

Das ist ein bekanntes Problem. Habe ich mit meinen mx500 auch und irgendwer hier im Forum hat noch davon berichtet.

interessant, Danke für die Info, kannst Du bitte einen Link auf den Bericht posten, habe ich auf die Schnelle bei Dir nicht gefunden.

Danke!

[jj1987]

39 minutes ago, dyVinter said:

interessant, Danke für die Info, kannst Du bitte einen Link auf den Bericht posten, habe ich auf die Schnelle bei Dir nicht gefunden.

Danke!

Siehe zum Beispiel in diesem Thread:

 

Geht explizit um Attribut 197 und idR kommt dann nach ein paar Minuten auch wieder ein "returned to normal"