DataCollector

technisch: ja. Man nehme ein geeignetes Kabel und stecke es in die entsprechenden Buchsen der Geräte Unraid braucht in der Regel eine GPU und da ist dann eben auch die Bildschirmausgabe von unraid zu sehen (Bootablauf, Logon Anzeige etc...). Den urnaid Teil headfless zu betreiben ist eher tricky und nicht so vorgesehen. Du kannst aber weitere dGPUs einbauen und nutzen. Dann kannst Du eine der dGPU an die VM durchreichen und diese kann dann über deren Ausgang auf einem Bildschirm/TV angezeigt werden. Aber das geht zu Lasten der Energieeffizienz. Docker direkt auf Bildschirm anzeigen - keine Ahnung. auf die Idee bin ich noch nicht gekommen. Alle (von mir benutzen) Docker lasen sich per VNC oder Webzugriff anzeigen. Wenn Dein TV sowas beherrscht oder Du einen TinyPC/Notebook oder zu zur Bedienung nimmst, dann können die ja an das TV weiter geben. Nicht wirklich. Man kann ein ganzes Speicherdevice (PCIe) in eine VM durchreichen, aber das ist dann exklusiv. dann kann da nichts anderes darauf zugreifen. Eine VM läuft eigentlich in einer vDisk. DIes ist eine einstellbarere große Datei. Die läuft auf einem Datenträger. Wieso reicht Dir diese Nutzung in einer VM nicht? Docker laufen eigentlich per Default in einer eigenen vDisk (per Default btrfs vdisk, ich bevorzuge xfs vdisk). Uahc das ist eine vorgegeben Datei. Die kann auf dem selben Datenträger liegen, wie eine vDisk einer VM. Damit ist die Benutzung der beiden Anwendungen VM & Docker auf ihre vDisks exklusiv getrennt. Warum reicht Dir das nicht? Wenn man es will, kann man für Docker anstatt einer vDisk auch eine Verzeichnisstruktur nehmen, aber dort sehe ich keinen Grund eine SSD anders zu teilen, als über shares. Was willst Du mit Deiner "Teilung" einer SD bezwecken? Die zeitlich gleichzeitigen Zugriffe auf den physikalisch selben Datenträger kommen sich schlimmstenfalls sowieso in die Quere, egal ob man eine SSD nun in 2 Teile partitioniert oder 2 Dateien nebeneinander auf der SSD liegen.

Ob Du 700 MByte/s konstant über mehrere TB Transfer hinweg mit dem 6TB Platten in einem zfs raid (Pool) hinbekommst wirst Du ausprobieren müssen. Dieses Qttier ist eien Unternehmenslösung, die optimalerweise mit mehreren Ebenen (cold, warm, hot) arbeitet und auch 3 sehr große (ich rede in allen 3 Bereichen von mehr als nur 10 TB oder so) unterschiedliche Speicherbereiche hat. Auch QTier kann nicht hellsehen und wissen, wenn Du sowieso 40TB jederzeit im direkten Zugriff brauchst, wie es das auf einem erheblich kleineren SSD Cache organisieren soll, so das der nächste Zugriff in die SSD und nicht in einen der anderen Bereiche gehen soll. QTier in der Form ist für Konstellationen im Serverbereiuch (professionell und größer) gedacht. Die trennen sogar die Bereiche auf SATA, SAS (und hier wird eher 10.000Rpm SAS auf 2,5inch Festplatten gemeint) und SSD auf. Sowas ist per default nicht in unraid drin und so nutzt unraid auch die Cache'nden SSDs nicht. Die SSDs, die man als Cache in einem Share nutzen kann, sind Schreibcaches. Du willst aber flott 40TB von Deinem Material lesen. Lesend wird da gar nichts optimiert. Das, was man schnell haben (lesen) will, muss man manuell auf eine SSD transferieren (oder sich ein pasendes Script oder so dafür basteln). Aber erstens redest Du von 10 Tagen zu je max 4TB, was bedeutet: wenn Du wirklich 40TB Daten im SSD Cache haben willst brauchst Du 40TB SSD Platz. Wie soll unraid vorher wissen/erraten. welche Datei Du von den 40TB als nächstes aufrufen willst um diese im Vorraus umzulagern? Und selbst, wenn Du aus 40TB nur eine 3TB große Datei als nächstes brauchst und Du es unraid irgendwie mittelst: um die fluffig in einer SSD vorzuhalten muss unraid die dann eben erst zeitaufwändig aus dem array/pool lesen und in die gewünschte SSD kopieren/verschieben. Der Vorgang wird auch nicht schneller gehen, weil es eben nur mit der maximalen Geschwindigkeit geht mit der die Hardware eben lädt/speichert. Diese Zeit wirst Du in jedem Fall investieren müssen, wenn es nach dem ersten lesen fluffiger (latenzärmer) werden soll. Ich würde abschließend sagen, es bleibt dabei: a) entweder Du weißt, welche kleinen Häppchen Du als nächstes bearbeitest und läßt die vorher auf eine/mehrere SSD kopieren, geht zwischenzeitlich einen Kaffee trinken und arbeitest dann das Häppchen mit geringerer Latenz ab. b) oder Du sorgt für genug SSD Kapazität um Deine ganzen 40TB auf SSD zu lagern (weil Du ja jederzeit alles im schnellen Zugriff brauchst) c) oder Du lebst damit, daß ein Festplattenverbund nicht ganz so fluffig (latenzarm) läuft wie eine SSD d) oder Du bleibst einfach bei Deinem aktuellen Konstrukt und rüstest das ggf. auf.

Ein Experiment mit 2. Partity und so: Also hier hege ich eher Zweifel. Die sichere Methode: mach/aktualisiere (mindestens) ein aktuelles Backup (falls etwas schief geht). Löse das Array mit new config auf. Ordne die alten Datenfestplatten einem neuen Array als Datenfestplatten zu und ordne die neue 20TB Festplatte dem selben Array als Parity zu. staret Array und lasse Parity auf der 20TB Festplatte (neu) erzeugen. Gleichzeitig kannst Du die alte 18TB Parity in unraid als UD Preclearen. Wenn Parity aufgebaut wurde und Preclear ohne Probleme durchgelaufen ist kannst Du Array stoppen und die geclearte (und dadurch vorbereitete) 18TB dem Array als zusätzliche Platte zufügen. Da Preclear die schon geeignet vorbereitet hat, wird sie in der Regel schnell jm Array zugefügt ohne dort neu genullt zu werden. Über new config das alte Array löschen, dann neu zusammenstellen und Parity neu erstellen. So kann man auch eine Festplatte mit Daten dem Array zufügen. Bei dem klassischen Wege (nur Array stoppen, neue Disk zufügen und dann Array starten) wird die neue Disk immer gelöscht, sofern sie nicht von Preclear schon gelöscht/vorbereitet wurde. Ich weiß nicht wann "damals" war und seit wann das Tool "new config" existiert, aber heute geht das eben über neues Zusammenstellen des Array.

700MBit/s = 87MByte/s. Dafür brauchts Du keinen Plattenstapel mit 10 Platten. Ich fasse zusammen: bis zu 4TB pro Drehtag, 10 Drehtage = 40TB. Benötigte Geschwindigkeit auf Quell- und Zieldatenträger rund 90MByte/s Vorhanden sind 8x 6TB Festplatten. Das sollte also eigentlich dicke ausreichen. Wenn Du alle 8 Festplatten in einem Pool per zfs als äquivalent Raid0 oder Raid5 zusammenfasst hast Du diese Eckpunkte alle abgedeckt, aber es werden alle Festplatten bei Beanspruchung alle laufen ( maximaler Strombedarf auf Festplattenseite) lesend 90 MByte/s kann ein klassiches unraid Array aber auch abdecken, wenn man mit den ggf. bis zu 30 Sekunden Aufwachzeit pro schlafender Festplatte leben kann. Damit würde man einiges an Strom sparen., wenn man eben nicht alle 40TB immer in jeder Sekunde gleichzeitig im Zugriff braucht. Wenn Du lesend die Reaktionszeit von SSDs haben willst, musst Du das Material auch auf SSDs lagern. Das ist das, was ich bei meinem Workflow damit meinte mit "Deshalb (wenn ich absehen kann dass ich an einem Tag doch ein paar Dutzend Videos bearbeiten werde) landet das Quellmaterial bei mir erst auf einer guten 4TB NVMe SSD und dann bearbeite ich die Dateien und schreibe auf eine andere 4TB NVMe SSD." unraid kann leider nicht zaubern. Wenn es nicht weiß auf welche Dateien Du als nächstes zugreifen willst, kann es die nicht auf SSD vorhalten, damit Du einen fluffigen Workflow hast. Vor allem, wenn die SSDs nicht genug Platz haben die Dateien alle gleichzeitig vozuhalten. Und wenn Du SSDs als Schreibpuffer verwendest, kann unraid das in einem share zwar so einstellen, aber Du schreibst doch sowieso nur mit winzigen ca. 90 MByte/s, was eine einzige mechanische Festplatte heute problemlos abfangen kann (solange sie nicht gleichzeitig noch durch andere Prozesse belästigt wird). Ich befürchte, Du versprichst Dir von unraid einen Leistungszuwachs, den Du zumindest in dieem Anwendungsgeqbiet nicht erleben wirst. Vielleicht in naher Zukunft, wenn jemand den Stein der Weisenb gefunden hat und serienmäßig in unraid implementiert, aber aktuel sehe ich nicht, wie unraid Dir in dem Workflow irgendwie besser hilft, als dein bisheriges NAS. Unraid macht (wenn es nicht spinnt) genau das, was man man ihm sagt. Hellsehen und Wunder sind aber nicht Teil des Programmes.

Alle Parityfestplatten müßen mindestens so groß sein, wie die größte Datenfestplatte im Array. Wenn Du eine 18 und eine 20TB als Parity nutzt, hat El-Diablo recht: dann darf die größte Datenfestplatte eben nur max 18TB groß sein. zu der Frage: ja. Da Du die 18TB Parity nun verwirfst und eine 20TB als (aktuell einzige) Parity einsetzt, kannst Du die verworfenen 18TB Platte als Datenfestplatte im Array zufügen. Solltest Du irgendwann auf 2 Parity erweitern wollen, muß die 2.Parity dann aber eben auch mindestens so gross wie die größte Datenfestplatte sein.

Messungen zum Vergleich finden ohne Workload statt, weil die viel zu individuell ist. Und schon wird es individuell. Was soll denn darauf los sein? nur ein bisschen lesen oder auch schreiben, oder gleich Chia schürfen? Klar beeinflusst Workload auf der CPU die C-States der CPU. aber das ist nicht wirklich immer Schuld der PCIe Devices. Und da die Workload der SSD auch immer durch irgendwie durch den RAM (in der CPU gesteuert) oder die CPU selber muß ist das auch immer gleich mit Belastung der CPU. Ein solcher Test ist ja auch zu individuell für wirkliche Vergleiche. Mir ist noch keine 10GBit/s LAN Karte unter gekommen, die bei mir die C-States nicht belastet hat. Dem stimme ich zu - auch deswegen versuche ich keine Pauschalaussagen zu treffen, die so klingen, dass es immer der Fall wäre.

Auf dem Gigabyte B760M DS3H DDR4 kann man bis zu 5 NVMe SSDs gleichzeitig (ggf. mit PCIe 2 M.2 Adapter und ggf. nur mit 1 Lane) betreiben. Für jeden PCIe Slot, den man für etwas anderes benötigt (dGPU, LAN, ) fällt dann eien Möglichkeit weg. Wenn man bereit zur Investition ist und den höheren Stromverbrauch akzeptiert kann man mit PCIe Switchkarten etwas gegensteuern. Leider beherrscht das benannte Gigabyte Board kein Bifurcation. Und nur so nebenbei: ja, es gibt Personen, die Aussagen treffen, daß PCIe Komponenten, die direkt von der CPU versorgt werden immer den Stromverbrauch anheben. Solche Fälle gibt es wirklich zuhauf, aber diese Aussage wird dann zu pauschal für alle Konstellationen getroffen und das ist nicht korrekt, wie ich selber hier im Forum vor über 1 Jahr gerade an diesem Board dargestellt habe. https://forums.unraid.net/topic/156160-gigabyte-b760m-ds3h-ddr4-verschiedene-messungen-werte/ Siehe Messung 2: Lexar NM790 4TB im Chipsatz M.2 Slot: 9,51W und Messung 3: selbe Lexar NM790 4TB im CPU M.2 Slot: 8,94W Im Rahmen der möglichen Messungenauigkeit waren beide Konstellationen eher als identisch anzusehen. Anstatt es pauschal zu sehen kommt es eben sehr auf das komplexe Zusammenspiel der jeweiligen individuellen Kopmponente, den Firmwares, Einstellungen und Benutzungen an.

Du gibt viele Informationen, aber keine sagt aus, welchen Durchsatz Du für Deine Arbeit brauchst. Mit welcher Geschwindigkeit liest Du die Daten im Precut, Mit welcher Geschwindigkeit laufen die Daten von Quelle ein, wenn die Software den Cut+mux ausführt udn mit wlecher Geschwindigkeit scheibst Du das bearbeitete Material in dein Ziel? Da es bei unraid als NAS für Dich ja um die Zulieferung (Quelle) und ggf. auch als Empfang (Ziel) geht stellt sich die Frage was Du wirklich nutzt/brauchst. Wenn es wirklich im professionellen Umfeld stattfinden sollte (Profi = Geld damit verdienen) und pro Drehtag wirklich nur maximal 4TB anfallen, wäre es auch zu überdenken einfach ein paar NVMe SSD für die Quelle zusammen zu schalten. Ich nutze (nicht für Videobearbeitung) 3x 8TB SATA SSDs in einem unraid pool mit zfs Raidz1 (=Raid5). Funktioniert super und weil es SSDs sind, ist es sparsamer und (selbst durch Verwendung von Samsung QVO SSDs) immer noch schneller, als wenn ich 2-3 mechanische Festplatten dauerlaufen lassen würde um darauf immer wieder in kurzer Zeit zuzugreifen. Wenn ich mir ein Mainboard mit vielen Möglichkeiten für NVMe SSD (und/oder PCIe Slots) suche, sollten problemlos 4-6 NVME SSD machbar sein. Beispiele: - mein altes Fujitsu (neu Kontron) D3644-B könnte schon 6 NVMe beherbergen + einen 10GBit/s Lan Kontroller. 5x4TB = 20TB Quellmaterial ruckzuck (mit geringster Latenz im NAS) als Quellmaterial und gerne die 6. NVMe SSD für das Zielmaterial. - Auf dem erheblich neueren Asus PRIME Z690-P-D4-CSM wären 8x NVMe SSD möglich und zusätztlich ein 10GBit/s LAN. Und dabei sind die Möglichkeiten von PCIe Switches als PCIe Steckkartren für bis zu je 4 NVMe SST noch gar nicht dazu bedacht. Im Rahmen eines Profigehaltes sollte sich das recht schnell finanzieren lassen.

Es gibt nur noch "etablierte Hersteller" Der Markt ist auf 3 Hersteller geschrumpft. Wenn man andere Namen findet sind es umgelabelte Modelle. WD, Seagate und Toshiba sind nur noch verblieben und im unraid array fühlen sich alle Festplatten dieser Hersteller wohl. Nur bei der Parity sollte man ggf. langsame (SMR) Festplatten meiden. Eine dort verbaute passive Backplate: nein Eine aktive Backßlate (mit beispielsweise SAS Expander) hat indirekten EInfluß, da man dafür einen SAS Kontroller braucht udn die sind (heutzutage) per PCIe angeschlossen.

Ich nutze Hardwareraid Raid6 (kein zfs) mit bis zu 12 Platten pro Raidverbund. So schnell wie eine gute NVMe SSD (Peak meherere GByte/s, Dauerschreibrate über 1 TB stark abhängig von dem Modell um die 700 MByte/s) aber wird es dennoch nicht. Wie alturismo schon andeutet, es hängt von Deinem Workflow ab (achja und was Deine Schnittsoftware so alles an optimierungen im Workflow kann. wenn die das Material vorbereitet und zwischenspeichert läuft der Schnitt (precut) schneller, als wenn es nichts puffert und alles von der Quelle in Vollformat zieht, während Du über die Timelines springst. Ich (Amateur mit einfachen Mitteln und auch kein 4k oder 8k Material) Schneide die Videos und remuxe die nur an den Schnittkanten. Dadurch läuft es recht flott. Ich bemerke dennoch den Unterschied, ob ich Quelle/Ziel HDD (auch gerne ein Raid5/6) oder NVMe SSD habe (selbst wenn die SSD 'nur' per PCIe 3 bedient wird). Deshalb (wenn ich absehen kann dass ich an einem Tag doch ein paar Dutzend Videos bearbeiten werde) landet das Quellmaterial bei mir erst auf einer guten 4TB NVMe SSD und dann bearbeite ich die Dateien und schreibe auf eine andere 4TB NVMe SSD. So kommen sich auch Lesen und Schreiben nicht in die Quere, wenn man nicht alles auf einem Pool macht. Sobald ich in größerem Umfang remuxe wird es sowieso so langsam, das annähernd jede HDD da mitkommt. Auch das hatte alturismo ja schon angedeutet. Ich befürchte nur, wenn Du nicht weißt, wie Dein Workflow abläuft und welche Geschwindigkeiten und Latenzen Du brauchst, wirst Du enttäuscht. Auch, wenn Du beispielsweise über SMB Verbindungen schneiden willst. die Latenzen können den Workflow (im Precut) doch schon bremsen. Und irgendwie sehe ich nicht, daß ein Raid5/6 mit 10 Festplatten (vor allem, wenn sie unterschiedlich sind) viel "Performance"Unterschied macht, gegenüber einem guten homogenen 8 Platten Raid5/6. Zumindest zeigt meine Erfahrung mit Raid5 und 6 auf Hardwareraidbasies (Broadcom SAS und Expandern mit gesamt >50 Festplatten in mehrere Raids aufgeteilt), daß es ab ca. 6-8 Festplatten nach oben hin nicht mehr wirklich nennenswert flotter wird. Eine gute NVMe SSD steckt das allemal in die Tasche. Wenn es mir um Geschwindigkeit gehen würde, wären gute (und je nach Umfang auch große) SSD das Mittel der Wahl. Ich nutze nur so viele mechanische Festplatten, weil ich mir rund 1,5 PB an SSD Kapazität einfach nicht leisten kann/will und viele meiner Daten eher lagern. als täglich gelesen und geschrieben zu werden.. Wenn Du umfangreiches Material bearbeiten willst ist riesiger Cache sowieso sehr anzuraten. Aber dann macht es noch weniger Sinn einen "flotten" Festplattenpool zu nutzen, da ich mal stark davon ausgehe, daß Du bei Adobe Preimiere alles relevante im CXache vorbereitest und danach eben nicht nur geschnitten, sondern auch 'manipuliert' wird (Blenden, Farbanpassungen, Audio synchron einmuxen, etc.. und dann bezweifele ich, daß die CPU/GPU schneller als 150MByte/s (1200MBit/s) Quellmaterial in Zielmaterial verwandelt. Und diese Geschwindigkeit sollte eine gute Festplatte heute sogar alleine schaffen. Stromsparen ist bei einem zfs Raid5 gar nicht drin. Wenn auch nur ein Bit von einer der Platten geladen werden muß laufen ALLE Festplatten in dem zfs Verbund. 10Festplatten x 10Watt (moderne Platten haben laufend etwas weniger, ältere Platten liegen aber schon so um 10W) = 100W Dauerlauf. Wenn Dein NAS 24/7 läuft wird es zumindest beim Lesen oder Schreiben auf einen 10er Pool eben dann rund 100W jede Stunde zusätzlich verbraten. Deshalb ist bei unraid (wenn es um Energie geht) eben kein zfs Fetsplattenraid zu empfehlen. Das ist ja der Vorteil des unraid array: es werde nur die gerade benötigten Festplatten verwendet, was es energetisch sparsamer macht.

Ich glaube ich habe verstanden, daß Du hohe Performance/Geschwindigkeit willst. Bei einem klassischen Array sind die Parity Festplatte(n) sowieso die Größten, das wirkt sich nicht negativ aus. Das klassische Array ist aber auch nicht was Du wohl willst. In einem Pool mit einem zfs "Raid" kann auch zfs nicht wirklich zaubern. Je nachdem, welche Art von zfs "Raid" Modus Du verwendest, sollten es alles gleich große Datenträger sein (der Teil der größeren Datenträger ist dann in dem Raidmodus nicht nutzbar...(kann aber vielleicht mit einem anderen Raidmodus extra benutzt werden. Einige Raidsysteme könne das, ob zfs das kann weiß ich nicht. Aber wenn es das kann könnten sich ggf. unterschiedliche Zugriffe gleichzeitig auf diesen Datenträgern treffen und dann wird es ggf. langsamer. Raid0 = (Striping) Zusammenfassung des Speicherplatzes ohne Redundanz. Wenn sich die Zugriffe auf mehrere Datenträger verteilen können ist es schön flott und groß. Ich glaueb zfs handhabt das weitgehend beschleunigend. Raid1 = (Spiegelung). Es müssen alle Daten auf alle beteiligten Datenträger geschrieben werden. das ist zwischen genau so flott schreibend wie ein Datenträger alleine und minimal langsaer (wenn die Datenträger sich ewas unterschiedlich verhalten). Lesend kann es im optimalsten Falle eine höhere Geschwindigkeit als nur ein Datenträger erreichen. Raid 5/6 = (Raidz1/2) Meien ERfahrung (auzerhalb von zfs) mit diesen Modi: mit sehr vielen Festplatten gleichzeitig im Raidverbund kann es schon recht flott werden, aber die Geschwindgikeiot von guten NVMe SSD >1,5GByte/s habe ich noch nie erreicht. Aber irgendwie verstehe ich nicht: wenn Du flotte zfs Pool(s) aufbaust, wofür sind dann die SSDs noch gedacht? Und Dir ist bewußt, daß Du damit eigentlich die Stromsparmöglichkeiten des klassischen Arrays komplett in den Wind schießt?

Nur zur Sicherheit: Dein Laptop selber hat auch einen 2,5GB Lan Port und der 2,5 GB Lan Port des Laptop ist mit dem Repeater verbunden? Wie ist der Repeater mit der Fritzbox verbunden? Ich frage, weil WLAN selber sowieso etwas einbricht (je länger die Strecke oder auch je mehr Hindernisse) und wenn Du den 1GBit/s LAN Port des Repeaters und/oder der Fritzbox da auch irgendwie im Spiel hast, werden die 130MBit/s schon sehr gut erklärbar. Bei dem Test solltest Du eine durchgehende 2,5GBit/s Strecke haben.

Ziemlich leistungsfähig mATX und ATX werden hier benannt Zu Deinem RAM: bevorzugt wenige große, als viele kleine Riegel verwenden. Bei 64GB werden das bei DDR4 bevozugt 2x 32GB sein. Blechdeckel/Overclocker Module sind oft teurer und mit XMP oder so vielleicht eher auf hohe Takte bei erhöhter Spannung ausgelegt. In einem 24/7 laufenden NAS legt man aber eher Wert auf Stabilität, als auf jedes Quentchen Leistung, hart an der Kante zur Instabilität. Auch deshalb bevorzuge ich Standard SPD Module (also keine Blechdeckelmopdule, welche die fragliche Qualität der Chips unter dem Deckel der Verschwiegenheit verstecken müssen). Solange da aber ein vertrauenserweckckender Hersteller dahinter steckt und wenn bei einem Sonderangebot die Preise sehr gut=billig sind, darf es bei mir (aber eher für Windows Desktops) auch mal ein Blechdeckel sein. Aber die werden bei mir dann auch erst einmal heftig mit memtest86/86+ gequält. BN341: gutes und sparsames Netzteil. Ähm.. in das Node 804 ein ATX Boardf rein zu bekommen bedarf wohl einer Säge Bei dem Meshify 2 Compact sollte ein ATX Board passen. Wenn Du die WD Red schon hast: okay. Wenn Du die extra wegen unraid kaufen willst: meist zu teurer Overkill. Beim EInsatz im Array (und den der eher stromsparenden Nutzung mit viel Spindown sind 24/ Dauerlaufplatten nicht wirklich notwendig und als WD Red meist überteuert. Zur Menge der Festplatten: unraid klassiches Array mit 1 P+1D schreibt ziemlich schnell. Sobald Du mehr als 1 Datenfestplatte mit Parityplatte(n) einsetzt geht die Schreibgeschwindigkeit auf 33-50% runter. Das sollte Dir bewußt sein, wenn DU dann später aufrüstest und nicht erschrickst. Deshalb sollte der Cache für das Array ausreichen groß sein um Schreibzugoiffe mit neuen Dateien weitestgehend abfangen zu können. Bitte keine WD NVMe SSD (oder zumindest vorher recherchieren, welche ggf., Probleme mit den Schlafzuständen verursachen können). Auch sind Samsung 990 mal negativ aufgefalllen und um Intenso mache ich sowieso einen Bogen... Wenn es keine wirklich 'lebenswichtige' Anwendung ist, sollte eine NVMe SSD für Appdata und so (Systemshares) reichen, die andere wäre als Cache für die anderen shares auf dem Array hilfreich. Die beiden Cachefunktionen durch getrennte SSDs zu realisieren macht viel Sinn, wenn man auf beiden Anwendungen (Docker/VM = Systemshares) und auch schreibend ins Array gleichzeitig viel 'Action' hat. Ansonsten reicht auch eine (NVMe) SSD, welche als Cache die shares für alles beherbergt. Die Bandbreite (welche LAN? PCIe?) ist weniger interessant. Die Benutzung und Wahl der Komponenten ist ausschlaggebend. Wenn ich gleichzeitig über 10GbLan einige TB an Daten in mein unraid presse geht die SSD irgendwann etwas in die Knie und das würde auch dann die Docker/VM darauf beeinflussen. Deshalb habe ich die getrennt. Aber das ist ein Extremfall. wer presst in kurzer Zeit kontinuierlich so riesige Datenmengen in sein urnaid? Und dabei habe ich extra schon SSDs gewählt, die (im Rahmen eines guten Preises) eine doch ziemlich gute Dauerschreibfestigkeit aufweisen unnd bei Tests erst sehr spät in der Schreibgeschwindigkeit einknickten. Wie soll man das beantworten? Wenn Du 20TB an Daten unbedingt in dem Cache lagern willst (bevor der Mover oder eiene Routine umlagert) solltest Du etwas mehr als 20TB an Platz dafür bedenken. Wenn Du nur 5 MB darin lagern willst brauchst Du eben weniger als 100MB an Platz für Deine Daten. Da die Daten aber (bei normaler Nutzung) gar nicht lange im Cache rumliegen, sondern ggf. im Array gelagert werden und diese Umlagerung von Deinen gewählten Einstellungen abhängt kann man das eben nicht pauschal beantworten. Wenn Du darin eine Anwendung betreibst, die den lokalen Flugplatz versorgt und für die Fluglotsen wichtig ist: klar: Ausfallsicherheit ist da sehr wichtig. Auch die Steuerung des Beatmungsgerätes Deiner liebgewonnen Oma sollte möglichst Ausfallsicher sein. Wenn es hingegen nur um ein paar problemlos wieder einscannbare Blatt Papier und ansonsten nichts wirklich wicchtiges geht ist Raid1 im Pool eher eine Sache der energieverwendenden Bequemlichkeit. P.S.: Ich quäle meine SSDs wirklich und hatte bisher nur 2 oder 3 Ausfälle (zu der Anfangszeit der SSDs als noch SATA -2 absolut Hipp war (>1 Jahrzehnt her)). Seitdem ist mir von meinen dutzenden SSD keine mehr verstorben. Sie werden eher ausgewechselt, wenn sie zu klein sind und dann habe ich Freunde und Bekannte, die sich im Rahmen ihrer Aufrüstungen/Umbauten sehr über meine gebrauchten (und billig abgegebenen) SSDs freuen. Da ich meist bei PC Hilferufen kontaktiert werden kann ich sagen auch dort hatten wir noch keine SSD Haredwareausfälle. Probleme in Dateisystemen hingegen sind hingegen ab und zu mal vorhanden. (Bei unraid liest man bei btrfs gelegentlich von Problemen, bei WIndows gerne bei NTFS). Deshalb sehe ich Raid1 bei SSDs nicht mehr wirklich als wichtig an. Backup ist mir da erheblich wichtiger. Ein Fotografierender Bekannter, der seine Urlaubsknipsereien zwar ab und zu auf eine Festplatte backupt, aber dennoch viel auf seinem Windowsdesktop (ja, c:\User\Name\Desktop) lagerte musste mir da zustimmen, nachdem auf einmal sein Windows nicht mehr startete und die Rettung der Daten von SSD mit vielleicht 10% Erfolg endete. Die SSD selber war technisch okay (und ist auch danach wieder problemlos im EInsatz), aber das Dateisystem war defekt und somit die Zuordnungen der Blöcke nicht mehr rekonstruierbar.

Im happy to help 😁

Vorausgesetzt, es ist nicht noch mehr schief gelaufen: Backup Deinr Daten auffrischen (zumindest als UD sind ja alle wohl noch lesbar), Array mit dem Tool new config auflösen (nur das betroffenen Array und nicht die Pools), Array mit den Festplatten wieder neu erstellen, Array starten und Paritycheck machen (und Parity bei bedarf korrigieren lassen). Warten bis Paritycheck fertig ist und freuen, dass es wieder läuft. Zeitbedarf bei 16TB großer Parity: geschätzt 1,5 Tage.

Du hast das Array nicht verstanden oder genauer gesagt den Hinweis, daß die Parity (JEDE Parityfestplatte) IMMER die Größte sein muß. Du willst 12TB Parity + 4TB Parity nutzen: Dann darf jede Daten Festplatte maximal 4TB groß sein, weil die kleinste Parity die maximale Größe (hier 4TB) der Datenfestplatten vorgibt. Wenn Du nur eine oder gar beide 12TB als Parity einsetzt, dann kannst Du auch Datenfestplatten mit maximal so viel Größe (12TB) einsetzen. Wenn Du also auf die 4TB Parity verzichtest, kannst Du Deine andere 12TB und die beiden 4TB Disks als Datendisk einsetzten (=rund 20TB Nutzkapazität). Du hast dann bei der Konstellation aber nur eine Ausfallsicherheit gegen den Ausfall einer Disk im Array gleichzeitig (was bei einem so kleinen Array eigentlich ausreichend sein sollte). Und wenn Dir Deien Daten auf dem Array wichtig sind: Eine Ausfallsicherheit reicht dann ggf. nicht aus und eine geeigene Backupstrategie ist anzuraten.

Dass die Realteks unter unraid oft in per ASPM Helper sparsam bekommen werden können ist bekannt?

Dann schmeiss die Doch in so eine Anwendung rein. Die indiziert es Dir. bei Sharepoint ist eigentlich auch ein anderer Anwendungszweck vorgesehen. Da hat nicht ein Nutzer seine ganzen Dateien, sondern wie der Namen sagt sollte es ein Sammelpunt sein, auf den diese Person die Datzen mit andenen teilt (sharing). Ein Index macht Sinn, wenn andere Leute eben nicht wissen, wie etwas sortiert ist aber Zugriff auf all das haben sollen. Aber dass jemand bei unraid vielen anderen Useren einen Vollzugriff auf alle Dateien gibt ist irgendwie nicht üblich.

Ich habe bisher noch keinen zfs Pool mit 3 oder mehr Festplatten (Raid5/6) aufgebaut ... ich werdende aber unter Windows hardearerraid (Broadcom) mit bis zu 12 festplatten in einem raid6 und ja: Raid5/6 kann auchg mit vielen Datenträgern (Festplatten) so flott werden, daß es 10Gb/s Lan sättigen kann. Da Du aber eben eine NVMe vorschalten willst, würde sich das bei Dir nur lesend wirklich auswirken, weil Schreibzugriffe ja auf die NVMe SSD gehen, die dann später iden Pool moven köönte. 2x 2TB NVM in einem Pool zusammengescahltet als Raid0: das macht Sinn, wenn Du gedenkst wirklich schnell Datenmengen >3,9TB in unraid rein zu pressen, bevor ein Mover die in Deinen zfs Festplatten Pool verschieben will. 2x 2TB NVMe in einem Pool zusammengescahltet als Raid1: Ich bin da kein Fan von, aber ja,. es gibt einige Leiute, die meinen, daß ihre Daten so extrem wichtig sind, daß die Ausfallsicherheit unbedingt noitwendig ist, da die Beatmungsmaschien der oma dran hängt oder so... ja, dann ist auch das anzuraten. Für noermale Privatanwender sehe ich raid1 eher als Luxusspielereio und als nicht wirklich NOTwendig an. 2x NVMe SSD in je einem eigenen Pool getrennt aber jede als Cache im Rahmen eines (anderen) shares: Ja, das mache ich. Eine NVMe SSD bedient die shares für die Systemverzeichnisse (system, appdata...), die andere NVMe SSD ist weitaus größer (4TB) und dient eben als Cache für die shares in denen ich meine eigenen Nutzdaten platziere (weil ich eben doch des öfteren über 10Gb/s Lan Mengen > 3,xTB in einem Rutsch in mein unraid rein presse).

Was ich schnell finden will, habe ich geeignet sortiert und finde es. Wenn ich etwas suche, von dem ich nicht weiß, wo es gelandet ist, suche ich eben Dateiname (soweit bekannt/vermutet) und ggf. Dateiinhalt (soweit durchsuchbar): Dabei reicht mir meist das, was mir der TotalCommander meines zugreifenden Windows Clients ermöglicht. Wenn es um Dokumente geht (also nicht alle Shares, sondern eben nur das, was mit Dokumenten zu tun hat), gibt es Dockerlösungen. Wenn ich einen Index über alles erstellen lassen wollte, wäre das sehr aufwändig und groß. Auch will ich meine Urlaubsbilder nicht zwischen der Stromrechnung, TV Aufnahmen, Musikdateien, oder meinen persönlichen Briefen zusammen in einer Datenbank indiziert haben (wenn andere da auch zugreifen können (gewollt oder ungewollt)). Auch erschließt sich mir nicht (wenn es wirklich alle shares sein sollen) waruim man den Inhalt von appdata, oder isos indizieren sollte. Kompliziert wird es auch noch, wenn man per UD weitere Datenträger einbindet und die auf einmal ggf. mit indiziert werden, aber dann später nicht mehr vorhanden sind (weil man die abgemeldet/abgestöpselt hat). Selbst die Dateiindizierung auf meinen Windowsclients schalte ich weitestgehend ab.

Wenn DU die festplatten weiter im klassichen unraid Array verwenden willst, hast Du dort weiterhin nur die Lesegeschwindigkeit der jeweilig angesprochenen Festplatte. In einem solchen Array mit Parity hast Du im Array auch weiterhin nur die Schreibgeschwindigkeit von ca., 33-50% der Partity. Ha ändern auch andere Festplatten nichts dran. Ohne Parity liegt dei Schreibgescjhwindigkeit bei fast 100% der jeweilig benötigten festplatte (genau wie beim lesen). Wenn Du mehr Geschwindigkeit mit mechanischen Festpletten willst, aber dafür die Stropmsparmöglichkeiten verlieren willst kannst Du die Festplatten in einem/mehrerenb Pools zu Raid zusammenfassen. Ich würde weiterhin das klassische unraid Array nehmen (wegen dem Stromsparen). Wenn Ausfallsicherheit dort gewünscht ist mit Parity (größte+schnellste mechanische Platte). Dann eine NVMe SSD als xfs Singledatenträger in einem eigenen Pool und diesen in den Shares als Cache dem Array vorgeschaltet. Die zweite NVMe SSD ist in der Konstellation nicht erforderlich und braucht somit auch nicht mitlaufen und Energie in Wärme umsetzen..

Meine Antwort oben bezog sich (wenn ich mich nicht irre) auf die Frage, was das schnelle Backupziel in meinem Vorschlag sei. Das Du nun ein ganz anderes Thema bnringst, war mir nicht klar. Da ich das Thema nicht behandele, bin ich raus.

Dann kann es natürlich immer auch sein, daß der Kontroller wirklich verstorben ist.

Nimm das Windows Tool Das mit dem "nicht finden" hängt mit den Stromsparmodi zusammen. schalte die ab und boote unraid neu und die Disks sollten erstmal wieder normal da sein.

Bei einem Backup verschiebe ich nicht. Wenn der Mover verschiebt sollte das Backup schon durch sein und die Bilder liegen gedoppelt auf der zweiten SSD.