Ford Prefect

wie sind die beiden externen Gehäuse denn technisch mit dem Eitedesk verbunden?...e-SATA, USB, ...?? Hat des 2-Bay für Single-Mode auch getrennte Interfaces (eines je Disk)? Welche Schnittstellen bietet das Elitedesk? ...für USB: wie viele Coontroller hängen hinter den Ports? Nein, viele raten dazu, keine externen Disks für ein NAS, ausser zu temporären Zwecken (zB Backup/Restore), einzusetzen....das Risiko, dass die Verbindung nicht stabil ist, ist sehr hoch (einschl. physischem - meist ungewolltem - Eingriff in das Verbindungskabel).

Also vielleicht, vor dem Upgrade das Array-Autostart auf AUS (Settings - Disk-Settings - Enable Autostart) ?!? Dann kann der Mover keinen Mist bauen. ich bin / bleibe aber erstmal auf RC2 bis das hier gelöst ist:

...Das sind immer zwei Schritte, wenn Du Disks tauschen willst. Hier also: die/alle Parity Disk(s) aus der Konfg entfernen (Array stop, Konfig ändern, Array start -> danach ist/sind nur die Daten-Disk(s) im Array) alle/die Parity Disk(s) wieder in die Konfig einbauen (Array stop, Konfig ändern, Array Start -> fertsch) ...physisch musst Du die Disks nicht ausbauen. Aber vertausche in der Konfig nicht die (bestehende) Daten-Disk mit Parity (oder umgekehrt). Also am besten darauf achten, die Daten-Disk(s) an ihren Sots zu belassen (ganz, ganz wichtig für Schritt 2).

...das ergäbe für mich nur Sinn, wenn Du in das system-Verzeichnis sebst weitere Dateien hineingeschoben hast. Die Blockgrössen der Dateissysteme sind nicht so unterschiedlich, dass so ein Delta zwischen Cache und Array herauskäme. ...weil - siehe oben - Du sie vielleicht vorher da reinkopiert/hinverschoben hast...mehr fällt mir auch nicht ein.

...um sowas zu vergleichen würde ich mal Netzwerk, SMB und FUSE aus der Gleichung rausnehmen wollen. Wer einen Mirror im (unraid)Pool will, wg. Verfügbarkeit, kann halt XFS nicht nutzen.

Aha.....im RC1 steht schon: Aber ich vergass: ARC ist eh der/ein Lese-Cache...hat also mit Deinem Problem nix zu tun. ...ich tippe auf das FUSE Dateisystem als Ursache für das Problem.

eigentlich ist das dynamisch. Evtl. wurde das in einem RC3 oder folgend aber fixiert? Ich bin noch auf RC2

ZFS Cache ist auch im RAM ...in Deinem Bid also RAM (17%, für unraid, Host, Docker, ...) und 73% für ZFS ..macht zusammen 90% vom nutzbaren RAM. ...oder von was sind die genannten 73% ZFS sonst her?

...käme darauf an, ws für ein zpool das ist...in einem raidz1 ist eine Disk Party...dann sind allle Daten bei 2-von-3 Disks noch da. Hast Du versucht den Pool zu importieren? ...Edit: natürlich mit allen drei Disks im system.

ZFS Cache ist RAM und wenn Du da schon bei 90% bist, was willst Du da noch tunen? Steck halt noch ein paar GB rein ...interessante Schlussfolgerungen und eigenwillige Interpretation für was/wie man unraid einsetzen kann...aber wenn es für Dich so i.O. ist...viel Erfolg weiterhin. Deine ursprüngliche Frage lies übrigens Dein Ziel nicht wirklich erahnen. Wobei ich ehrlich auch nicht sagen kann, warum der zpool bei Dir eingebrochen ist. Ich hab auf nem zraid mit 3TB Disks seinerzeit 700MB/sec über den ganzen pool, mit nur 8GB RAM (Debian ...ca. 10 Jahre her) gesehen....diese Disks waren nur halb su performant wie die modernen Toshiba HDDs. Evtl liegt es am Fuse File-Datei-System...Du hast die RC4 wohl "verpasst"...damit könnte man es umgehen:

Das Daten dabei verloren gehen? nein. Ich habe selbst nach der Standard-Vorgehensweise meinen Cache von BTRFS auf ZFS umgestellt. Das "problem" mit dem langsamen mover für das Docker-Container (unter system) Verzeichnis hatte ich auch...abgebrochen und den Verzeichnisbaum zuerst dann gelöscht...da es BTRFS basiert ist und auf ZFS migriert werden soll, muss man die Docker eh neu laden, wenn Docker ein Verzeichnisbaum und keine vdisk ist. Was man braucht/behalten muss ist das appdata Verzeichnis. ...bei mir hat das prima funktioniert....warum bei Dirr nicht kann man von hier nicht wirklich nachvollziehen. Auch das Daten vom Array betroffen sind, soweit ich verstehe, ist mir schleierhaft. Bist Du sicher, dass Docker- und VM-Dienste gestoppt waren, ach als DU manuell, ohne mover verschoben hast? Wie gesagt, für mich nicht zu rekonstruieren...

...Du hast es ja dankenswerter Weise auch im Bug Report thread gepostet und die Entwickler haben schnell den Fehler gefunden. Nur falls, Du hier zuerst schaust...das ist der Fix für Dich/Dein Problem:

...Du musst die Disks nicht physisch ausbauen, nur logisch aus der Array-Konfig herausnehmen/"ausbauen"...dann kannst Du sie zB mit dem Unassigned Devices plugin mounten. Aber schön, dass es mit der normalen Methode auch geklappt hat.

...ist hier ZIL und ARC gemeint? Was mich viel mehr verwirrt ist das auch ZFS "pools" hat

....das Konzept ist super neu...keine Ahnung, welche Wechselwirkung da auftreten kann. Ich würde das mal in der Bug-Sektion / im RC4-Faden reporten.

Siehe oben die Anmerkung von @saber1 Nimm mal die Parity aus dem Aarry und versuche die zu mounten. Anders als "normal" sollte die ja ein Mirror sein, also ein FS haben. Dann kannst Du zumindest noch Backups machen. ...wenn das mit dem mounten klappt, würde ich anschliessend - da identische DIsks - Parity und Disk1 quasi gegeneinander im Array tauschen

...ja, so die Theorie. Interessant wäre, waas der Parity-Check da im Vorfeld ausgespuckt hat ud ob die Disk als defekt markiert wurde.

-> https://wiki.unraid.net/Manual/Storage_Management#Checking_a_File_System Hast Du Backups?

Zigbee ist L2, analog WLAN...ich meinte das Protokoll, dass zur Steuerung darüber liegt (Ende-zu-Ende auf Applikationslevel). Edit: Ah, sorry...Zigbee ist wieder son Kuddelmuddel-Protokoll. Für Tasmota gibt es da ein Gateway: https://tasmota.github.io/docs/Zigbee/ Damit könnte man denn wenigstens auf HA Seite was "vernünftiges" AKA mqtt nutzen.

Die Frage wäre, welches Protokoll verwendet wird, um die Steckdose anzusteuern. Bei MQTT kann man QoS Parameter setzen *und* als Pub/Sub-Protokoll kannst Du wirklich sicher sein, dass - selbst wenn die Steckdose selbst mal kurzzeitig nicht im (W)LAN ist - der letzte Wert/Befehl auch später noch von der Steckdose "abgeholt" werden kann (Retain-Flag bei Publish setzen). Ausserdem kannst Du über das LWT (Last-Will-and-Testament) im MQTT-Broker sehen, ob die Steckdose gerade beim Broker online/connected ist...kannst also auch das überwachen. Eine Websocket-API ist halt doof, und läuft bestenfalls in den Timeout, den man dann abfangen und mit ner "Retry-Schleife" heilen muss. Next Best Thing, nach MQTT wäre Modbus (serielles Ende-zu-Ende-Protokoll, geht auch über TCP). Ob HA das alles so transparent kann weiss ich allerdings nicht. Kurz: mit MQTT bist Du auf der deutlich sichereren Seite, dass es einfach funktioniert. Daher haben alle meine smarten Gismos Tasmota Firmware und alle Systeme, die ich steuern/integrieren will (Hausbatterie, PV, Wallbox) können MQTT (oder zumindest Modbus).

Ich bin in der Tat total verwirrt. Fang nchmal von vorne an, bitte....du schreibst: Also...unraid hat einen 2.5G NIC .. und Dein Win11-PC auch.... ...jetzt hast Du aus dem Unraid noch einen weiteren Win11-PC gemacht. Du hast keinen unraid Host mehr, sondern 2x WIn11-PCs ...das ist jetzt der oben genannte, zum Win11 umfunktionierte, unraid-PC? OK, was hat das ganze jetzt mit unraid zu tun? Der Adapter scheint doch auf dem PC zum alten NAS zu funktionieren. Wenn Du meinst, dass das ein Problem auf Seiten von unraid ist....beschreibe bitte das Problem im Zusammenhang mit unraid...und hänge die Diagnostics ein.

...also da läuft er gut, was ich vermutet hatte. Aber Du hast ihn oben/zuvor in den unRaid Host eingebaut...unraid ist Linux. Um was für einen Adapter handelt es sich denn genau und was sagt unraid, welcher Treiber geladen wird (pack mal Deine Diagnostics hier rein)?

Keine Sorge, das wird so gut laufen dass Du diese Dinge bis zum nächsten Mal, wo Du sie wieder brauchst, schon wieder vergessen hast 🤣 Weiterhin viel Erfolg!

...unter welchem OS? Realtek-NICs und Linux sind schon immer keine besten Freunde gewesen. Da gab es viel Frust, zumal Realtek wohl auch an OEMs (MB- und NIC-Hersteller) verschiedene Chip-Varianten mit gleichem Label/Namen/Modell/Typ liefert (wenn ich das mal laienhaft ausdrücke, hoffe ihr versteht was ich meine). 2.5G ist mMn eine Brückentechnologie....10G sind heute auch zuhause machbar....selbst über cat5e Kabel.

->