hawihoney

Why no RC2 announcement in the Announcement thread? Came here by accident.

Nein, die neue Platte wurde nur gecleart. Eine geclearte Platte kann ohne Parity-Operation zum Array hinzugefügt werden. Das liegt an der Art der Parity-Kalkulation innerhalb Unraid (XOR-Even). Eine 0 stört nicht. Erst beim Formatieren wird die Parity aktualisiert. Du kannst das auch an Deinen Read/Write Werten sehen. Wäre die Parity beim Clearen im Spiel, dann wären das Millionen Zugriffe.

Danke, genau das hatte ich befürchtet. Genau dieses Feature hatte mich vor einem Dutzend Jahren auf Unraid aufmerksam gemacht und ist für mich auch heute noch das Schlüsselelement von Unraid.

Kann man mit ZFS eine Plattenkonfiguration ähnlich des Unraid Arrays erstellen? Konkret geht es mir um das Unraid Array Feature, dass selbst beim gleichzeitigen Ausfall vieler Platten, die verbliebenen Platten, auch ohne Parity, noch zu lesen sind. Vielen Dank.

Klick im Browser mal auf den Main Tab in der Unraid Gui - selbst wenn Du dort schon stehen solltest. Vielleicht wurde die Seite nicht aktualisiert. Mach mal Screenshot der Main Seite und poste ihn hier. Diagnostics Datei würde auch nicht schaden. Der clear macht nix außer alle Bits der neuen Platte auf 0 zu setzen. Sie kann anschließend ohne eine Aktualisierung der Parity eingeklinkt werden. Erst mit dem anschließenden Format der neuen Platte wird auch die Parity aktualisiert. Nach dem Einsetzen der neuen Platte muss das Array nicht mehr runtergefahren werden. Siehst Du denn den Format Button? Hast Du encrypted XFS als FS angegeben (vor dem Format links auf die Disk klicken).

Formatted with type 2 protection kann der Auslöser sein. Habe ich ewig nicht mehr gesehen. Vor Jahren mussten diese zunächst Low Level formatiert werden. Wie der aktuelle Status ist weiß ich nicht.

Sofern es sich um Motherboard, CPU, RAM, etc handelt - also Hardware wie von Dir gefordert: Einfach den alten Stick in die neue Maschine stecken und gut ist. Sofern Du beim Umzug auf die neue Hardware die Platten- oder Share-Konfigurationen ebenfalls änderst, tja, dann musst Du Hand anlegen. Deine Auflistung oben lässt sich nur begrenzt eindeutig beantworten. Container Konfiguration liegt bis 6.9.x auf dem Stick, Container Daten liegen dort wo Du sie hingelegt hast (Docker Settings bzw. Container Settings). Das kann Cache/Pool, Unassigned Devices oder auch Array sein. Plugins --> Stick, VMs (ebenfalls laut VM Settings), etc

Was ist die Motivation? Stromsparen für 1:45h eines 2:00h Films? ~10W? Da gibt es so viele unbedachte Störfaktoren: Wer kümmert sich ums Aufräumen auf dem Cache? Wenn im RAM, Du pausierst den Film und andere Jobs kicken den Film raus oder Du denkst nach 15 Minuten "Was für ein beschissener Film" und löschst ihn, hast aber 30 GB zuvor nutzlos kopiert? Und zum Schluss läuft Docker nicht mehr, da doch etwas auf dem Cache vergessen wurde ... Mehr esoterisches fällt mir im Moment nicht ein ...

Look at this post for details (cables, HBAs, backplanes) on using Supermicro storage boxes (JBOD/DAS) and backplanes. It looks different now, but is working since years. Notes about power draw and loudness still apply:

HDD temps only for spun-up disks:

Das war nicht Deine ursprüngliche Frage. Was willst Du denn genau machen?

Ja, die ZIP-Datei mit dem USB Creator Tool aus dem Download Bereich von Unraid einfach auf einen anderen Stick übertragen. Lediglich die Lizenz-Datei passt dann nicht mehr zum Stick. Also nach dem Übertragen auf einen neuen Stick muss die Lizenz von dem alten Stick auf den neuen Stick übertragen werden. Der alte Stick wird dann durch Unraid "geblacklistet".

Das gibt es so nicht. Entweder: /mnt/user/ für User-Shares oder /mnt/diskn/ (n sind 1-2 Ziffern) für Disk-Shares oder /mnt/disks/ für Unassigned Devices lokal oder /mnt/remotes/ für Unassigned Devices remote.

Nur der Vollständigkeit halber: Auch bei den anderen Write-Alternativen werden Datenplatten gelesen - in diesem Fall aber alle anderen. Es entfällt das Lesen der zu beschreibenden Daten-Platte (was Performance einspart durch das fehlende Warten auf den Schreib-/Lesekopf zwischen Lesen und Schreiben an der gleichen Stelle) und das Lesen der Parity-Platte(n).

Aus der Ferne schlecht zu erklären: 1.) Bitte benenne die von Dir verwendeten Quelle und Ziel in der Form /mnt/disks/... --> /mnt/.... Die Punkte musst Du natürlich entsprechend füllen. 2.) Öffne die Konsole und gib folgende Befehle ein. Was ist das Ergebnis? Ein erster Unterordner mit der jeweils ersten Datei reicht - nicht alles posten: ls -lisa -R /mnt/disks/.../ | more ls -lisa -R /mnt/.../ | more

Du irrst Dich. Nach Deiner Erklärung dürfte beim Schreiben einer Datei auf eine Datenplatte das Folgende nicht passieren. Wie erklärst Du Dir die Lesezugriffe auf die Datenplatte beim Schreiben: Natürlich gibt es einen existierenden Datenblock auf der Datenplatte. Der soll ja überschrieben werden. Der kann leer sein oder bereits Daten enthalten. Durch das Lesen werden die Unterschiede zwischen dem neuen Datenblock und dem alten Datenblock gefunden. Dazu wird der passende Parity-Block gelesen und dann binär abgeglichen. Dann erst werden Daten- und Parity-Platte geschrieben. Probiers mal aus. Schreib einfach mal eine Datei. Es gibt Lese- und Schreiboperationen auf Daten- und Parityplatte(n).

Es steht sogar auf dem Screenshot den Du gepostet hast. Alle weiteren, tiefergehenden Details sind ebenfalls im Einzelnen beim Docker Subsystem oder beim Unassigned Devices Plugin aufgeführt. Wenn man weitergehende Anforderungen hat muss man sich halt intensiver mit der Materie beschäftigen. Die Matrix aus allen verknüpfbaren Informationen kann man nicht 1:1 mundgerecht irgendwo niederschreiben.

Theoretisch geht das alles. Außer /boot, /mnt und mit Ausnahmen /tmp ist aber nix von Bedeutung im root für einen Container. Im speziellen Fall (Unassigned Devices mit /mnt/disks und /mnt/remotes) ist /mnt im Data Path völlig ausreichend. BTW, ich nutze ausschließlich die Konsole für umfangreiche Dateioperationen

Lies mal den Text unter Data Path. Den musst Du umstellen von /mnt/user auf /mnt damit Du /mnt/disks erreichen kannst.

Nur geraten: Manchmal muss ich den Container neu starten, damit Änderungen innerhalb mnt sichtbar werden. Wie gesagt, nur ein Versuch wert.

Ich bin mir nicht sicher ob das in den Jahren mal geändert wurde, aber das ist mein alter Wissensstand zu dem Thema:

With a proper design/layout of the usage of system resources that's no problem. That's what I wrote exactly: "Cache/Pool-Writes". That does include Cache/Pool-Reads as well.

Absolut normal. Beim Rebuild wird jedes Bit mit dem kumulierten Wert aller Platten an dieser Stelle geschrieben. Die alte Platte hatte die Werte seit dem letzten Neustart. Hab gestern eine 12 TB Daten-Platte als Ersatz eingebaut. Die steht bei 31.089.128 Writes.

Brauch ich eh nicht. Aber wie muss ich mir das vorstellen? Ich lege einen ZFS Pool an und darauf dann was?

Ist das nicht das Dateisystem, das identische Platten benötigt? Wie auch immer. Nach 13 Jahren mit dem Unraid Array bin ich ein großer Fan von diesem. Extrem stabil, nicht ein einziges Problem in all den Jahren. Ich spekuliere darauf, dass das Unraid RAID-4 Array in Zukunft eine Option bei der Wahl der Ausfallsicherheit in den Pools wird. Solange warte ich. BTRFS ist, wie Du weißt, nach diversen Ausfällen hier, ein absolutes NoGo.