Ford Prefect

Eine T-CPU ist im idle nicht besser als eine ohne...die ist einfach langsamer und damit nicht so schnell wieder im idle...ich würde nicht das T-Modell wählen, wenn es ums Stromsparen geht...die sind nur für weniger Abwärme, in beengten Gehäusen, zB 1HE Racks, gebaut worden.

Das heisst, Du hast Dich nicht mit realen Daten bei Web.De/freemail für den Account registriert? Dann melde doch den Account als Versender von SPAM bei Web.DE

ja, das ist eben de-duplication...ich denke nicht, dass das jemand mit nem single CPU-System, welches eher Strom sparen soll, einsetzt. Im Kontext der Diskussion xfs und BTRFS/ZFS für unraid, wäre das wie Äpfel mit Birnen zu vergleichen...alles ist Obst. Meine ersten Erfahrungen mit ZFS sind schon über 10 Jahre her...damals gab es nur Solaris und ZFS on Linux, noch kein OpenZFS...der ZFS-Stammtisch im HWLuxx startete im Januar 2009 und war da, zusammen mit napp-it von User gea die erste Anlaufstelle. Und ja, es lief ohne Probleme und schnell auf meinen X8SIL mit kleinem Xeon und nur 8GB RAM, unter napp-it und dann Debian auf einem AMD Opteron mit 4GB, später 8GB RAM ls Filer. Damals waren 2TB disks so teuer wie heute ein 16TB, ReiserFS für Linux war da eher Teil in der Diskussion und dann kam erst BTRFS, auf was noch in den Kinderschuhen war und sich nicht so weiterentwickelt hat. Ich gehöre zu denjenigen, welche unter unraid, insbesondere nach v6.3, extreme Problem mit BTRFS hatten. ZFS ist einfach ne andere Liga...nur weil es für viele neu in unraid ist, muss man verstehen, dass es es selbst nicht neu, sondern state-of-the-art und gehärtet, bei vielen professionellen Anwendern im EInsatz und nicht mehr wegzudenken ist. Das es jetzt von unrid unterstützt wird, ist für meinen Teil ein Segen, sonst hätte ich die Sticks mit den Lizenzen wieder ins Regal gelegt und wäre auf Proxmox gewechselt. Trotzdem übertreibe ich es nicht, mit dem "Feature - F("&§&!=?".....ich will einfach nur weg von BTRFS und mehr Sicherheit und Performance in Pools. Ich sehe es als BTRFS Ersatz. Bisher klappt das super auf meinem C246M-WU4 und nem i8100. Snapshots und ZFS send sind schöne DInge, die es bei BTRFS nicht gab.....aber hier ware ich noch ab...wird kommen und dann schaue ich mir das an...keine Eile....schon garnicht mit ARC, ZIL, Special Caches auf nem extra vdev (https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/) ...wobei das eben wieder anderes Obst ist. my2cents.

Ja, vor allem wenn Du eben ein ZFS-Raid Level nutzen kannst. ich würde das aber nicht mit rSync machen, sondern einfach durch den cache-level der Shares und den mover lösen. nimm einfach die Default Einstellungen...Performance kommt zuerst durch IOPS...also in einen Raid-Level investieren. Da reichen, wie gesagt auch 4GB RAM für das pure NAS. ...taste Dich gern weiter ran, wenn Du magst

Ich wiederhole es nochmal...der RAM-Verbrauch bei ZFS passt sich dynamisch an, ist nicht statisch vorgegeben. Mach einen test und gib ner VM doch mal 24GB von Deinen 32GB (2-4 solltest Du für unraid selbst einkalkulieren). Da wird es keine ZFS Errors geben....ich hatte auch schon ZFS-Systeme mit 4GB RAM ohne irgendein Problem. in einem Pool würdest Du ja ein ZFS-Raid Level bauen. Im Array hast Du nur eine Parity...ist bei BTRFS nicht anders. ich habe aus Faulheit mein Array aber auch noch auf XFS....niemand zwingt Dich zu ZFS im Array...nimm doch das Beste aus allen Welten.

kurz: ja Nein, komprimierung ist einfach das, was es sagt...ist wwie "zip/unzip on the fly"...ich meine der Basis-Algo ist LZ4...kann man aber einstellen. Braucht natürlich auch RAM und CPU...aber de-duplication ist was anderes. Ich habe 2x18TB und 2x20TB und 2x1TB8Cache) mit ZFS ... im alten Filer mit 8GB hatte ich 23TB ... ich weiss nicht, woher die Leute immer diese Zahlen hören/haben...quatsch! überhaupt NULL einbußen, solange Du eben CPU hungrige features nicht aktivierst...nicht Äpfel mit Birnen vergleichen. Wenn Du auf ner Baby-CPU - egal ob mit/ohne AES-NI Support - (die falsche) compression aktivierst bis Du am Irsch...logisch ;-)...diese eingebauten Features sind für Enterprise-Level...logisch, wenn man weiss, wer es erfunden hat. Auch Auto-Trim ist drin, was bei SSDs/NVMEs Sinn macht....das hat xfs oder btrfs nicht.

Du hast ja bit-rod detection durch copy-on-write. Wüsste nicht, was das mit der Grösse und Raid-Level zu tun hat. Im Array hast Du 1x Parity...eine Disk kann ausfallen. Im Pool hast Du scrub. Bei unraid Pools mit ZFS hängt es von der Struktur des ZFS-Pools ab...wenn Du ein hot-spare hast, dann geht die Reperatur / replace+resilver unkomplizierter snapshots gehen noch nicht "nativ" in RC2 ... es gibt ZFS Plugins, die das können...aucb Backups mit zfs send...habe ich ber nicht getestet. im RC2 hast du eben den gleichen "unraid Level" wie BTRFS...nur ist ZFS wirklich stabiler...auch auf Linux ausgereift....einige schöne Features sind noch nicht "zuugänglich", aber das macht ZFS jetzt nicht unausgereift. Nein, ist es nicht...es wird einen Teil des RAMs als ARC-Cache nutzen, den aber auch dynamisch wieder freigeben, wenn gefordert....mein alter Filer lief mit ZFS auf 8GB Ram ohne wesentliche Performance Probleme...die DIsks waren aber auch langsamer als heute in meinem System mit 32GB belegt ZFS etwa 20-35%, laut UI...es ist stets genug RAM "übrig", etwa 40-50% (habe einige Docker und eine FreePBX VM) Der "echte Speicherhunger" kommt - neben ARC Cache - durch ein Feature, das "de-duplication" heisst...das würde/habe ich nie genutzt. Das wäre der Plan...versprechen kann das aber natürlich Niemand....Backups sind ohnehin, auch so Pflicht Ich habe einen Pool aus 2x18TB Mirror gebaut...und eine Woche später nochmal 2x20TB da drin nachgerüstet....also ein Mirror aus 2x2 Devices (2 groups of 2 devices). Ist was spindown und spinup betrifft völlig unauffällig.

Nein, würdest Du nicht...daher sagte ich ja..."denke für unraid ZFS wie BTRFS". Wenn Du im Array BTRFS wählst wird auch kein BTRFS Raid draus...die einzelne Disk wird mit BTRFS formatiert...jede einzelne...mit ZFS ist/wird es genauso. Du erhälst statt eines journaled FS ein Copy-on-write FS auf jeder Disk im Array...die Parity ist eine unraid-Parity, nicht einen BTRFS/ZFS-Parity aus einem BTRFS/ZFS-Raid-Mode, es gibt kein Striping im Array. "Echte" ZFS-pools und datasets und Rad-Level kannst Du für unraid pools verwenden....hier musst Du ein wenig aufpassen/verstehen, da das Wort pool eben bei unraid und bei ZFS auftaucht, dass hier pool technisch unterschiedlich belegt ist. Wieso? Ist die neue Daten-Disk grösser als die alte Parity? Ich würde die Parity ausbauen...die neue Daten-Disk zusätzlich einbauen und dann einfach die Daten der "alten" Daten-DIsk manuell auf die neue kopieren (kopieren, nicht verschieben, so bleibt sie als Backup übrig und kann bei Bedarf über UD nochmal eingebunden werden). Dann die alte Daten DIsk ausbauen, die neue an ihren Platz setzen ... die Position der Daten-Disks, solange Parity nicht da ist, spielt keine Rolle....dann die Parity wieder einbauen. So muss man nur einmal Parity neu bauen....ist sicher dann, wenn man Backups hat...sonst muss man das Risiki abwägen. Bei jeder Disk-Config Aktion natürlich vorher Array stop/start. Eine neue Disk bekommt bei mir immer 1x Pre-Clear...eine alte schonmal 2x. Ja,, als "Dummy" kann ein USB-Stick dienen oder eine kleine HDD/SSD (mit/ohne Parity)...bei einem Dummy musst Du halt den Cache für die/alle Shares auf den Pool umleiten. Bei Filmen, die nur angeguckt werden, habe ich es so gemacht...der Stromverbrauch ist der gleiche, da die Disks eben 99% der Zeit schlafen....bei Nutzung aber eben alle laufen. Im Pool gibt es keine Performance Penalty...neue Filme hinzufügen geht also schnell. Ich habe 2x18TB +2x 20TB in einem Pool und damit meinen alten Filer abgelöst, dessen MB+NT nach 10 Jahren gestoben ist...der war 99% im Sleep Wenn Du das Array öfter nutzt, zB mit Daten ausm Scanner oder Office ... ich habe 1xDaten+1xParity zu 1TB aus 2.5HDDs im Array für diesen Zweck. Bei nur 1x Daten-Disk im Array (0x, 1x oder 2x Parity) macht unraid übrigens einen "Trick" und macht stillschweigend einen Mirror draus...auch keine Performance-Einbussen beim Write.

Das liegt an den lahmen DIsks, wenig RAM und wie das Fuse-Datei-System funktioniert, sowie der Artt&Weise, wie die Parity funktioniert...der Mover macht das ja ausserhalb SMB. ich hätte aber vermutet, dass Du schon auf 50MB/sec kommen solltest...wieviel RAM und welche CPU hast Du am Start? Edit: oder Verschlüsselung aktiviert? Hast Du mal "turbo-Write" aktiviert -> https://wiki.unraid.net/Manual/Storage_Management#Array_Write_Modes und probiert?

ZFS in unraid ändert an der Philosophie dahinter nix....alles klappt, wie bisher, inkl. Disk spindown/-up im Array und Pools, ebenso wie gemischte Grössen bei Daten-Disks im Array. Denke ZFS wie BTRFS...nur stabiler, zumindest was meine Erfahrung betrifft...und sogar stromsparender (mein Cache Pool aus 2x1TB NMVE läuft mit ZFS echte 2-3Grad kühler, bei gleicher Nutzung). ...selbst wenn Du andere ZFS-features wie snaps usw. nicht später einsetzt, würde ich sogar ZFS schon jetzt, mit der aktuellen 6.12RC2 empfehlen.

Docker können einfach keinen DHCP-Server nutzen, weil sie einfach keinen dhcp-client an Bord haben - also kann es nicht auf diese Art funktionieren...der DHCP-Server würde einfach nie "angesprochen", wenn der Docker startet/läuft und kann daher keine IP vergeben und diese verwalten/mit Namen versehen. Ein Docker ist keine VM mit einem kompletten OS, sondern nur eine App, die alle benötigten shared Libraries aus dem Basis-OS im Bauch/Dateisystem hat...kein ganzes OS, keinen asynchron zum Host laufenden Kernel, wie eine VM...LXC sind da wieder was Anderes., aber die gibt es auf unraid eben nicht. Wo wäre der Unterschied im Aufwand zur statisch, vergebenen DHCP Adresse im DHCP-Server? Da musst Du doch auch im Zweifel einen Namen eintragen, weil man sich nicht darauf verlassen kann, welchen Namen der Docker verwendet...Du könntest ja einen Docker 1-mal installieren aber n-mal starten 8der Container hat die IP, nicht der "Docker". Also kannst Du das auch im DNS eintragen....die IPs willst Du ja auch aus guten Gründen statisch halten. ich meine der Aufwand wäre identisch/marginal unterschiedlich. Edit: es gäbe eine Möglichkeit, das "halbautomatisch" zu machen....wenn Du zb eine Fritzbox als Router hast. sobald der Docker mit statischer IP mal traffik durch die Fritz laufen lässt (weil er ins I-Net gehen will) taushct er in der Liste der Heimnetz-PCs auf Dann kannst Du dort einen Namen vergeben im Pihole DNS kannst Du für Deine lokale Domain dann die Fritz als DNS-Server eintragen ...habe ich so ähnlich laufen, mit meinem Router (keine Fritz, mit statischen DNS Adressen für die relevanten Docker) und Adguard statt Pihole. Sollte aber ähnlich funktionieren und die Fritz wird Dir die IP schonmal eintragen/anzeigen...also "halbautomatisch"...weniger Aufwand.

Ich kenne pihole jetzt nicht aus dem EffEff....mit DHCP hat das aber nix zu tun, da die Docker eben das nicht nutzen. Du solltest mMn die IPs als statiche, lokale DNS Adressen im pihole hinterlegen....dann sollte pihole sie als solche erkennen und zB in den Statistiken anzeiigen. Im DHCP-Informationsfenster allerdings eher nicht, weil eben kein/nie DHCP genutzt wird.

Ich hab schon lange Erfahrung mit ZFS..bin von unraid v4 zu einem ZFS-Filer gewechselt und VMs und wieder zurück wegen Stromverbrauch (weil spindown nicht zuverlässig funktionierte und die v6 mit VMS und Docker kam). Ansonsten hat mir da ZFS schon oft den A***** geretttet, bei Disk Ausfall. Mit unraid und BTRFS habe ich nur Ärger...seit der v6.12beta bin ich zurück auf ZFS. Wäre ZFS nicht in v6.12 gekommen, wäre ich wegen BTRFS von unraid wieder weggegangen und evtl. zu Proxmox gewechselt....hätte @ich777 mich nicht auf die beta aufmerksam gemacht....der WAF war hier echt am Boden. Und meine beiden 1TB NVMe im Cache-Pool (die eh nie schlafen) laufen mit ZFS etwa 2-3Grad kühler im gleichen System und gleicher Last...also doch stromsparender. Zusätzlich habe nun einen Pool aus 2x18+2x20TB HDDs und spindown klappt bisher einwandfrei. Endlich habe ich wieder ein unraid, dass das beste aus allen Welten vereint und zuverlässig ist....BTRFS kommt mir nicht in Haus...ZFS rocks! Auch nur my2cents...

...wenn der Ordner auf dem Array jetzt wirklich, wirklich leer ist (also nicht mit dem Docker, sondern mal direkt, über die Kommandozeile oder im unraud-UI schauen, dann ja...futsch ist futsch. Wenn der ordner "Filme" aber auch weg ist, sollte das nicht im Docker passiert sein, sondern durch eine andere Handlung. Trotzdem gilt, dass wenn die Berechtigungen stimmen, man natürlich vor der Tastatur Fehler machen kann...da hilft kein Parity, nur Backups....oder nach dem Schreiben, den Dateien alle Schreibrechte entziehen....am besten mit nem speziellen Modus, sodass auch Ransomware keine Chance hat - aber Clients weiterhin lesen können. Da gabs hier auch einen Faden dazu....

Äh, nein...Du hat Recht...ich werde wohl langsam zu alt für diesen S*/§%"?

Da sieht man, dass Du dem Docker den kompletten Pfad /mnt/ des unraid Host freigegeben hast. Diesr Mount ist direkt, ohne Umweg über ein Share. In Verbindung mit root-Rechten ist das ne gefährliche Sache.... Du kannst also mit der App im Docker grossen Schaden anrichten. Der Docker oben drüber, hat nur den Pfad /mnt/user/Filme gemounted...damit kann man dann nur Schaden unterhalb anrichten...zB den Ordner/das Share /mnt/user/Filme selbst nicht mehr von dort löschen. Edit: das war leider falsch rum gedacht...mea culpa...danke an @saber1 für die Aufklärung, einen Post drunter 🥲

Was willst Du denn da in unraid anpassen? Die Grösse wird bei der Erstellung der VM festgelegt...danach ist für die VM nur noch Name und Ort der vdisk Datei wichtig, nicht mehr die Grösse des FS da drin.. unraid basiert auf KVM/qemu. Die vdisk selbst kannst Du also mit den qemu tools bearbeiten: https://www.qemu.org/docs/master/tools/qemu-img.html (ich würde vorher die VM stoppen und die vdisk Datei mal sichern ). ... qemu-img "resize" ist das magische Kommando. Danach hängt es vom OS und dem Filesystem in dem Image ab, ob es sich selbst expandiert...Versuch macht klug.

Wie gesagt, bei openWRT bin ich raus. Das hat auch nix mit unraid zu tun...versuche es mal im openWRT forum. ich gehe davon aus, dass es ein Routing/forwarding Problem ist. Du kannst mit ip-tools versuchen herauszufinden, wo / an welchem Interface der Pfad der IP-Pakete "stehen bleibt"...ping & tracsroute sind die üblichen Verdächtigen.

...und wie wurde zuvor der Cache geleert? Durch den Mover? Du hast zwei Daten-Disks, nutzt aber für dieses Share nur die eine Disk #1....so gewollt? Die Cache-Disk ist jetzt nicht übermässig gross...400GB kan man über Nacht schon mal locker transportieren...ich vermute, dass die also voll geworden ist. Ich würde vor solchen nächtlichen Aktionen den Mover auf stündlich, oder noch kürzer einstellen... Wie @DataCollectorschon erklärt hat, solltest Du der Fehlermeldung mal vertrauen und der Ursache auf den Grund gehen. Die Einstellungen für den minimalen Speicherplatz auf 0kB sind wahrscheinlich die Ursache..Du musst da mehr Luft lassen....und es für jedes Share und auch die Cache Disk einstellen.

wie meinst Du das genau...wie hast Du das "verschieben" gemacht? Sicher? Wie sinnd die Cache Einstellungen für das Share, in welches Du die Ordner kopiert hast? Dann ist das Array vielleicht doch voll...welche Disks sind dem Share zugeteilt? Hast Du mal bei den Shares im UI ein "compute all" gemacht und geschaut, wo welcher Ordner liegt?

...hast Du ein Cache Laufwerk? Dann ist das vielleicht voll...lass den Mover laufen bzw. erhöhe im Scheduler den Takt/Zyklus damit das nicht so häufig vorkommt.

Ja, das macht Sinn. Wenn Du keine Backups von den Daten hast und auf Nummer sicher gehen willst, dann installiere die UD Plugin(s) und schaue / mounte die Daten-Disks erstmal und vergleiche die IDs mit Deinem Screenshot. Eigentlich kann nix passieren, solange Du die Parity nicht zu einer Daten-DIsk machst und vor Allem auch nicht umgekehrt. Parity ist/sind die Disk(s), welche nicht formatiert ist/sind. Ich würde das Array erstmal ohne Parity zusammenbauen, starten und schauen, ob alles da ist...dann Parity einbauen/hinzufügen

Doch, ich habe aus zwei Systemen eines gemacht und 13HDDs durch 4 (bei Verdopplung der Größe) ersetzt. Das alte 750W NT, selbst wenn es in der Woche zusammengenommen etwa 1Tag lief hat mehr verbraucht als nun diese 4 Disks 24x7. Das kombinierte System ist aber in einem Bereich in dem das Corsair nicht wirklich vorteilhafter ist als das beQuiet...und dank reichlich PV Überschuss muss ich nicht mit 43ct pro kWh rechnen, sondern mit 13ct (Verlust der Einspeisevergütung + MWSt fürs FA). Ich beziehe durch die Umrüstung weniger Strom als vorher und mehr von meinem selbst erzeugten Strom. Gesendet von meinem SM-G780G mit Tapatalk

Ich habe so eine Konstellation nicht am Start, kann daher nur Vermutungen anstellen... Der Hinweis auf Hairpin-NAT ist erstmal richtig. bei der Fritz heisst das aber, glaube ich, anders...funktioniert aber genauso. Edit: und selbst wenn es durch den Router läuft, heisst das ja nicht dass es durrch die schmale I-Net Verbindung läuft. Der Router und dessen Anbindung ins LAN muss halt genug Bumms haben für eine bidirektionale Verbindung..es wird dann etwas OOverhead geben, aber mehr als 100Mbps müssen es dann schon sein...etwa 800Mbps, wenn es nur ein 1Gbps Link ins Heimnetz ist. Wenn es im Router noch durch die Firewall durch muss, wg. "fehlconfig" kommt die CPU des Router nochmal ins Spiel...da kann eine Fritz nicht mithalten (und das "Problem" ist dort, in einer Fitz, mangels Monitoring-Möglichkeiten" dort auch kaum festzustellen). verwende nicht ping, sondern traceroute (unter win: tracert), sowie nslookup ... mit nslookup siehst Du die IP, die vom DNS aufgelöst wird. Dann, wenn es die P aus dem lokalen Netz ist, vergleiche die ARP-Tabelle (Befehl: arp -a) ... da sollte im client für die lokale IP eine MAC Adresse stehen, die *nicht* die des Router-LAN-Interfaces ist, sondern vom unraid. Nur dann nimmt er die Vebindung ohne Umweg zum Router. Kleine Ergänzung: das geht natürlich nur, wenn client und unraid im gleichen lokalen Netz sind. Sind es zwei verschiedene Netze, zB VLANs, dann *muss* das durch den Router durch. Welchen DNS hat der Client denn lokal eingetragen und wenn es nicht der PiHole ist, sollte man das klären. Im Zweifel im Router, in der Firewall forcieren, dass alle Anfragen durch den PiHole *müssen*....sowas geht natürlich nicht mit einer Fritz. Oft gibt es auch Eintragungen für mehr als einen DNS-Server...diese werden dann manchmal wahlweise oder simultan abgefragt...der schnellste gewinnt meist...sowas muss man dann lassen. Evtl. ist auch im Pihole das Hairpin NAT falsch konfiguriert?

...ich hatte etwa 8 Tage gewartet....da war das beQuiet aber schon eingebaut und 75EUR vs 115EUR sind schon ne Ansage...zumal ich eben den gestorbenen Filer ersetzen musste und dafür noch 4 HDDs nachgrüstet hatte, fiel die Entscheidung doppelt leicht.