DataCollector

Hier verweise ich mal wieder auf meine Tests mit dem Gigabyte B760M DS3H DDR4 und dem darauf befindlichen I3-12100 (oder dem aktuell preislich sehr naheliegendem I3-14100). Zum Mainboard: Wenn es mehr SATA Ports sein sollen wurde hier das ASRock Z690 PG Riptide (90-MXBHQ0-A0UAYZ) auch gut gemessen (auch wenn man da im BIOS/UEFI ziemlich tricksen muß). Auch da wäre eine I3 der nächste Schritt, wenn man die N100 als Anfangspunkt sieht.

Es ist schon etwas "besonderes". Die Speichermodule sind so 'besonders' das der Hersteller meint es sei cool die unter einem Blechdeckel zu verstecken, damit man nicht sieht, was da wirklich drunter ist. Und falls man denkt das wäre zum kühlen wichtig: Speichermodule die in diesem normalbetrieb Kühlung brauchen sind nicht okay, denn normale SPD RAM Module die nicht den Aufpreis für ihre "Coolness" haben,. schaffen problemlos DDR4-3200 CCL22 ohne Blechdeckel beizubehalten. ...und Du hoffst, daß die nicht intern rumregeln und sich an die Angaben im BIOS/UEFI halten. Hast Du 2 Speichermodule oder dar 4 Module (also 2 Kits) eingesetzt? Achja Di rist bewußt, daß eine Vollbestückung und auch die ungünstige Positionierung der Ram Module (in die falschen Sockel) den Takt negativ beeinflussen? Wenn es nur 2 Module gesamt sind: Hast Du die nach Angaben im Handbuch in die letzten Sockel der Verbindungsleitungen gesetzt oder in die Slots die näher zur CPU sind?

Crucial Pro 64GB DDR4-3200 (Crucial Pro): https://geizhals.de/crucial-pro-dimm-kit-64gb-cp2k32g4dfra32a-a2950989.html Übertragung 3200MT/s (3200MHz effektiv - abgeleitet von 1600MHz I/O-Takt mit Double Data Rate) Speichertakt 400MHz (intern) Module 2x 32GB JEDEC PC4-25600U Ranks/Bänke dual rank, x8 CAS Latency CL 22 (entspricht ~13.75ns) Row-to-Column Delay tRCD 22 (entspricht ~13.75ns) Row Precharge Time tRP 22 (entspricht ~13.75ns) Spannung 1.2V Und natürich musste es ja unbedingt Blechdeckel/Overclocker RAM anstatt normalem SPD RAM sein. 😭

Warum? Willst Du das System so oft neu starten, daß die paar Extra Sekunden wirklich ins Gewicht fallen? Ein normales Nas läuft eigentlich 24/7 und bootet selten. Aber wenn du entsprechendes suchst: schau ins BIOS/UEFI, da nur dort das Verhalten bei einem Kaltstart einstellbar sein dürfte.

Wie Timmey85 schon schrieb: Overkill. Wieviele SATA und so brauchst Du denn? Für unraid: keine Blechdeckel/Overclocker Ram, keine XMP Ram, DDR4 ist weniger knapop auf Kante entwickelt und wenn es um langzeitige Stabilität geht eher meine Wahl. Standard SPD Module 32 GB pro Modul DDR4 32300 sollten reichen. Du schreibst, daß es auch ein paar Jahre ohne weiteres Upgrade gehen soll: dann vielleicht 2 oder 4TB NVMe SSD. Dann ist mehr Luft nach oben, wenn Du wirkllich 5 oder mehr Jahre ohne Upgrade leben willst. 335 Euro/Stück bei 16TB ist mir weeeeeit zu teuer. https://geizhals.de/?cat=hde7s&xf=1080_SATA+6Gb%2Fs~13810_16000~8457_non-SMR Wenn es 16TB sein soll: Toshiba Cloud-Scale Capacity MG09ACA 16TB, 24/7, 512e / 3.5" / SATA 6Gb/s MG09ACA16TE für rund 220 Euro/Stück wenn es ungefär so teuer sein soll: Toshiba Cloud-Scale Capacity MG10ACA 20TB, 24/7, 512e / 3.5" / SATA 6Gb/s MG10ACA20TE für rund 330 Euro/Stück 2x SATA: Dann reicht ein erwähntes N100 wirklich (je nachdem, was Du als Spielereien bezeichnest) ASRock N100M war meine Wahl. Wenn es also doch upgrades geben darf: dann ASM1166 rein. jedes beliebige, was mATX Boards und ATX Netzteile beherrscht und die gewünschet Anzahl von 3,5inch Festplatten fasst. bequiet BN341 (550W) Und bei allem (auch den Festplatten) greifst Du sehr weit oben ins Preisregal ohne, daß ich den Bedarf sehe. DDR5 ist sehr neu (wenige Jahre) und teilweise so hochgezüchtet, daß die Hersteller den Modulen wenig über den Weg trauen und ECC on Die entwickelt mussten. Damit verlassen die sich nicht darauf, daß die DDR5 Chips so gut sind, sondern versuchen deren mögliche Fehler durch ein weiter entwickeltes ECC zu kaschieren/beheben. Für ein System, bei dem es um Stabilität und langzeitigen Betrieb geht ist das vielleicht nicht die beste Idee, vor allem, wenn das System weder diesen höheren Energiebedarf & Takt/Leistung braucht. Welche Anwendung, denkst Du, in einem NAS braucht eine so hohen Ram Takt, das man zu DDR5 greifen muß weil es mehr als Standard DDR4-3200 SPD Module bietet? Wenn es um eine Gamingmaschine geht, klar: DDR5 so hoch gezüchtet wie möglich und dazu eine fette Grafikkarte mit viel noch flotterem Ram. Wenn es um einen Numbercruncher mit wirklich wichtigen Berechnungen geht: Workstation mit viel flottem Ram und der so sicher wie Möglich (jedes ECC das geht) da rein. Aber wir reden bisher von einem NAS bei dem ein flotter RAM oder eine flotte CPU eben viele Takte länger die Däumchen dreht bis die paar Bits per 1GbLan oder so hereintröpfeln. Mit DDR5 drehen die Festplatten nicht schneller, bewegen sich schnarchlangsamen Bits nicht schneller über die LAN Schnittstelle, nur hat die CPU eben viel mehr Taktzyklen in denen sie .... /Trommelwirbel/..... auch genau absolut NICHTS tut. Auch ist DDR5 (aktuell) in aller Regel teuerer. Also: Warum DDR5? Welchen Nutzen bringt es hier für eun unraid, welches eben nicht mal viel/anspruchsvolles per VM zu machen scheint? Wenn Du ein Board mit mindestens 2 Ramslots nimmst und nicht irgendwann aufrüsten willst (wie es initial mal die Absicht war) dann gleich 2x32GB. Aber notwnedig ist das nicht. Das N100 beherrscht nur 1 Modul, aber bei den bisherig erkennbaren Anwendungen reicht das vollkomemn aus. Ich sehe nicht, daß dies "oft" vorgeschlagen wird. Frag die, die es vorgeschlagen haben. Absoluter Overkill für den bisher zu erkennenden Anwendungszweck. DDR4 Ram passt nicht zu DDR5 Board und umgekehrt, aber ansonsten. kann passen. Würde ich aber (abgesehen von den Nvme SSDs) nichts davon wählen.

Festplatten ("rotierendes Eisen") mit zfs im Array ist keine wirklich zu begrüßende Idee. Wenn damit das Array gemeint ist: xfs. 1. zfs ist kontraproduktiv, wenn es spindon sein soll. 2. Ich gehe davon aus, daß die Festplatten ins Array sollen. 3. Permanent spindown bedeutet, die laufen nie, somit brauchst Du die nicht. Ausbauen und ins Regal legen spart am meisten Strom vermutlich meinst Du damit SATA SSD. Leider ist unbekannt wie flott die sind, denn bei 10GbLan wird schon eien Schreibgeschwindigkeit von rund 1GByte/s erreicht und das ist mehr als SATA bieten kann. gerade eher selten genutze Isos fühlen sich auch auf Festplatten oder gar im Array wohl. Aber das ist meine persönliche Meinung. Grundsätzlich ist es aber nicht schlecht die 4 Systemshares (auch isos) auf einen Pool zu legen. Dafür sind NVMe SSD gut geeignet. Einen Lese-cache im Pool bietet unraid nicht. Als Schreibcache, bei dem es nicht auf Geschwindigkeit ankommt sind die SATA SSDs geeignet. Wenn Du unbedingt Deine 10GbLan in den Cache schreibenw illst bieten sich eher nur die NVMe SSD an, wenn sie mindestens 1GByte/s schreiben können (leider hatte ich vor kurzem das Pech eine Samsung NVMe OEM SSD zu bekommen, die sequentiell schreibend zwischen 80 und 21 MByte/ rumdümpelte. Die ist sofort wieder retour gegangen). Was meinst du damit und was soll daran anders sein, als bei dem HDD Cache oben? Unraid bietet keinen solchen extra Lesecache. Das musst Du Dir mit Scripten/Apps evtl. selber basteln oder die Ordner exklusiv auf dem SD Pool lagern (und ggf. per Script ab und zu Backups ins Array legen). Ich nutze die Dynamix App Cache Dirs. Bei Single Disks/SSD (auch Array): xfs Bei einem Verbund (raid) im Pool: zfs. zfs im Array oder bei Single Disks ist nicht wirklich die beste Idee und bringt weder aus Sicht des Stromsparens, noch aus Sicht der Datensicherheit einen wirklichen Pluspunkt. Wie oft möchtest Du das noch wiederholen und was machst Du überhaupt mit der 10GbLan? Erstelle Dir einen Pool mit xfs mit einer maximal großen & flotten NVMe SSD für das, was Du ins Array schreibend cachen willst (vermutlich eingehend über Deine 10GbLan). Erstelle Dir einen zweiten Pool mit xfs mit einer akzeptabel flotten NVMe SSD für das, was Du in den Docker/VM machen willst. Die restlichen unbenutzen Datenträger kannst Du rausnehemen. Das spart Strom. Lesend: gar nicht. Schreibend: unraid schreibt in den Pool mit der SSD und wenn der Mover zeitgesteuert anläuft verschiebt wer das ins Array (das dann dafür nicht mehr im Spindown bleiben kann). kein zfs bei Einzeldisks, kein zfs im Array 1 Array mit Festplatten (drehendes Eisen) 1 Pool mit NVMe SSD Schreibcache 1 Pool mit NVMe SSD Cache für Docker/app Ja, bei Einzeldisks nutze kein zfs Ja, bei Verbund (Raid im pool) nutze kein btrfs, dann bleibt nur zfs. Die Stellen, die mit dem 10GbLan beschrieben werden bevorzugt mit flotten SSD versehen. Da sich die Fragen irgendwie so anhören, als hättest Du es noch nicht getan: Lies die Dokumentation zu unraid.

Da hier unspezifisch gesucht werden muß: (fast) alle. Und auch dann ist kein Erfolg/Lösung garantiert.

Gibt es denn noch eine Disk3? Würde es vielleicht helfen auf einer Disk 3 dieses Verzeichnis einfach anzulegen? Mit Löschen meinte ich nict das Verzeichnis selber, sondern die zugehörende cfg Datei auf dem USB Stick. (/config/shares/ ordnername.cfg) Mit Löschen meinte ich nict das Verzeichnis selber, sondern die zugehörende cfg Datei auf dem USB Stick. (/config/shares/ ordnername.cfg)

iGPU Multimonitor würde ich eher so deuten, dass die iGPU eben mehrere Monitore/Aushänge gleichzeitig ansprechen kann und nicht nur Einen exklusiv.

Ist Dir entgangen, das es da Einschränkungen hat? "In RAID 0 mit Desktop SSHDs beträgt die Lesegeschwindikgkeit bis zu 410 MB/s (max.) und die Schreibgeschwindigkeit 400 MB/s (max.)." Du verwendest bei unraid weder Raid0 noch sind die Ironwoilf SSHDs (also nicht Flashbeschleunigt). Nur hat genau dieses Terramaster kein solches 3.1 mit 10GB/s. Erstens ist die Einheit GB nciht passend, es wären Gb oder GBit und andererseits sind es nicht 10, sondern 5: https://geizhals.de/terramaster-d5-300c-a1653801.html Anschlüsse extern: 1x USB-C 3.0 (5Gb/s) Zusätzlich ist dieses TerraMaster D5-300C nicht mal ein reines JBOD Gehäuse, da es versucht ein Hybrid zu sein: https://www.terra-master.com/de/d5-300c.html "Der D5-300C bietet 2+3 RAID-Speicher. Dies bedeutet, dass Festplatte 1 und Festplatte 2 als RAID 0, RAID 1 oder Single Disk konfiguriert werden können, um Ihre wichtigsten Daten zu sichern." "Superschnell mit USB 3.0 TransportProtocol! Das D5-300C verwendet USB 3.0 5 GB SUPERSPEED Protocol. In RAID 0 mit Desktop SSHDs beträgt die Lesegeschwindikgkeit bis zu 410 MB/s (max.) und die Schreibgeschwindigkeit 400 MB/s (max.)." Also müssen alle Daten durch einen Hybridchip (und schlimmstenfalls für den JBOD Teil noch durch einen USB Hub. 21,5 sind wirklich etwas schlapp, aber mehr als 50 MByte/s würde ich bei 2 Disks im 1P+1D Array in einem solchen USB Gehäuse nicht erwarten. Wenn Du die Disks als Raid0 konfigurierst wirst Du einen flotteren Betrieb erreichen (wenn Du KEINE weiteren Disks in das Gehäuse steckst!!). Wenn sich da alles immer durch eine Leitung quetschen muss kommt es sich in die Quere. Je nachdem welchen Standard Dein TB hat udn welche Chips verbaut sind ist flotterer Betrieb möglich, aber ähnlich wie USB eine wackelige Angelegenheit. Piobiere es aus und reduziere die Nutzung von TB durch andere Komponenten (kein Display, Lan, oder so durch den selben TB Chip.).

Irgendwie fehlen mir Infos zum System. Wieviel Disks sind es denn jetzt? Kann man ggf. temporär eine Disk 3 zubauen? Existiert denn ein so benanntes Share/Hauoptverzeichnis überhaupt noch (irgendwo)? Du schreibst, dass es auf Disk 3 nicht mehr ist, weil es die Disk3 nicht mehr gibt, aber ist es denn irgendwo? Ich habe es noch nicht ausprobiert, aber was passiert wenn Du bei herunter gefahrenem unraid von dem USB Stick im shares Verzeichnis einfach die zugehörende *.cfg Datei löschst und dann urnaid wieder hoch fährst? Dann sollte doch die komplette configuration dieses shares verschwunden sein, so daß Du die von Hand neu ein stellen kannst. Oder? (Ich würde aber vorher ein Backup des Sticks und der Daten in dem Verzeichnis machen.)

Hast Du noch einmal (also in Summe 2 mal) neu gestartet? Starten sie wieder, wenn Du auf 7.0.0 zurück gehst? Ist Dein USB Stick read only? Hat sich bei dem Pool, den der Docker vermutlich nutzt etwas dahingehend verändert? Hast Du das Changelog gelesen? Könnte Dein unbenannter Docker/Container etwas mit den dort erwähnten Veränderunegn für Docker zu tun haben? "As of this release, starting such containers has been disabled. To proceed, disable the Tailscale integration for containers in Host mode or change the Network Type to Bridge or "Custom: eth0/bond0/br0.""

Falls man genauer nachlesen will, was die CPU so kann/hat: https://www.intel.com/content/www/us/en/products/sku/226265/intel-pentium-gold-processor-8505-8m-cache-up-to-4-40-ghz-with-ipu/specifications.html

idle 30-3W with 4 Harddisks + 3 SSD. To me it looks like very much power for only idle and only this few devices.

Nein. ich meine die Anwendung powertop, welche mit dem aufruf "powertop --auto-tune" gerne verwendet wird, wenn man Strom sparen will. Wenn man sich die notwendige Datei nicht selbst aus dem Netz ziehen und an die richtige Stelle einkopieren wollte, hat man die in der Vergangenheit mit der Nerd App schön einfach installieren können. okay, jetzt weiß ich, warum schon der vorherige Verbrauch so hoch war: AMD 😉 Aber warum er nun noch höher ist, kann ich nicht sagen. Auch nicht so ganz das, was unter unraid gedacht ist. aber wenn sich da nichts verändert hat sollte das auch nicht den Mehrverbrauch verursacht haben. Hast Du unraid zfs laufen und vielleicht mit V7 in das neue zfs Format gewandelt?

Bezogen auf V7: ja, richtig. Wenn die Pools aber > 1 Disk sein sollen wird es eine Art Raid und schon laufen in dem Pool alle Datenträger. Der Vorteil des Array ist ja (für viele Nutzer) die Energieersparnis, weil nur die benötigten Disks laufen. Wenn ich mein Array mit 24+2 Festplatten als Pool betreibe bleibt nur Raid6 und dann sind im Betrieb schon mal ein paar hundert Watt mehr drin, als bei einem schlafenden Array. Diesen Wunsch hatte ich schon mehrfach geäußert und bei dem Feature Voting auch gepusht, aber bisher ist das nicht der Fall.

Ich glaube ich erwähnte schon mal, daß ich genau aus dem Grund einen 4TB großen NVMe SSD Cache nutze. Den kann ich dann per 10GbLan befüllen (des öfteren so 2-3,5TB in einem Durchgang) und dann kann der gemütlich geleert werden. Vorher hatte ich ich sogar meinen 4x2TB Raid5 SSD Cache (6TB) und einen 3x8TB raid5 SSD Cache (16TB). Wenn der Cache zu klein ist: größeren konfigurieren. Ist natürlich auch eine farge des Geldes und der noch freien Anschlüsse. Das geht, wenn man das Array mit new config auflöst und (ohne Parity) dann neu zusammenstellt. Natürlich hat man dann in der Zeit keine Ausfallsicherheit im Array. Sollte das öfters vorkommen ist vielleicht ein größerer Cache doch ratsam. Alternativ gleich ganz auf die Parity verzichten, wenn einem die nicht wichtig ist. Bei einer so großen Initialbefüllung kopiere ich ins Array und erzeuge die Parity später. Wenn es im laufenden betrieb später zusätzlich 30TB ins Array sein sollen muß man eben ausreichend großemn Cache verwenden. Ich würde dem Syetm einen groß genugen temporäten Zwischenspeicher verpassen (QNAP TR-004 mit 3x18TB Raid5 bestücken und per USB anschließen oder einfach 2x18TB Rals Raid0 in einem Pool stecken und konfigurieren), dann von der 30TB Quelle (PC per SMB?) in den temp Zwischenspeicher kopieren. Dann kann die Quelle wieder abgeschakltet werden/etwas anderes tun/etc... Und unraid wird dann angewiesen den Inhalt des temp Zwischenspeichers ins Array zu verschieben. In meinem großen System möchte ich meien Parity nicht "zwischendurch" abschalten, weil dann mehr als das 10fache der aufzukopierenden Datenmenge nicht mehr ausfallgesichert wäre.

Ich habe meines seit rudn 1 Woche auch aktiv im Betrieb (um 2 Notebooks bequem zu testen). Ich habe zwar leichte Probleme mit der Bildschirmauflösung, aber für so einen Notbetrieb ist es super. Wenn ich im Netz richtig gesucht habe sollte man sich aber überlegen besser kein Firmwareupdate durechzuführen, einige haben sich damit das Ding gebrickt., Leider läuft mein Checksummenlauf noch, somit kommte ich noch keine Screenshots zum Adaptec machen um sie vergleichen zu können.

70-80 MByte/s schreibend entspricht einem normalen Festpllatten Array mit 1 oder 2 Parityfestplatten.

Wenn Parity mit läuft ist der langsam. Schließlich muß er dann einmal die Daten auf die neue Disk schreiben und die Parity aktualisieren und dann von der Quelle löschen und die Parity aktualisieren. Ich weiß jetzt nicht wie der Dateimanager genau läuft aber da der mc bei sowas immer Häppchenweise (Datei- oder Verzeichnisweise) arbeitet kommen sich auf der parity die Operationen nicht so direkt in die Quere. Sollte der Dateimanager jede date einzeln kopieren und dann direkt verschieben, treffen sich die Lese- und Schreiboperationen bei der Parity und bremsen sich so (durch notwendige Kopfbewegungen) zusätzlich aus.

Das ist viel. Scheint ein großes System zu sein. Erst einmal schauen, wie es aussieht, wenn das System idle ist (alle VM+Docker aus). Ist der Verbrauch dann immer noch riesig, ist es ein problem in unraid. Ist der Verbrauch wieder niedrig, ist es einer der Docker/VM. Schuss ins Blaue: Da es die NerdTools für V7 nicht mehr gibt könnte es sein, daß die deinstalliert wurden und powertop oder so mitgerissen haben? Kann es sein, daß Du vorher powertop verwendet hast und das jetzt eben nicht mehr läuft?

Da das Array im Regelfall eine Parity hat würden sich alle Zugriffe aber wieder an der Parity "knubbeln" und gegenseitig noch mehr bremsen. Vermutlich deshalb ist sowas nicht implementiert. Selbst wenn man mit dem Mover gleichzeitig vom Pool auf 3 Disks beschreiben will, würden sich die Zugriffe in der Parity dann sogar noch mehr als nur um das 3 fache verlangsamen. Der Mover (zumindest vor V7) war ja nur gedacht zwischen Array und Pool zu verschieben. Von einer Disk zur Anderen im Array ist damit ja sowieso nicht angedacht gewesen. Das ist für einen Mover schon schnell. Entweder hast Du keine Parity im Array oder Du nutzt im Array SSDs. Bei normalen Festplatten mit Parity sind peak eher 85 MByte/s üblich.

Ich zumindets nicht. Vielleicht mal ein neues Sahre erstellen und da neu konfigurieren. Hast Du vielleicht eine Mover tuning App oder sao aktiv? Bei mir ist sowas bisher nicht aufgefallen. Text, Bild und auch gepackte Dateien werden bei mir ohne Probleme gemovt.

Schlimmstenfalls: anderen urnaidstick basteln (Testlizenz reicht ja), SSDs entfernen, mit dem Stick booten und optimieren (powertop...) und dann unraid komplett mit Array starten und Platten in Spindown schicken (wobei der Spinup/Spindown die C-States nicht beinflussen sollte). Auch das sollte nach ca. 20 Minuten zeigen ob mehr als C3 drin ist. Man muß ja nicht das laufende System mit dem aktuellen Stick verbiegen um nur diese Kleinigkeit festzustellen. Und da ich zu faul bin für kurze Tests die Set Befehle (ASPM Helper) zu nutzen, etc... warum nicht gleich mit 6.12.4 das mal kurz testen? Auf dem Weg hat man auch für den kurzen Test keine störenden VM oder Docker laufen und kann erahnen, was mit den aktuellen BIOS/UEFI Einstellungen möglich ist. Nachteil Mitd em Test verbennt man den USB STick füpr eien Unraid Lizenz. Aber irgendeinen alten Stick mit ID sollte man vielleicht ja noch rumliegen haben. urnaid ist klein und auch ein 1-2 GB Stick sollte für den Test reichen.

Deine Kriterien waren robust und flott und dann hast Du WD BLUE Modelle gewählt? 😮❓ Ich bin weiterhin der Meinung: sparsam und gut sind Samsung 970 Evo Plus (möglichst groß) und habe gute Erfahrungen mit AData Legend 960 4TB, Patriot Viper Lite VP4300l 4Tb und Lexar NM7790 4TB gemacht. Die Viper wird von denen am wenigsten Warm.