DataCollector

Ich meine: Raid1 im Privatumfeld ist nicht wirklich zwingend notwendig. Wen Du stattdessen Einzeldatenträger mit xfs nutzt, kannst Du die jeweils zweite NVMe nehmen als Ziel für ein Backupo. Da eine NVMe SSD in der Regel schnell schreiben kann dauert ein Backup weniger lange (= schnell) als beispielsweise auf eine mechanische Festplatte. Bei einem Raid(1) ist es so, daß ein Datenverlust wegen Programm oder Bedienungsfehler sich auf alle beteiligten Datenträger auswirkt und man ggf. gleich die betroffenen Daten verloren hat. Wenn man hingegen sporadisch ein einen Datenträger auf einen anderen backupt, kann auf dem original Datenträger ein totale Datencrash stattfiunden, aber man hat die Daten mit dem Stand des Backups dann immer noch vorliegen. Und da eine NVMe ja (hoffentlich) flott ist, dauert ein Backup eben auch nicht lange (könnte man ja nachts oder von mir aus alle Stunde automatisiert machen. Dein Backup auf die Synologie wird mutmaßlich länger dauern als auf eine lokale NVMe SSD. Dein Backup auf Die Syno wäre dann eine externe zweite Backupausfertigung, was sinnvoll ist.

Bei dem Betreff vermute ich, daß alles NVMe SSD sind. Kann man machen. Ich würde eher 1x xfs für Dokumente, etc. und 1x xfs als schnelles Backupziel nutzen der ersten SSD. Warum zfs bei einem einzelnen Datenträger? xfs wäre zu bevorzugen (wenn man nicht unbedingt die ganz speziellen Funktionen von zfs braucht, die bei Einzaldatenträgfern aber eher begrenzter sind). auch hier: Ich würde eher 1x xfs für Dokumente, etc. und 1x xfs als schnelles Backupziel des ersten Datenträgers nutzen. Raid muß im privaten Umfeld in der Regel nicht wirklich sein und erhöht den Strombedarf.

...das habe ich schon vor rund 2-3 Jahren. als ich angefangen habe gehört... mein Glaube schwindet´. Aber freuen würde es mich schon, weil die Grenze von 28+2 Festplatten im Array so langsam eine Grenze bei mir erreicht und ich eigentlich weiter machen wollte. Und das bei erst ca. 500TB.

Das klassiche Array beu unraid heißt "array". Die klassichen Pools bei unraid können beliebige Namen annehmen. Allein schon um Verwechselungen auszuschließen (weil Pools andere Fähigkeiten haben) sehe ich array und pools ebenfalls als getrennte Sachen an. Es mag sein,d ass jemand damit vielleicht den Wunsch nach Multi Array abdecken will, aber das Array ist einfach stromsparender beim Lesen von einer der 3 oder mehr Datenträger, wenn man es mit einem Raidz (raid5) Pool vergleicht. Solange die Funktionen unterschiedlich sind, sehe ich einen Bedarf der Trennung/Uterscheidung. Bei unraid ist der Begriff eines "Arrays" aber leider mit der Funktion des klassischen Array verbunden und solange ein Pool sich nicht wie das urnaid array verhalten kann bedarf es (meiner persönlichen Meinung nach) einer Unterscheidung. Auch um beispielweise Neueinsteigern nicht zu shcwer zu machen, wenn man auf die unterschiedlichen Funktionalitäten abzielt. Ein array mit >2 Datenträgern kann sehr viel stromsparender (und langsamer) sein als ein Pool mit gleich vielen Datenträgern im zfs basierten RaidZ (vgl. Raid1, 5 oder 6) Verbund. Eigentlich sind sie zur Zeit eindeutig klar und aufgrund der Unterschiede eher nicht verwirrend. Wenn man aber array und pool beides "arrray" nennt und einem User versucht klar zu machen, wann man die Vorteile (und Nachteile) eines klassischen array hat und wann man die eher gegensätzlichen Vorteile (oder auch Nachteiles) eines Pools hat ist die Unterscheidung sogar sehr wichtig um eben nicht extra zu verwirren, wenn man dann beides einfach array nennen würde.

Ist der aktuell nicht im Beta Test? Bist Du Betatester? Dann frage doch Deinen Betreuer für den Betatest. Wenn es Probleme gibt sind die bestimmt interessiert das Ding besser zu machen. https://telekomhilft.telekom.de/conversations/labor-pinnwand/beta-test-speedport-7-testerinnen-und-tester-gesucht/6874c02880b775090902559e

Das sich xfs beiweiten seltener als Problemursache herauskristalisiert bei zurvor unerklärlich erscheinenden Problemen. Wenn hier im Forum irgendwelche Probleme beschrieben werden,taucht nicht selten als Ursache im Rahmen der Recherche btrfs (bzw. damit im Zusamnmnenhang stehende Fehler) auf. Deshalb habe ich alle Pools im Raidverbund von btrfs auf zfs umgestellt und auch meine Docker VDisks auf xfs. Ich empfehle weiterhin für unraid: Single Datenträger (also auch Array und hier auch Docker vDisk): xfs. Wenn man mehrere Datenträger miteinander verbinden will: zfs. Da Du Deine ursprüngliche btrfs vDisk leider entfernt hast ist eine nachträgliche Analyse nicht mehr möglich.

Ich würde sowieso kein btrfs nutzen. xfs Image funktioniert bei mir auch als vdisk für Docker bisher ohne Probleme.

Was spricht dagegen die Gewährleistung des Händlers zu nutzen, welcher das vor rund nur 2 Monaten gelaufe Modul eben tauschen soll?

Ich mache sowas mit mc. Da habe ich eigentlich keine Zugriffsprobleme, selbst wenn ein sabnnzb (ich777) mal wieder ein Unterverzeichnis angelegt hat das ich über SMB oder so nicht löschen kann (und die darin enthaltenen dateien auch nicht).

Bei überdimensionierten Paritätsplatten dauert es unnötig lange. Das ist korrekt. Bei einer 24TB D + 24TB P Konstellation im Array hat man zwar nur eine einfache Ausfallsicherung bei abe auch nur 2 möglichen Platten, die ausfallen könnten. Bei Deiner kKonstellation hast Du doppelte Ausfallsicherheit, dabei aber auch erhöhte Wiederherstellungszeit und doppelt soviele Festplatten die ausfallen können (Ausfallwahrsheinlichkeit +100%). Und die kleineren Festplatten kann man ja zusammen als USB Backup nutzen und hat damit zusätzlich ein Backup, falls mal das ganze Array abschmiert. Als ich mich vor Jahren damit beschäftigt hatte stand das (glaube ich) im Syslog. Das hatte ich angenommen, da erst in letzter Zeit überhaupt 24TB halbwegs preisgünstig zu haben sind. Da ich ein (bzw. 2) Backup habe und zusätzlich auch Checksummen zur Kontrolle der Dateien nutze darf das System gerne die Parity korrigieren/überschreiben. Ich lasse ja sowieso ab und zu das Backup abgleichen und/oder prüfe die Checksummen. Eine defekte/veränderte Datei im Array fällt bei mir ggf. bei einem der Abläufe auf. Erwähnte ich schon, dass eine Parity nicht vor Datenverlust schützt? Backup ist das Zauberwort. (und wenn einem die Daten wirklich wichtig sind, ggf. mehrere Backups)

Das kann passieren. Das erklärt die lange Zeit für den Paritycheck. Ich verwende seit kurzem 28TB HAMR Platten als Parity und brauche auch rund 2 Tage. Also hast Du 14+8TB Nutzkapazität = 22TB. Wären da nicht 1x Parity 24TB und 1x Daten 24TB nicht sogar mehr Speicherplatz und (weil nur 2 Platten) auch stromsparender und als 1P+1D Array erheblich schneller? Die verbleibenden beiden Platten (14 +8TB) kannst Du extern für Backups nutzen. Falls Du damit die Paritätsplatte und Datenplatten meinst: Zumindest nicht ohne zusätzliche Maßnahmen. Falls Du damit die "Daten" im Sinne von Dateien meinst: Die Datenfestplatten enthalten mehr als nur Deine Dateien. Es können auch Bits im Bereich der Metadaten betroffen sein (Zeitstempel, Attribute, Dateisystemverzeichnis, etc...). Also ich habe das vor Jahren mal verfolgt und im Systlog waren die betroffenen Sektoren verzeichnet. Problem wäre nur auf jeder Festplatte diese Sektoren zu lesen und zu schauen, was drauf ist. Wenn die Fehlersektoren aber >14TB Kapazität liegen ist es bei Deinem Aufbau definitiv etwas auf den Parityplatten und nicht auf den Datenplatten. Sektorfehler auf physikalisch erkennbarer Ebene werden (beim Erkennen) in den SMART Werten verzeichnet. Da bei dem Paritychek alle Sektoren gelesen wurden ist es unwahrscheinlich, daß zumindest Lesefehler auf physikalischer Ebene nicht verzeichnet wurden. Wenn Du wirklich die Festplatten testen willst kannst Du die aus dem Array ausloggen und unter totalem Datenverlust auf dem Datenträger per Preclear testen. Ich selber mache Sektor Schreib- und Lesetests aber lieber mit HDTunePro unter Windows auf einem extra PC. Bin hier eben eher ein Fan von GUI mit bunten Kästchen, die im Fehlerfalle sofort rot angezeigt werden. 8)) Aber nach Diener Beschreibung: Ich glaube nicht, daß eine der Festplatten wirklich ein Sektorproblem hat. Und nur zru Sicherheit: Parity schützt nmicht unbedingt gegen Datenverlust. Ein geeignetes Backup ist hier das Zauberwort.

Bei Benutzung der PCIe Slots/M.2 direkt an CPU angeschlossen, kann es immer sein, daß die Strromsparmaßnahmen strark verschlechtert werden. Du willst eine dGPU einsetzen (vermutlich in einem solchen PCIe Slot) , somit wird die Energieeffizienz schlechter ausfallen. Wenn Du das alles Onboard willst: Da bleibt bei einer Filterung bei www.gh.de (ich hasse deren neue GH Filter!!!) nur noch ein Mainboard übrig: (Ich gehe wegen der Energieeffizienz einfach mal von einem S1700 System aus) https://geizhals.de/msi-meg-z690-unify-a2625601.html?hloc=de MSI MEG Z690 Unify (7D28-001R) 1x PCIe 5.0 x16 1x PCIe 5.0 x16 (elektrisch x8) 1x PCIe 3.0 x4 3x M.2/M-Key (PCIe 4.0 x4 2280/2260) 1x M.2/M-Key (PCIe 4.0 x4 22110/2280/2260) 1x M.2/M-Key (PCIe 3.0 x4 2280/2260) 1x M.2/M-Key (PCIe 4.0 x4 2280/2260) 1x M.2/E-Key (2230, belegt mit WiFi+BT-Modul) 4x SATA 6Gb/s (Z690) 2x SATA 6Gb/s (ASMedia ASM1061) Die Sache hat aber einen Pferdefuß: MSI - ist bisher nicht als sehr effizient aufgefallen. Aber bei der Bestückung mit zusatzsteckkarten wird das System sowieso ein Stromschlucker. Auch ist es ein DDR5 Board. Du kannst dort Deine bisherigen DDR4 Module nicht einsetzen (wären aber auch für ein DDR4 S1700 System wohl etwas langsam). Wenn Du evtl. die 6 SATA per Zusatzkontroller (ASM1166 M.2 Bauweise) erreichst wären ggf. auch das https://geizhals.de/gigabyte-z790-aorus-elite-ddr4-z790-a-elite-ddr4-a2894871.html?hloc=de GIGABYTE Z790 AORUS Elite DDR4 (Z790 A Elite DDR4) möglich. Ich kann aber bei beiden Boards nichts zur Energieeffizienz/-verbrauch sagen. Mein sehr effizient gemessenes https://geizhals.de/asus-prime-z690-p-d4-csm-90mb18p0-m0eayc-a2637165.html ASUS Prime Z690-P D4-CSM (90MB18P0-M0EAYC) (mit Bifurcation!) scheidet leider aus, weil es neu nicht mehr wirklich günstig zu haben ist und allerhöchstens noch gebraucht in einem vernünftigen Preisrahmen unter 200 zu haben ist. Auch stellt einen die Bifurcation Nutzung des x16 Slot vor mechanische Probleme. Tja, ich schätze, das kann hier keiner garantieren, da man die Boards dazu getestet haben müßte. Du wirst da wohl den Vorreiter spielen, doch bei der gewünschten Endbestückung sehe ich nicht, dass das System am Ende wirklich sparsam wird, selbst wenn Du ein Wunderbrett mit unter 15W idle/nackt und Deiner Wunschausstattung findest.

Wenn die Parityplatte recht klein oder alles rasend schnell ist fällt es nicht auf, weil die ja nur ein paar Stunden braucht. Bei mir (bei meinem großen System) brauchts dann schon etwas über 2 Tage (stört mich aber auch nicht, weil alles drum herum ja über SSDs läuft)

Ich sehe/kenne keinen Hinweis, das DDR4 Neuware kürzere Haltbarkeit hat als DDR5 Neuware.

Ich tippe auf Schreibproblem beim Stick, denn im letzten Versuch hat es ja wohl funktioniert. Ja, aber es kann beim Übertragen/Schreiben immer mal etwas schief gehen. Ich empfehle ein lokales Backup des Flashsticks anzulegen und lokal zu lagern. Wenn Du im Main Tab auf den Link zum Flash Stick klickst, kannst Du ein Backup als lokale ZIP Datei erstellen und 'herunter laden'. Dieses Zip dann sicher/gut extern aufbewahren. Aber er wurde anscheinend nicht korrekt beschrieben. Das aktuelle Installationstool ist dahingehend leider fehlerhaft. Entweder mit einem älteren USB Creator von unraid erstellen oder die manuelle Methode nutzen.

Okay, ich habe den Ablauf mit der Windowssoftware beschrieben und durchgeführt. Zu dem Zeitpunkt war mir kein Linux Weg bekannt. Der Weg über Linux ist erst mit dem Entdecken der letzten Firmware bekannt geworden. Dazu kann ich nichts sagen, da ich bisher in diesen Fällen immer unter Windows geflasht habe. Unter Windows klappte das mit allen von mir verwendeten/getesteten (und in den Beiträgen verlinkten) Firmwares.

An diese Meldung kann ich mich nicht erinnern. Flashst Du unter Windows (wie in meiner Darstellung) oder nimmst Du Linux dafür?

Ich sehe schon, Du hast den ursprünglichen Beitrag nicht wirklich gelesen. Darin wird auch auf https://forums.unraid.net/topic/185255-asm1064-test-der-firmwares/ verwiesen. (Siehe auch Screenshot unten). bisher ja. Screenshot:

USB Datenträger (im Array) ist eigentlivch nicht wirklich eine gute/empfohlene Idee. Platzsparende Alternative: kleinen ITX oder mATX PC/Mainboard in ein kleines Gehäuse packen, alle Datenträger per SATA oder NVME PCIe anschließen...

Das meine ich (weiter unten) mit "Teppich unter den Füssen wegziehen". Wenn man bei solchen Aktionen über Kreuz arbeitet, kann es zu Datenverlust kommen, weil die shares mit dem Fuse System mit dem Disks verknüpft sind. ===== Zuerst eine Warnung: Meist wollen Leute innerhalb eines unraid Systemen Daten verschieben. Verschieben bedeutet im Endeffekt, dass irgendetwas von einem Ort gelöscht wird. Dabei kann es passieren, daß man von einer Disk in ein share verschieben will (oder auch umgekehrt von einem share auf eine Disk), welche durch den share (Fuse System) aber zusammen hängen. Damit kann es passieren, daß man Dateien verschieben will und sich dabei sprichwörtlich "den Teppich unter den Füssen wegzieht" (weil man im Endeffekt irgendwo etwas löscht) und dabei Datenverlust entsteht. Deshalb ist es im Normalfall nicht zu empfehlen Shares zu Disk oder auch Disk zu share zu verschieben. Man sollte bevorzugt nicht "über kreuz" arbeiten (share zu Disk oder Disk zu share). Bevorzugt immer von share auf share oder Disk auf Disk. Und wenn man über kreuz arbeitet: lieber kopieren und nicht verschieben. dann hat man bis zum Ende das Original und kann dann nochmal nachdenken und die ggf. doppelten und ungewünschten Dateien selektiv löschen. ===== In Deinem Fall sollte es aber kein Problem sein, weil ein UD Device ja keinen Zusammenhang mit einem share (per Fuse System) hat. In Deinem Fall würde ich so vorgehen, daß ich den mc oder krusader oder so verwenden würde. Da ist es einfach übersichtlicher als wenn man auf der Terminalebene mit Kommandozeilen arbeitet (finde ich). Ich bevorzuge mc. Auf er einen Seite manövriert man zum UD auf der anderen Seite manövriert man zum share. Die UD finde ich bei mir unter /mnt/disks/ (im Screenshot rechts zu sehen. Die Disk hat den Namen Leer64 (USB Stick 64GB) und enthält das für Windows verräterische Verzeichnis 'System Volume Information'. Die shares finde ich bei mir unter /mnt/user/ (im Screenshot links zu sehen. Die shares werden dort mit Namen angezeigt und man kann dort einsteigen und dann von links nach rechts oder auch von rechts nach links sehr bequem kopieren/verschieben oder auch einfach löschen. Screenshot mc (midnight commander): EDIT: Achja, da Du erwähnt hast, daß ein Verzeichnis futsch ist: Es gibt das Plugin Recyle Bin. Das ist eine Art >Papierkorb in dem gelöschte Dateien auftauchen (wenn man ihn entsprechend einstellt/konfiguriert). Ich bin jetzt nicht sicher ob solche "cross-action" Fehler auch dadurch aufgefangen werden, aber auch im Falle anderer Löschungen hat man da noch ein kleines Sicherheitsnetz. (Das ist dann dieser Ordner, der oben links im Screenshot zu sehen ist namens: .Trash-99)

Bei Problemen und dann btrfs werde ich sehr hellhörig. EDIT: Du hast aber anscheinend iene überprüfuznb gemacht udn es werden keien Fehler gemeldet. Ich hätte sonst auf Dateisystemproblem getippt. In jedem Fall würde ich mal ein Backup machen. wenn Dir die Dateien dort wichtig sind. Ja, die Einstellung des Shares dazu meine ich. Dazu ist im Pool auch noch einstellbar, wieviel frei bleiben soll. Ggf. steht dazu auch was im Syslog. kannst ja mal die diagnostics hier anbieten.

Naja auch ein Verzeichnis auf eienm Datenträger kann in eine Begrenzung (keep xxxx free) laufen oder auch der Datenträger kann voll laufen. Ist das Verzeichnis nur in einem Pool oder auch im array platziert? Wie sind die Einstellungen zu dem betreffenden Verzeichnis/Share?

Meine neue BlueWalker PowerWalker VI 1500-CSW (nicht vor unraid geschaltet) hat ein Display, welches nach einigen Sekunden abschaltet und per Knopf für kjurze Anzeige angeschaltet werden kann. In den paar Sekunden mag das Display etwas Energie schlucken, aber grundlegend finde ich es praktisch direkt davor stehen zu könne und zu sehen, was Sache ist. Das klingt schon nach ziemlich wenig. Scheint sich wohl in dieser Hinsicht gut zu machen. Leider (laut Webseite) keine vom Nutzer austauschbare Akku(s).

Man kann mehrere Bifurcation Steckkarten verbauen, aber die Bifurcation Funktion ist nur bei der CPU angeschlossenen Karte nutzbar. Eine andere Karte (in einem nicht an CPU angeschlossenen PCIe Slot), wird dann als normale PCIe Karte mit einem Device angesprochen. Der Rest liegt brach. Bifurcation ist eine Sache der CPU. Die CPU auf meinem Fujitsu D3644-B ist nur am Slot angebunden, welcher der CPU am nächsten ist. Die anderen Slots können kein Bifurcation. Es würde mich sehr wundern, wenn jemand Bifurcation auf Slots von Intel Boards findet, die nicht direkt an einer CPU hängen. Ausnahme: ist zwar nicht Bifurcation, aber mit energieintensiven PCIe Switchen kann man auch die Lanes mehrfach belegen. Das findet sich eher bei teuren Workstation oder gar Serverboards aufgelötet oder kann per Steckkarte nachgerücktet werden. Dies ist aber bei einem 24/7 laufenden NAS mit durchgehendem Stromverbrauch nicht unbedingt die sparsamste Idee.

Link? Was er will weiß ich nicht. Ich will mechanisch stabiles und belastbare 3D Modelle erreichen, da ich eher gedenke Ersatzteile oder gar Verbesserungen der eher mechanischen belasteten Natur herzustellen, die ich sonst ggf. etwas nicht mehr reparieren/ausbessern/verbessern kann. Zuletzt hätte ich gerne die untere Aufhängung für eine Kühlschranktür erstellen wollen, doch ich schätze die Punktuelle Belastung mit mehreren Kilogramm (in der Tür stehen diverse volle 1,5L Getränkeflaschen und so) bei einer gleichzeitig flachen Bauform läßt privates Amateurhaftes 3D Drucken nicht ausreichen. Und ein metallsinter 3D-Drucker ist mir einfach zu teuer. (Auch) Deshalb habe ich bisher zum klassischen Metallbau gegriffen. Da ich aber noch keinen 3D Drucker habe ist das alles bei mir zumindest graue Theorie.