DataCollector

Ja, und genau das ist ja auch der Grund dem Array einen Pool mit SSD(s) vorzuschalten Die Parity bei einem Array mit mehr als 2 Festplatten bremst eben. Naja, Du bist mit 2 Paritydatenträgern sicher gegen den Ausfall von maximal 2 Datenträgern im Array. Wenn das die gesuchte (Ausfall)Sicherheit ist: ja. Gegen so gut wie (fast) alles andere was passieren kann bist Du damit nicht sicher. unraid selber kann BitRot nicht erkennen oder gar beheben. Es gibt ein FileIntegrity Plugin, welches ich aber nach Tests nicht mehr einsetze. Ich setze auf halbautomatisch (über ein Windowssystem) erzeugte Checksummen um in späteren Prüfläufen zu erkennen ob da etwas nicht mehr stimmt. Wenn es Dir das bringt, was Du willst: okay. Naja, "um jeden Preis" ist eine vielleicht doch sehr teure Sache. Aber dann wird es wohl Zeit für diverse gespiegelte Systeme auf der Welt.

Ist zwar eine Share Einstellung, aber ja, die wirkt sich auch auf die zugeordneten (bzw. nicht ausgeschlossenen) Disks aus. Ich gebe zu, ich verstehe die Frage nicht so ganz, aber die oben gemachte EInstellung betrifft nur das Array. Für Pools (SSDs) kannst (und solltest) Du extra nochmal einen Minimum free Space einstellen. Wenn Du Daten von außen beispielsweise per SMB hoch lädst hat ein Docker damit nichts zu tun. Wenn Du eine 300GB große Datei hoch lädst bekommst Du bei der Einstellung ein Problem. Der Minimun Free Space sollte immer größer sein, als die jemand zu schreibende Datei. Wenn Du hingegen viele kleinere Dateien hoch lädst, die in Summe 300GB haben, dann wird unraid so lange den Pool/SSD beschreiben, bis eben die 100GB unterschritten werden. die nächsten ganzen Dateien werden dann (wenn man de nicht irgendetwas falsch eingestellt hat) nicht mehr in den Pool, sondern in das Array direkt geschrieben. Plexeinstellungen sind nicht so mein Ding. Ich plexe nicht. Was Du in einem Plex Container einstellen kannst, weiß ich nicht. Das Docker Image ist immer nur auf einem Laufwerk. Man kann Docker auch nicht im Image, sondern in einem Verzeichnis laufen lassen, aber auch das liegt eigentlich auf einem Laufwerk (das aber vielleicht auch zum Teil von dem Pool in das Array rüber schwappen kann). Aber eigentlich ist es ja so, daß die Container für Docker sehr klein/schlank sind und somit der Dockerkrempel kaum Platz bedarf. Aber Du kannst den Containern (mit vielleicht 2 GB Platzbedarf) ja Zugriff auf diverse Shares geben, doe dann einige hundert TB groß sind. Und diese müssen ja auch nicht unbedingt Shares sein, die auf physikalische festplatten verweisen, sondern können auch auf physikalischen SSD liegen, die vielleicht permanent auf einem extra Pool liegen.

Was ist denn auf den SSDs/Pool drauf, was Du gemoved haben willst? Nutzdaten oder Systemshares?

Ich verstehe nicht, was das bewirken soll. Dein NAS läuft 24/7. Die Platten schlafen. Dein Mediaplayer will eine Datei abrufen die im Array auf den schlafenden Platten liegt. unraid erkennt das und weckt die notwendige Platte(n) selbstständig auf (Spinup Time 20-30 Sekunden). Was soll da noch zusätzlich ein WOL oder sonst etwas machen? Selbst wenn ein beliebiger PC/NAS mit schlafenden Festplatten da wäre und der komplett per WOL geweckst wird würde das auch nicht schneller sein, weil auch da die Festplatten hochdrehen müssen. Was ist der gedankliche Hintergrund, wenn ein Player auf einen 24/7 laufenden NAS mit Spindown Festplatten zugreift? Das NAS erkennt das ja sowieso (weil es ja läuft) und spinnt die Platten hoch. Der Player muß nur eben damit klar kommen, daß er mal ab und zu 20-30 Sekunden Wartezeit hat.

Naja, ich erwähnte mit Absicht auch den Preis, weil mir ca. 80 Euro für einen 16GB USB Stick dann doch zu teuer ist. 💸 💰 https://www.mouser.de/ProductDetail/Swissbit/SFU3016GC2AE2TO-I-GE-1AP-STD?qs=vmHwEFxEFR95u3MYVVd1Ag%3D%3D

Beachte, daß die Anleitung von 2022 und an einigen Stellen schon veraltete/überholt ist.

Heute üblicher Flashspeicher in USB Sticks ist eigentlich immer NAND. (Es gibt zar auch USB Sticks, die sich der Techniken von SSD bedienen, aber der Speicher selber ist eigentlich gleich, nur schneller oder wird verschachtelt (mehrere Module) angesprochen. https://de.transcend-info.com/embedded/product/embedded-flash-solutions/jetflash-280t "3k P/E" damit ist das wohl TLC Speicher (3Bit pro Zelle) den die mit "3D NAND" soweit verklausulieren, daß wohl nicht auffallen soll, wenn es eben doch einfach TLC sein dürfte. Da hat die Marketingabteilung und nicht die Techniker formuliert. Das ist nicht abwertend gemeint. Bei (nicht gerade den Billigsten Exemplaren von) USB Sticks sehe ich Transcend eigentlich als einen guten Hersteller an und das ist bestimmt ein guter USB Stick. https://www.kingston.com/de/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand MLC wird eigentlich mit ca. 3fach so hoher Lebensdauer als TLC angesehen (10k P/E). 3D NAND hat da nun wieder eine Verbesserung der Lebensdauer von einfachem TLC geschaffen, aber ob das dann wieder bei ca. 10k P/E ist kann ich nirgendwo sehen. Und ich befürchte (ohne es eben zu finden) daß es dann irgendwo zwischen TLC und MLC liegt. Selbst Transcend schreibt ja eben von 3k P/E. Leider gibt es auf dem Markt in den Preis-/Kapazitätsregionen (meines Wissens) keine SLC USB Sticks (mehr).

Transcend Jetflash 600 sollten wegen des verbauten MLCspeichers allgemein länger halten. Die Transcend JetFlash 780 sollen ebenfalls MLC haben, sind aber USB 3.0. Die kann man aber mit Kabelpeitsche, Y-Adapter oder eben an einem USB2.0 Port auch zu USB 2.0 überreden (was stromsparender ist).

Intenso - da muß man nicht mehr viel sagen. Hast wenigstens Glück, daß unraid sich darauf installieren läßt und Du nicht eine der Serien erwischt hast, die alle mit der selben Nummer versehen sind. Wenn dann ein Kunde damit unraid nutzt, werden alle anderen Sticks geblacklistet.

Interpretiere ich Deien Aussage richtig: Du liest ein großes Videofile vom Array und schreibst es gleichzeitid in einen Share des selben Array ohne, daß dieses Zielshare einen SSD Cache hat? Mit Turbowrite hast Du es zwar etwas beschleunigt, aber dennoch muß nun (schlimmstenfalls von der gleichen Festplatte) lesen und pufferst dann den Schreibvorgang nicht mit einem Pool/SSD ab. Das bremst eben. Mir erscheienn die unter 30MByte/s zwar auch eher gering, aber falls die festplatten schon gut gefüllt sind erreichen die selbst alleinig lesend nicht unbedingtt ihre Spitzenwerte von 280MByte/s, sondern eher 130 MByte/s (im langsamen Innenbereich). Dazu dann eben noch lesen und schreiben gleichzeitig mit ständiger Kopfneupositionierung. Ich würde an deiner Stelle schreibend einen flotten SSD cache zwischenschalten.

Mein System: https://forums.unraid.net/topic/120263-vorstellung-erster-unraid-server-4he-noch-kein-finaler-stand-erreicht/ BIOS Screenshots fertige ich voraussichtlich heute an, wenn ich wieder zuhause bin. (Mein Brötchengeber hat mich heute ins Büro gezwungen) EDIT: In der Datei sind Screenshot der BIOS Einstellungen meines Gigabyte W480 Vision W Rev1 Nicht wundern, unter den Peripherials ist ein MaxView Storage Controller zu sehen, das ist mein SAS Kontroller (ADAPTEC 72405-24i), der sich ins UEFI eingeklinkt hat. Davon habe ich keine Screenshots gemacht, da Du den vermutlich nicht drin hast. Und nur so: ich habe das BIOS/UEFI nicht sehr auf Stromsparen angepasst. Vieles ist noch auf Default, auch weil ich vor ca. 2 Jahren (als ich damit anfing) mich noch nicht wirklich mit Stromsparen beschäftigt hatte, da das System alleine schon weitaus sparsamer als meine Windowssysteme war und diese ersetzen sollte (was bis heute noch nicht so geklappt hat). Allein die ASPM Einstellungen waren vorhin alle noch auf Default. Habe die im Zuge dieser Screenshots anschließend aber nun auf enabled gestellt. Gigabyte-W480-Vision-W-Rev1.zip

Es hat ja auch seine Vorteile. Aber die erkauft man sich eben mit diesen kurzen Spikes. Die Software läuft eben und das benötigt elektrische Energie.

Ich übersetze mal "Videospeicher, Dokumentenspeicher und Zielort für Backups/Images" Das Ergebnis ist eigentlich eine Uunraid Standardkonfiguration: Ein paar Festplatten ins Array und eine oder 2 davon als Parity. Damit gerade stattfindende Schreiboperationen (Backuops) nicht zu lange dauern, eine flotte und große SSD (egal ob nun NVMe oder SATA) nehmen (1-2TB) und diese in einen Pool als Cache vor das Array legen. Die paar benannten Docker könnten zwar auch auf die selbe SSD, aber zur Sicherheit würde ich die auf eien extrs SSD legen (auch hier ist es egal ob NVMe oder SATA). Da Docker sehr klein sind, kannst Du da auch eine kleine SSD nehmen (250 oder 500GB sind okay). Dann stellst Du den mover so ein, daß er einmal in der Nacht anspringt und die Daten von dem Pool/Cache ins Array verschiebt. Solltest Du dann doch irgendwann auf 2,5GBLan gehen und somit Schreibgeschwindigkeiten um die 250-280MByte/s auftreten, sollte die SSD dann besser eine gute NVMe sein, weil die sowas dann auch noch gut abfangen kann. 10GBLan macht auch hier nicht wirklich Sinn und frißt nur unnötig Strom. Alles in Shares, die primär auf den Pool/Cache gehen und nachts per Mover ins Array gehen. Ausnahme 8wie schon mal angedeutet) solltest Du beispielsweise Deien Favoriten Musikfiles ab und zu abrufen wollen und Dich 20-30 Sekunden Anlaufzeit der Festplatten im Array stören, belasse diese auf einer SSD in einem Pool. Falls Du aktuell noch nicht weisst ob sowas relevant ist: nimm lieber eine großße SSD, dann hast Du die Freiheiten das später so zu machen. Mir reichen da Backups. Ausfallsicherheit im Rahmen von Raid im Pool ist für mich im privatbereich egal.

Wenn das System vorher intensiv getestet und bis dahin fehlerfrei war entstehen RAMfehler in den nächsten Jahren eher seeehr selten. Auszuschließen ist es nicht und es ist auch nicht auszuschliessen, daß diese Fehlerstelle lange unbemerkt bleibt, weil sie keinen Programmcode zum abstürzen bringt sondern wirklich ein Bit in den Nutzdaten verändert. Ich schätze das mal im 0,0...01 Prozentbereich eines vorher fehlerfrei getesteten Systemes ein. Sollte ein Bitfehler in einem Bild sein, wird es weniger "hopps" gehen, sonden ein Bit im Bild wird vielleicht nicht Blau 255 sondern vielleicht Blau 250 haben. Viel Erfolg!

Wenn man seine Daten liebt, sind Backups wichtig! Mehr als nur eine Generation! und die auch ab und zu auf korrekten Inhalt überprüfen. Vielleicht auch zusätzlich eine UPS, weil dann auch die Daten im Ram gegen Stromausfall gesichert werden können. ECC ist eher Glaubensfrage. Ja, in Firmenumgebungen oder wenn es einem wiiiiirklich wichtig ist ist ECC ein klitzekleines bisschen mehr Sicherheit gegen Bitfehler die sich in den Daten verschleppen. Aber das ist ein eher sehr selten auftretendes Problem. Brauchst Du die Datenmengen rein Firmentechnisch oder sind das nur eher weniger Daten. Bei Stromsparend (ohne ECC) ist Intel zu bevorzugen. Wobei ich aber nicht sagen kann ob AMD oder intel bei ECC nun stromsparender ist. Bei diversen AMD Systemen liest man aber immer wieder von Problemen, welche ich bei Intel weniger sehe. Ich würde auch bei ECC erst einmal zu Intel schielen. Dem Transcoder ist 1 oder 2,5GBlan egal. Wenn Du transcoden willst, wird gerne eine aktuelle iGPU von Intel genannt. ich plexe/transcode nicht. Ich komme mit hier im Forum eher zu Intel. Ich bin kein bezahlter IT ler (Profi). Ich bin langjähriger nicht profi in dem Bereich und sehe AMD als sehr gut für Desktop, Gaming, etc.... Im Serverbereich dieser preisklasse wirst Du mit aktueller neuwar ebei Intel nicht hinkommen. Also nimm das, was Du Dir rausgesucht hast und erzähle uns wie gut es läuft.