hawihoney

@DataCollector hat das alles leider falsch wiedergegeben. In meinen beiden Posts über seinem stehen die aktuell korrekten Mount-Points sowie die Hinweise zum verwendeten Disk-Label. Eine in UD eingeklinkte Disk findest Du natürlich unter /mnt/disks/.

Guck genau hin. UD hat einen Teil der Device-ID verwendet - in diesem Fall die Seriennummer.

Nein, /mnt/addons/ --> reserviert für Deine eigenen Mounts /mnt/remotes/ --> UD z.B. SMB Mounts /mnt/disks/ --> UD Drives /mnt/diskx/ --> Array Drives /mnt/user/ --> User Shares /mnt/user0/ --> User Shares ohne Cache m.M.n. deprecated

Ggfs. User Shares abgeschaltet? Zu finden in den Einstellungen unter Global Share Settings.

Welcher Content? Die 980ti kann nur ein H265 Profil encoden (Basis). Die 5 weiteren kann sie nicht. Also im Zweifel Mediainfo (nur das Profil) bei einer Anfrage beifügen.

Du bekommst eine Text-Mail mit einer Rechnung und eine Text-Mail mit dem Link zum Download der Lizenz-Datei. So war es jedenfalls bei meinen letzten Bestellungen. Wen sollte das interessieren? Als Limetech noch Server anbot hatte ich zwei professionelle Rechner bei denen gekauft und über den Teich schicken lassen. Hab das alles für meine Firma übers Finanzamt laufen lassen inkl. Zoll/Shipping. War halt nur blöd wegen der fehlenden Vorsteuer. Aber das interessiert das Finanzamt dann auch nicht. War ja mein Problem.

Stupid question: Consider a 4-disk Unraid Array built from 2x Parity-Disks and 2x Data-Disks. And now consider the two Data-Disks fail. Will the two remaining Parity-Disks emulate both absent Data-Disks? I'm pretty sure that this will happen because of different P+Q calculations, but I can't find a confirmation for this special case. Thanks in advance.

Ich weiß ich bin pingelig: Du schreibst für diesen Fall, dass noch eine Daten ausfallen darf. Und ich habe ergänzt, daß statt einer Daten die zweite Parity ausfallen darf. Um mehr geht es nicht.

Ich gehe eigentlich davon aus, dass es egal ist welche Platte ausfällt. Habe aber im Moment keine Quelle. Im Unraid Manual wird immer vom Ausfall von Datenplatten geredet - deshalb wahrscheinlich die Unsicherheit. P und Q werden unterschiedlich kalkuliert damit genau das abgefedert wird. Ich finde das aber nicht mehr.

Nee, es kann auch statt einer weiteren Daten die zweite Parity ausfallen. So jedenfalls mein Verständnis von Dual Parity und genau darum geht es ja in diesem Thread. Oben wurde sehr oft nur der Ausfall von Daten-Platten als ok genannt. Ich ziele darauf ab, dass es egal ist welche Platte ausfällt. Darum ging es mir. Das ist IMHO missverständlich. Ist eine Parity weg, darf auch noch die zweite Parity ausfallen oder eine Datenplatte.. Allerdings frage ich mich gerade was passiert wenn nur noch zwei Parity-Platten in einem 4-Drive Array übrig bleiben. Ich denke das müsste auch gehen - würde aber nicht Haus und Hof darauf verwetten.

Hmm, das würde mein Unraid-Array Weltbild zerstören. Mein Verständnis bisher: Im Unraid-Array dürfen soviele Platten (egal ob Parity oder Daten) ausfallen wie Parityplatten vorhanden sind. Erst mit einer weiteren ausfallenden Platte beginnt dann der Datenverlust. Sollte ich damit all die Jahre falsch gelegen haben? Am Beispiel Dual-Parity im Unraid-Array: 1. Fällt eine Parity aus passiert nix 2. Fallen beide Parity aus passiert nix 3. Fällt eine Daten aus passiert nix 4. Fallen zwei Daten aus passiert nix 5. Fällt eine Parity und eine Daten aus passiert nix 6. Bei jeder weiteren Konstellation beginnt Datenverlust.

Hier sind ein 9300-8i und zwei 9300-8e im Einsatz. 1x Amazon, 2x eBay. Die Dinger sind von Hause aus HBAs - im IT mode. Man muss sie firmware-seitig upgraden um RAID Support zu bekommen. https://docs.broadcom.com/doc/12352000 Den aktuellen Zustand der Firmware kann man erkennen durch Download des letzten Firmware Release für den HBA und dem Ausführen des sas3flash Utilities. Hier die Vorgehensweise für eine Analyse. Es reicht sas3flash -list um den Modus zu erkennen (Firmware Product ID😞

Achtung: Hat Dein Array eine oder zwei Parity-Disks? Wenn ja, dann gilt der o.a. Link. Ansonsten musst Du anders vorgehen. Meld Dich dann noch mal.

Ggfs. hilft es mal den Browser Cache zu leeren. Nur so eine Idee.

Nur zur Info: Im LSIO Container funktioniert das auch ohne den trailing slash astrein:

Verstehe ich nicht. Wie wolltest Du das denn vorher lösen? Wolltest Du etwa ein ganzes Block-Laufwerk in den Container mappen? Zeig mal davon einen Screenshot.

Found that today in CA changelog. I'm eagerly waiting for Multi-Array support with my three Pro licenses. Can you please give me an idea of how much money I need to put aside if I upgrade a single Pro license to Unlimited ... 🤔

Mach mal bitte einen Screenshot von Deiner Container Einstellung zum Mount.

I know, this thread is really old. I'm currently working with an Xiaomi Android Tablet Pad5. It's nearly impossible to work with the new Notification icon on the right. These three steps to get to the individual notifications always ends in deleting all notifications here. It's to small, to fast flickering and to many steps. On a desktop this is no problem. But on my tablet it's a pain. Perhaps I'm to old but IMHO this is no good user experience. I can't reach the individual notifications on my tablet any longer. So I stopped using the tablet for the Unraid GUI during vacations because it's useless. I wait til I'm back home 14 days later and use the desktop then. Just my 0.02 Cent.

Wie der Name schon sagt: Beim Parity-Check wird die Parity gecheckt 😉 1. Bei Lesefehlern von Daten-Platten werden die Parity-Platten und die anderen Daten-Platten verwendet um den betreffenden Block auf der Daten-Platte erneut zu schreiben - ggfs. auf einen Reserve-Block - was dann wiederum ggfs. die Parity-Platte aktualisiert. Der Lesefehler wird vermerkt aber es passiert nichts weiter. Entsteht aber im Nachhinein, beim erneuten Schreiben des Blocks, ein Schreibfehler, dann wird die Platte disabled und in der Folge emuliert. 2. Bei Schreibfehlern wird die Platte disabled und emuliert. 3. Du hast Sync-Fehler während des Parity-Checks. Die Inhalte von Daten-Platten und Parity-Platten passen also nicht zusammen. Dann wird, sofern nicht abgeschaltet, die Parity-Platte aktualisiert.

Hab den Satz nicht verstanden ABER bei einem Parity-Check wird nur die Parity geändert. Die Daten-Platten haben immer Vorzug. So muss das auch sein.

Die Garantie kann Dir niemand geben. ABER: Der Ablauf der vier Operationen beim Schreiben fängt immer mit der Datenplatte an. Denn erst nach Kenntnis des beschriebenen Blocks auf der Daten-Platte kann der gleiche Block auf der Parity-Platte beschrieben werden. Zudem haben moderne Dateisysteme eine Art Transaktions-Log, das beim nächsten Boot abgearbeitet wird und nur vollständige Änderungen aufspielt. Lass einfach die Korrektur der Parity zu, damit das Array in sich schlüssig wird. Was mich nur nervös machen würde sind die über 20.000 Sync Fehler. Das ist für einen simplen Stromausfall viel zu viel. Jeder Schreibvorgang wird nämlich mit minimalem zeitlichem Versatz in der Parity abgebildet. Deshalb meine Fragen nach der Vergangenheit oder CRC-Fehlern. Hattest Du mehr als einen Stromausfall, o.ä.

Das Thema ist hier im Forum bestimmt schon 1000x hinterfragt worden: 1.) Nein, Unraid lässt nicht erkennen welche Dateien betroffen sind. Man sieht im syslog nur Tracks/Sektoren - denn nicht alles auf einer Festplatte gehört zu einer Datei (Metadaten. Verwaltungsinformationen, ...). 2.) Wenn man sich nicht sicher ist, dann spielt man ein Backup zurück. 3.) Allerdings scheinst Du nur gelesen zu haben (CRC Check) - das erzeugt keine neuen Dateien. Vermutlich hast Du das Problem schon länger oder etwas anderes hat massiv Daten geschrieben (25000 Sync Errors ist extrem viel). Schau Dir mal die SMART Werte der Platten an. Hast Du CRC Fehler? 4.) Es ist unerheblich ob eine Parity-Platte oder eine Daten-Platte betroffen ist. Wenn man kein Backup hat, dann bleibt einem nichts anderes übrig als den Parity-Check korrigierend laufen zu lassen. Die Parity-Platte muss zu den Daten-Platten passen. Durch Deinen nicht-korrigierenden Parity-Check hast Du nämlich im Moment folgendes Problem: Parity- und Daten-Platten passen nicht mehr zueinander. Wenn jetzt eine Daten-Platte ausfällt, dann wird diese garantiert mit Müll beschrieben.

Spielt denn beim Backup die Geschwindigkeit so eine große Rolle? Ich hab ein paar "Samsung Portable SSD T7" für diese Fälle. Die sind schnuckelig klein und passen in die Jackentasche. Die hänge ich einfach an den Server und starte einen rsync Job innerhalb eines User Scripts. Klar, das sind SSDs, aber von den NVMe Frickelgehäusen hatte ich eines mal in Betrieb, das war einfach nur Schrott. Die Samsung baumelt während des Backups zufällig vor dem Lüfterausgang des Gehäuses. Das kühlt die auch noch wunderbar runter: Und guck Dir mal die Vergangenheitswerte an (Data units read/written). Da wurde in der Summe ein PB bewegt. Die läuft und läuft und läuft ... Hier die Details zum Modell: Bzgl. 970 Evo Plus. Von denen habe ich zwei im Server. Einmal täglich synchronsieren die sich. Hier das Ergebnis des letzten Sync-Jobs. Nicht vergessen, da wird viel gelesen und geschrieben - also nicht kontinuierlich geschrieben. Dafür ist die Performance excellent:

Das ist so nicht korrekt. Das Verfahren ist bei allen Konstellationen identisch. Nur bei der oben genannten Konstellation führt das Verfahren zufällig zu zwei identischen Platten. Unraid nutzt zur Kalkulation des Parity-Bits "XOR-even". Das Ergebnis aller Bits aller Daten-Platten an der Bit-Position muss immer even sein, das Parity-Bit wird zur Korrektur gesetzt. https://docs.unraid.net/legacy/FAQ/Parity/#how-parity-works 0101 Daten-Platte XOR 0011 Parity-Platte = 0110 Das Ziel ist even(0). 0=0, 1=1 - nur die beiden äußeren werden even. Somit identische Bits in beiden Platten.