DataCollector

Dito. Da hier die Frage nach dem Stromverbrauch von unraid 6.12.9 angedeutet wurde, habe ich mein Testsystem mal dahingehend angeworfen. Hardware: siehe https://forums.unraid.net/topic/156160-gigabyte-b760m-ds3h-ddr4-verschiedene-messungen-werte/?do=findComment&comment=1388195 eben ohne Steckkarten. Wie üblich warte ich bis der Monitor schwarz geschaltet wird (ca. 15 Minuten) und lese dann den niedrigsten Wert der AVM DECT200 Steckdose per Fritzbox aus. Messung 1: unraid 6.12.4 (weil es mit dem Realtek Lan Chip out 'of the Box' am stromsparensten umgehen kann) Wieder einmal die üblichen knapp unter 10W und C10 absolut idle und ohne irgendeine Funktion. Messung 2: unraid 6.12.8 ca. 14W weil damit nur noch maximal C3 erreicht werden. Wie schon früher festgestellt, das Realtek Lan Problem ist damit ja nicht behoben. Ebenfalls komplett idle. Messung 3: unraid 6.12.9 ca. 14W weil damit nur noch maximal C3 erreicht werden. Also das Realtek Lan Problem ist auch damit noch nicht behoben. Auch hier wieder komplett idle. Aber daß Version 6.12.9 wirklich einen Mehrverbrauch zu der vorherigen 6.12.8 hat, kann ich hiermit nicht feststellen.

Intern: Es hat den Vorteil, daß der Stick nicht abbricht, wenn man gegen das Gehäuse kommt und eien Manipulation/abziehen ist schwieriger. Extern: man kommt schneller dran, wenn man doch mal an dem Stick was machen/reparieren muß (beispielsweise gibt es ja aktuell wohl ein Problem mit 6.12.9 und broken zfs Raid, was den Stick wohl komplett löscht. Ich möchte in dso einem Fall nicht jedesmal das Gehäuse aufschrauben um den Stick zu entnehmen und extern neu zu bespielen. Falls Du mit "low profile" die C-States meinst;: das ist leider etwas Glückssache geworden. Deshalb hat sich ja auch die Sache mit der Flashmöglichkeit ergeben. Ausprobieren. Dafür gibt es zu wenige Anbieter der ASM Karten, die mehr als nur irgendwelche flüchtigen CHinanamen sind um da ein spezielles Produkt herauszupicken. Die Original Silverstone-Karte hat ja das Flashtool, aber genau diese Karte ist ziemlich teuer (wenn überhaupt noch zu bekommen) Falls Du mit "low-Profile" das eher sogenannte Vorhandensein eines Low-Profile Montagebleches meinst: viele Lieferungen hatten beide Bleche im Lieferumfang. Wenn die Karte die sparsameren C-States nicht unterstützt ist das Flashen eben eine Möglichkeit, daß es funktionieren kann. Aber in letzter Zeit finden sich auch immer mehr ASM1166 Karten, bei denen das auch nichts mehr bringt (zumindest so meine Erfahrung seit rund 1/2 Jahr). Dieser Aussage entnehme ich, daß Du diesen Beitrag noch nicht kennst: https://forums.unraid.net/topic/141770-asm1166-flashen-mit-der-firmware-der-silverstone-ecs06-karte-sata-kontroller/?do=findComment&comment=1324431 Du kannst eigentlich jedes Share auf jeden Pool legen. Und die Position von VM Disks ist eben nur der Inhalt eines dafür vorgesehenen Systemshares. Das war nicht der Hintergrund meiner Aussage. Wenn die normale Cachefunktion des Array die VM/Docker in deren bedienung beeinflußt macht es generell Sinn diese auf unterschiedliche Pools/Caches zu trennen. Wenn sich diese nicht beeinflussen kann man die auch zusammen lassen. Ob sie sich beeinflußen ist sehr individell von der Nutzung und ARt der VM udn Docker und SMB Freigaben abhängig. Ich dachte aber eher daran in jedem Fall große SSD zu verwenden. Und das spricht ja nicht dagegen 2 Stück der großen SSD zu nehmen.

Warum teuren Overclocker-/Blechdecekram? Standard 32GB DDR4-3200 Module sind billiger. Willst Du den Stick unbedingt im Gehäuse platzieren oder wäre es nicht bequemer den von außen erreichbar zu haben? Technisch passt sie, In wie weit sie die C-States beeinflußt wirst Du sehen. Ob DU es mit dem umflashen bei bedarf verbessern oder verschlechtern wirst, wirst Du uns dann vermutlich erzählen. Das ist egal. Für diese Festplatten sind alle Slots identisch gut. Ich bin ein Freund von: besser groß. Wenn man mal mehr transferiert läuft man nicht in die 'Arraybremse', große SD haben b´meist auch einen höheren TBW Wert, weshalb man annehmen kann, daß sie bei gleicher Belastung wie eine kleiner SSD länger halten sollten und größere SSD sind ggf. auch flotter als deren erheblich kleineren Geschwisster.

Nur so als Bemerkung: anfangs wolltest Du nicht aufrüsten, nun schreibst Du von 'dazu stecken'. Nimm keine kleinen Speichermodule! Wenn Du mit 32GB starten willst nimm 1x 32GB Modul und keine 2x 16GB. Wenn Du aufrüsten willst, dann hast Du mehr DIM Slots frei dafür. Nebenbei: Du brauchst keinen teueren Overclocker-/Blechdeckelram (DDR5-5600) für 98,16 Euro um ein NAS zu betreiben. Der I3-14100 ist sowieso nur für DDR5-4800 (PC5-38400, 76.8GB/s) spezifiziert. Nimm das, was technisch passt und günstig ist. Wenn es ein Sonderangebot für Bleckdeckelram gibt ist das okay, aber im Normalfall reichen auch welche, die die Chips nicht unter Bechdeckeln verstecken müssen. Eigentlich sollten die alle passen: https://geizhals.de/transcend-jetram-dimm-32gb-jm4800ale-32g-a2747929.html?hloc=at&hloc=de https://geizhals.de/mushkin-essentials-dimm-32gb-mes5u480fd32g-a3059070.html?hloc=at&hloc=de https://geizhals.de/adata-ddr5-dimm-32gb-ad5u480032g-s-a2626411.html?hloc=at&hloc=de https://geizhals.de/crucial-ddr5-dimm-32gb-ct32g48c40u5-a2627504.html?hloc=at&hloc=de und sind alle billiger als das benannte 2x16GB Kit.

Ich bin skeptisch bei 5x transcodieren gleichzeitig. Ich plexe zwar nicht, aber je umfangtreicher man da transcodieren will (mit oder ohne tonemapping und vielleicht dann doch herausfordernder Untertitel) befürchte ich, das das 5mal vielleicht etwas grenzwertig wird. Man müßte wissen, was hier mit Transcoding genau gemeint ist.

Bauliche Veränderungen dieser Art sind zur Zeit nicht akzeptabel. Ich bleibe dabei Ethernet TwistedPair über diese Strecken zu nutzen oder mich wirklich mit GF Spleißen zu beschäftigen (ggf. auch einfach einen Fachbetrieb dafür zu beauftragen). https://www.telefon.de/Sonstiges_g950_998/Telekom-Speedport-OptoLAN-Pack_p41178 Es war eine Lösung mit 30m POF-Kabel (Polymeres optisches Faser-Kabel) 2 Sende/Empängerboxen und Netzteilen. Zu der damaligen Zeit ein preiswertes Set für rund 30 Euro um eben 100MBit/s sehr elegant zu verlegen (aber eben energiebedürfend an den Enden). Ich sehe, Du kennst das Telekom POF Set eben nicht.

Nur so: Ein Mover, der auf Füllstatus reagiert würde das System noch mehr durcheinander bringen. Erklärung: Man hat eine Pool/Cache SSD, die die Daten schenll aufnimmt (sagen wir mal bei einer 10GBLan Anbindung schreibt die SSD optimal konstant mit 1GByte/s). Wenn dieser Pool Cache nun bis zum Anschlag voll läuft und der Mover anspringt, verschiebt dieser die Dateien des Cache ins Array, welches festplattentypisch mit 80Mbyte/s wegschreibt (wenn man Parity nutzt). Das bedeutet also, daß nun einerseits die Daten der Pool/Cache SSD ins Array geschrieben werden (welches aber zur Aufnahme nicht schnell genug ist). Es prasseln aber andererseits weiter Dateien über die 10GBLan rein und diese werden dann (default bei unraid) direkt ins Array geschrieben. Somit kommen sich auf dem Array 2 Schreibvorgänge gleichzeitig in die Quere und werden beide dann auf jeweils ca. die Hälfe ausgebremst (wegen der zusätzliochen Kopfbewegungen, vermutlich sogar noch niedriger). Somit würde eine Füllstandsabhängige Movernutzung in dem Fall sogar noch mehr behindern, als es die defaulteinstellung des Durchschreibens auf das Array macht. Warum es bei Dir nicht auf das Array schreibt, weiß ich nicht. In der Regel sollte das funktionieren. Mit ausreichend (bis sogar sehr groß dimensioniertem) Cache kann man das auch kompensieren. Du schreibst von Cache SSDs = Mehrzahl: Falls Du die als Raid1 nutzt, vielleicht mach es Sinn die als Raid0 zu nutzen. So hast Du ohne Kostenaufwand eine höhere Kapazität im Cache und wenn Du den Mover vielleicht auf 1x pro Nacht einstellst gehen im Schadensfalle auch nur die Daten eines Tages verloren. Nur so als Gedanke.

Daß man bei einem ausreichen großen Cache eben die Platten möglichst lange schlafen lassen kann und diese dann eben timergesteuert erst anlaufen, wenn das System in Offzeiten nicht viel zu tun hat. Dass ist im Regelfall auch so. Was Du da verstellt hast, dass die Daten nicht ins Array laufen weiß ich nicht. Hast Du evtl. mit dem zusätzlichen Mover Plugin da etwas verstellt? Korrekt. Und das ist auch so gewollt und dokumentiert. Kann es ein, daß Deine Software, die diese Dateien anlegt vielleicht temporärdateien auf dem selben 'laufwerk'/Share nutzt? Sabnzb beispielsweise macht den download und kopiert anscheinend danach die Teile zusammen. Das bedeutet, daß im falschen Moment für den einen Download fast doppelt so viel Platz benötigt wird, als das Ergebnis hinterher aufweist.

Ich glaube, ich erwähnte, daß ich eben schmale Rohre habe. Und um den Bestand zu nutzen einet sich eben bisher Kupfernetzwerkkabel besser, da ich eben nicht spleißen kann. Ich habe noch ein paar der alten Magenta POF Kits im Keller, aber die sind nur bis 100MBit geeignet und nur mit deren eigenen Endstücken.

Kannst Du bei LWL Spleißen? Icha habe ein paar Strecken, die ich gerne (wegen dünner Rohre) gegen LWL austauschen würde, aber leider passen die Stecker da nirgendwo durch. Somit müßte ich mir einen Spleißkoffer leihen/anschaffen und hoffen nicht zuviel Ausschuß zu produzieren. LWL im Gebäudenetz ist eine nette Idee, aber die manuelle Konfektionierung ist eben immer noch nicht so einfach wie RJ45 mit TP Kabeln.

Share Minimum Free (sollte etwas größer sein, wie die größte jemals zu schreibende Datei). Cache Minimum Free (sollte etwas größer sein, wie die größte jemals zu schreibende Datei). Und wenn im Share geschrieben wird und der Cache sich als voll meldet, dann wird ins Array durchgeschrieben. Die Funktion des Movers ist an den Timer geknüpft. Man kann mit Mover Tuning da etwas vareieren, aber der Mover arbeitet default nach dem eingestellten Timer/Schedule. Bild 1: Share (gelb = minimum Free Space; Grün = Wie soll weiter geschrieben werden) Bild 2: Im Cache gibt es auch ein Minimum Free Space.

Ansonsten vielleicht mal über einen Monitor-Dummystick nachdenken. Einige Mainboards/Grafikkarten sind da empfindlich und nur mit solchen Tricks zur vollen Kooperation zu bewegen. Natürlich sollte man dann mal schauen ob der Dummy nicht über die Zeit dann sogar mehr Strom benötigt, wie die Spikes zusammengerechnet. (Keine Medikamente ohne Nebenwirkungen 😄 )

Ich vermute Du meinst, Du willst die -16i neu einsetzen und die alte -8i dafür rausnehmen/entfernen. Da beides SAS Kontroller im HBA Modus sind, werden die Festplatten transparent durchgereicht und somit sollte der Austausch dahingehend kein Problem sein. Beachte, daß die 9300-16i eigentlich 2 9300-8i auf einer Platine sind und sich etwas ungewöhnlich verhalten kann, je nachdem welche Firmware drauf ist. Vielleicht interessiert Dich dazu: https://www.mydealz.de/comments/permalink/45323776 bzw. der relevante Link darin (den das Forum hier nicht einfügen läßt, weil es ein Link zu einem Konkurrenzprodukt zu unraid ist). Eigentlich nicht, da die 9300-16i (bestehend aus 2 internen 9300-8i Chipkonstruktionen) ein ziemlicher Stromfresser ist (erkennbar an dem riesigen Kühler), wirkt es sich kaum noch aus, ob Du nun alle Port des 16i oder ein paar weniger am 16i und dafür ein paar mehr am Mainboard nutzt. Daß es Deine C-States fast komplett verhagelt sollte Dir ja schon mit dem 8i aufgefallen sein. Beachte die erforderliche Luftbewegung. Der alte 8i war dahingehend nach halbwegs handzahm, aber der 9300-16i ... Hier das Usermanual mit der Powerangabe. https://docs.broadcom.com/doc/12353308 "Power Requirements: PCIe 12.0 V = 2.25 A Passive cable, nominal = 26,9 W" Die rund 25W möchten gerne aktiv gekühlt werden! (Vielleicht sind doch ein paar sparsame SATA Kontroller, zusätzlich zu Deinen onBoard 6 SATA, da doch empfehlenswert um 16 Ports zu erreichen?)

nein ja

Er steckt eine PCIe 2.0 x4 10GBLan Karte (4x 500MByte/s = 16000MBit/s) in einen PCIe 3.0 x2 Slot (2x 1GByte/s =16000MBit/s) und wundert sich über Performanceprobleme bei 10GBLan Übertragungen (10000MBits/s). (Die Sache mit dem bidirectionalen Datentransfer lasse ich mal außen vor.) Dabei sagt er doch selbst, daß der Slot nur x2 ist und somit läuft die Karte darin nur im PCIe 2.0 x2 Modus = 2x500 MByte/s = 8000MBit/s = ca. 8GBit/s. Und das ist ja auch die Performance, die er dann mit seinem iperf (5 Verbindungen gleichzeitig) Test erreicht. Vielleicht sollte er das mal mit einer PCIe 3.0 Karte versuchen (die dann aber eben mehr Strom schluckt) Ansonsten ein nettes Video mit interessanten Denkanstößen und viel zu viel Werbung für das kurze Video.

Naja, da ich zfs eben nur da verwende, wo ich Datenträger miteinander koppeln will, beschränkt sich das bei mir nur auf die paar Pools. Im maximum ist das bei mir ein pool mit 2x18TB und ein Pool mit 3x8TB (=16TB Nutzkapazität). Zusammen wären das rund 52GB. Damit habe ich dann immer noch einen Haufen RAM. Wobei dei Aussage 1GB pro 1TB eine sehr grobe Angabe ist. Da das dynamisch ist (je nachdem was man auf dem zfs System macht) kann das auch weit weniger sein oder auch mehr. Da unraid zfs bisher noch nicht vollständig eingebaut hat, sind noch gar nicht alle Funktionen wirklich per unraid WebGUI erreichbar (Snapshot, Deduplizierung...) und deshalb gehe ich auch davon aus, daß der Ram Bedarf sogar geringer ist. Bevor es falsch aufgefaßt wird, ich habe von Linux annähernd keine Ahnung! Ich bin auch ein WindowsIndianer und pirsche seit ein paar Jahren durch den unraid Wald. Wo es nicht anders geht muß ich mich zwar auch mal mit der einen oder anderen Linux Begebenheit beschäftigen, aber ansonsten ist für mich Linux noch immer eher fremd. korrekt. Ich bin erst sei unraid 6.9.x dabei und da war der Verbund eben nur mit btrfs möglich. Deshalb hatte ich das anfangs genutzt. Ob es vorher mit anderen Systemen (Reiserfs) möglich war entzieht sich meiner Kenntnis. Ich greife nicht mehr zu btrfs, weil ich Bedenken habe. Nicht so ganz: Ich habe im Array xfs Ich habe in Pools mit mehr als einem Datenträger zfs Ich habe in Pools mit nur je einem Datenträger xfs. Und um Dich noch mehr zu verwirren: Ich habe eben mehrere Pools in meinen Systemen.

btrfs neigt dazu im Laufe der Zeit irgendwann mal Probleme zu bereiten. Du kannst machen, was Du willst, mir waren die diversen Problemmeldungen hier im Forum dann doch zu viele. Seitdem: einzeldatenträger xfs. Wenn man Koppeln will zfs. Ich nutze auch einen schön komplexen Zahlen/Buchstabenwirrwarr. Mir reicht das aktuell auch. Ich habe mit Absicht einen Bogen um deutschsprache Besonderheiten gemacht. Aber ansonsten ist mir da nichts bekannt. Beachte nur, daß bei einer versehetlichen Verwechselung von deutscher und englischer Tastatureinstellung vielleicht einige Zeichen wo anders sind und man die Vertauschung z und y vielleicht nicht sofort bemerkt. Da ich das Problem mit Absicht umgangen habe, wirst Du es mir vielleicht sagen, wenn Du darauf stößt. 😁 Ich habe mich nicht genauer zum kryptografischen Stand der Dinge informiert, sondern eiinfach das genutzt. Klar kann man es immer noch die eine oder andere Stufe stärker oder doppelt verschlüsseln, aber für meine Zwecke wird das schon reichen. Ich mache mir aber auch nicht die NSA, BND, Mossat oder den BKA zum Feind (soweit ich weiß) 😅 Ja, viele einzelne Disks = jede xfs Es muß nicht "unglaublich viel" sein, aber ja, zfs zieht aus einer größeren Menge Ram einigen Nutzen. Da ich meine unraid Systemen sowieso auf maximum Ram aufgerüstet habe sehe ich bei mir kein Problem. Irgendwo las ich mal pro 1TB Datenträger sollte man 1GB Ram bereit halten. Aber damit wäre mein 2x18TB zfs Pool in meinem 128GB Ram System immer noch kein Problem. Habe mich aber bisher nur oberflächlich mit zfs beschäftigt und brauche dessen Spezialfunktionen (zB. snapshot) bisher nicht. Dachte ich anfangs auch, als unraid noch kein zfs beherrschte, war btrfs unter unraid die Wahl, wenn man mehrere Datenträger zu einem verbinden wollte (Raid). Doch im Laufe der Zeit las ich hier von immer mehr Problemberichten, die sich dann doch auf ein Problem mit btrfs zurückführen ließen. Bei zfs gibt es zwar auch problemberichte, doch sehe ich da bisher eher, daß Leute mit Sonderfunktionen experimentiert haben und dann Probleme auftraten. Ganz selten ist man ein zfs Verbund von urnaid nicht mehr automatisch erkannt worden, aber oft gab es dafür auch einfache Lösungen. Ich habe alle meine btrfs Verbünde auf zfs umgestellt und bisher keine Probleme deswegen. Ich sollte aber auch eingestehen, daß ich vorher mit btrfs auch eine Probleme hatte nur eben wengen der Berichte dann doch sicherheitshalter umgestellt habe. Sollten einem die Daten wichtig sein ist ein (oder mehrere) Backup(s) sowieso weiterhin wichtig! Ich sehe zfs bei Einzeldatenträgern unter unraid als nicht erforderlich an und bleibe erst einmal bei Einzeldatenträgern bei xfs, solange sich da nicht irgendeine wirklich wichtige/wünschenswerte Zusatzfunktion eine anderen Filesystems zeigt.

Ja, kannst Du (xfs-enc kann man auswählen) Sollte es wirklich nur um eine Verschlüsselung für genau den oben von Dir benannten Zweck gehen, wäre es sogar okay den Key(file) direkt bei unraid abzulegen. Solltest Du Angst vor irgendwelchen Hausdurchsuchungen oder Diebstählen haben, solltest Du dann den Key(file) für die Verschlüsselung aber nicht direkt im System speichern. (einige Leute scheinen einen zuvor dort abgelegten den Key von einer andern Webinstanz zu holen, weshalb ein Offline-starten dann nicht [so einfach] möglich ist, oder gar den Key auf einem smartphone zu haben, welches dann beim start von unraid dort ausgelesen wird. So kann ein entwendetes System mit vertretbarem Aufwand von Fremden nicht ausgelesen werden.) Da das Array/Pool ohne den Key nicht laufen, kann es aber sein, daß Du sich ggf. sogar selbst aussperrst. Ich sehe dazu keine Notwendigkeit. Unraid kann selber die Standardverschlüselung nutzen. Bei Einzeldatenträgern (Array und Pools mit einzelnen Disks/SSDs) wäre dann xfs encrypted sinnvoll Bei Pools, die aus mehreren Datenträgern bestehen wäre dann zfs encrypted sinnvoll. btrfs und reiserfs sind besser zu meiden.

Das ist individuell. Ich spreche hier von meinen Anforderungen: Ich hantiere auf einem meiner Systeme (1st System Tessa) gerne mit großen Datenmengen (3-4TB an einem Stück auf das unraidsystem über SMB zu schreiben ist dann schon an einigen Tagen üblich). Da solche Datenmengen dann doch auf die Dauerschreibfestigkeit von Pool/Cache SSDs geht, haben bei mir in diesen Extremfällen die VM/Docker angefangen träger zu reagieren (zeitverzögert). Da mich das gestört hat und auch zeitkritische Anwendungen in einer der VM liefen (Downloads & Par Berechnungen) habe ich ziemlich früh dazu tendiert die Systemshares (für VM/Docker) auf einen getrennten Pool/Cache/SSD zu legen und meinen Pool/Cache für mein Array dann auf eine andere SSD(s) abzubilden. Das Ergebnis ist, daß ich auf a) einem unraid, bei dem ich geringere Datenmengen schreibe (2nd System Shipon, siehe Signatur) eine alte Samsung 970 Evo 256GB in einem Pool/Cache für Systemshares nutze und eine AData Legend 960 (max) 4TB in einem anderen Pool/Cache zum Puffern für mein Array (Vorher hatte ich anstatt der AData 3x2TB Samsung 970 Evo Plus per zfs zu einem 6TB Cache zusammengeschaltet). b) einem anderen unraid (1st System Tessa), welches ist eben am Stück auch mal mit 3-4TB voll pumpe) die Systemshares auf einer Samsung 970 Evo Plus 2TB liegen habe und auch hier eine AData Legend 960 (max) 4TB den Pool/Cache für das Array bildet. Da dieses System auch generel höhere Anforderungen hat, habe ich sogar noch weitere Pools angelegt (3x8TB Samsung QVO zfs raid5ähnlich & 2x 18TB Festplatten zfs raid0ähnlich)

Okay, man wird es im Selbstbau nicht so kompakt/elegant hinbekommen 8x 3,5 inch zu erreichen und die selben Features (Wechselrahmen...) zu bekommen, aber 900 Euro sind schon ein gutes Budget um sich da etwas gutes selber zusammen zu bauen. Hier kann man aber nur die Hardware betrachten. Aufgrund der neuen und höheren Lizenzkosten von unraid muß man aber so langsam auch beginnen diesen Preis mit einzuplanen und dann sollte man bei 8 Devices 129 oder gar 249 US$ nicht unbedingt vergessen.

zfs hat einen größeren RAM Bedarf und Lime ist noch nicht so ganz final fertig mit der Integration von zfs. Es arbeiten bei unraid aber eben nicht 2 Festplatten gleichzeitig an der selben Operation.

Der Tipp ist: einen groß genugen Pool/Cache ( + etwas Reserve) zu haben, dann speichert man eben nicht direkt ins Array, sondern schreibt erst einmal in den vorgeschalteten Pool/Cache, welcher dann Timergesteuert per Mover in aller Ruhe ins Array übertragen wird. Wenn Du von 'bis zu 500GB' an einem Tag ausgehst würde ich 1TB im Pool/Cache vorschlagen, wenn Du täglich den Mover (nachts?) laufen läßt. Wenn Du den Mover nur alle 3 Tage laufen lassen willst sind dann eben eher 1,5 bis 2TB zu veranschlagen. Solltest Du pro Woche nur 500GB speichern wollen (weil es eben nur ab und zu die Menge ist), kannst Du das alles ja anpassen (dann sollte eben wieder eher so 1TB reichen, wenn DUudann in der Woche ein oder 2 mal den Mover anwerfen läßt).

Der Grund aktuell zfs im Array zu verwenden --- das erschließt sich mir nicht. Ich kann Dir jetzt nicht sagen, warum der performanceunterschied so groß ist, aber unraid ist eben kein sehr flottes System, dafür aber stromsparender (wenn man es richtig anwendet). unraid ist kein Raid und kann deswegen auch mit 2 Disks nicht schneller lesen, weil sie (wenn überhaupt) nacheinander gelesen werden. Deshalb nehme ich das Plugin "Cache Dirs" zu Hilfe. Das puffert die Ordnerstruktur sehr weitgehend zwischen, so daß die wirklichen Zugriffe nur minimal sein müssen (solange der Zwischenspeicher ausreichend groß ist).

Gute. Theoretisch könntest Du also auch Dein Array einfach mit Deinen Disks erstellen und die Backups in einem Rutsch einspielen. klar. Es macht Sinn eine Parity zuzufügen, wenn Du meinst einen Ausfallschutz zu brauchen. Du kannst die Parity sogar weglassen (dann schreibt es sich auf das Array schneller) aber dann exististiert bei Dir keine Sicherung gegen Festplattenausfall.

Ich glaube so langsam zu verstehen, was Du machen willst. Bitte korrigiere mich, wenn ich falsch liege: a) Du hast ein bestehenden Windows-Server, dessen Festplatten Dir gehören, aber die eben auch voll mit Daten sind (3x 12 TB, 2x 16 TB, 1x 18 TB und 1x 20 TB). b) Du willst nun unraid aufsetzen und leihst Dir dafür Festplatten um ein Array aufzubauen (ein Gemisch mit zusammen ca. 25TB freier Nutzkapazität). c) Nun willst Du die Daten erst einer einzelnen Disk aus Deinem Windows System ins Array verfrachten. (Beispielsweise die 20TB Disk) Dazu schließt Du die Disk einfach an unraid an und mountest sie außerhalb des Array per unassigned Devices (UD). d) wenn die Daten ins Array kopiert/verschoben wurden, kannst Du diese ehemalige 20TB Windows Disk aus den UD unmounten und ins Array einbinden. unraid löscht die Disk und Du kanst sie dann formatieren lassen. Danach hast Du deren Platz im Array wieder als freie Kapazität. e) und dann das Spiel mit der nächsten WIndowsDisk (18TB) wiederholen, da ja nun wieder freier Platz im Array vorhanden ist. f) - x) Das geht dann solange so weiter, bis alle Disk des WindowsServers in unraid sind. y) Am Ende sollen die geliehenen Festplatten wieder leer geschaufelt werden, z) damit Du wie aus dem Array entfernen kannst und Deinen Spender zurückgeben kannst. Sehe ich das richtig? Gundlegend funktioniert das gut, ist aber seeeeeeeeeeeeeeeehr zeitaufwändig. Wenn Du während der "Füllaktion" auf die Sicherheit einer Parity verzichten kannst, geht es etwas schneller, da Parity stark ausbremst. Achtung! Wenn Du später eine Paritydisk in das Array mit den beschrieben Disks einbinden willst: die Paritydisk muß mindestens so groß sein, wie die größter Festplatte mit Nutzdaten im Array. Da Du nur eine 20TB Festplatte hast, solltest Du dann vielleicht in Punkt c mit der 18TB beginnen oder vielleicht sogar von klein nach groß die Daten ins Array migrieren. Denn Deine 20TB würde dann ja die Parity. Ansonsten: das da oben ist eigentlich genau der auszuführende Ablauf. Um später die geliehenen Disks wieder leer zu bekommen ( Siehe Punkt y ) kannst Du dann Tools wie unbalance oder mc oder krusader oder so nutzen um von den betreffenden geliehenen Disks die Dateien auf die Disks zu verschieben, die im Array verbleiben sollen. Um dann die Disks zu entfernen (welche Du Deinem Spender zurückgeben willst) kannst Du einfach dann mit dem Tool "new config" das Array auflösen und mit den Festplatten neu aufbauen, die Du drin lassen willst (das wäre dann Punkt z ). Und dabei kannst Du dann auch Deine Paritydisk mit festlegen und die Parity erstellen lassen (vermutlich eben auf der 20TB, die dabei komplett überschrieben wird) Und hier eine sehr wichtige Anmerkung: Das wäre dann eine umfangreiche Aktion ohne Netz und doppelten Boden! bei jedem der Schritte kann etwas massiv schief gehen und Du kannst Daten verlieren. Du solltest wirklich darüber nachdenken Dir ein Backup der Dir wichtigen Daten extern anlezulegen. Falls ich etwas falsch verstanden habe: Sorrrrrrrry! War keine Absicht!