mgutt

So, man kann jetzt bei meinem Skript auch bestimmte Zeilen ignorieren.

You can now add ignore strings. I already added your case and a different one which annoyed me.

Da steht aber nichts davon, dass es nicht lösbar ist. Da fragt er ja nur nach wie man filter schreiben muss.

Ja und nein. Aktuelle Infos dazu findest du im englischen powertop Thread.

Aha. Na dann arbeite ich mal an einem supress feature. EDIT: Hast du den Link zu seiner Aussage?

Die sind alle nicht normal. Im UD Plugin Thread melden. Nutzt du Stromsparmechanismen? Gibt es ein Update für dein BIOS? Eventuell hilft der Thread: https://forums.unraid.net/topic/121146-nvme-aer-corrected-error-und-pcie-bus-error/

Das Fujitsu D3617 könnte evtl auch noch eine Option sein. Das hat 8x SATA und 1x M.2. Allerdings nur mit dem proprietären Fujitsu Stromstecker. Braucht man dann noch einen Adapter oder muss sich ein Original Fujitsu Netzteil besorgen.

Das ist doppelt gemoppelt. powertop --auto-tune setzt diese Einstellungen bereits. Die manuellen Befehle sind nur für Leute, die kein powertop verwenden wollen bzw granularer die einzelnen Einstellungen setzen wollen. Der ist dein Hauptproblem. Der muss weg. Vermutlich die PCI Bridge der CPU. Wenn da die SAS Karte drin steckt ist das Ergebnis normal. ASPM funktioniert von unten nach oben. Können die Geräte nicht schlafen, können die Bridges nicht schlafen.

Der Syntax stimmt doch im Leben nicht. Port hinter Server und dann noch Mal in der separaten Zeile?!

Repeat this command every minute or so: find /var/lib/docker -type f -not -path "*/diff*" -print0 | xargs -0 stat --format '%Y:%.19y %n' | sort -nr | cut -d: -f2- 2> /dev/null | head -n30 | sed -e 's|/merged|/...|; s|^[0-9-]* ||' Now you should know which files are permanently updated (take a look at the timestamps). Lets say there is one file updated frequently like this one /var/lib/docker/overlay2/b04890a87507090b14875f716067feab13081dea9cf879aade865588f14cee67/merged/tmp/hsperfdata_abc/296 Problem: You don't know which container is writing to the path "b04890...". So you need this command to obtain this information: csv="CONTAINER;PATHS\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do subid=$(cat $f); idlong=$(dirname $f | xargs basename); id="$(echo $idlong | cut -c 1-12)"; name=$(docker ps --format "{{.Names}}" -f "id=$id"); [[ -z $name ]] && continue; csv+="\n"$(printf '=%.0s' {1..20})";"$(printf '=%.0s' {1..100})"\n"; [[ -n $name ]] && csv+="$name;" csv+="/var/lib/docker/(btrfs|overlay2).../$subid\n"; csv+="$id;"; csv+="/var/lib/docker/containers/$idlong\n"; for vol in $(docker inspect -f '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Destination }}{{ printf ";" }}{{ .Source }}{{ end }}{{ end }}' $id); do csv+="$vol\n"; done; done; echo ""; echo -e $csv | column -t -s';'; echo ""; Lets say it returns this and now you know which container caused this: Now you could think about how to solve your problem. Maybe the container is writing logs inside the container volume? Or permanently writes to a /tmp dir? Then you could add this path to your container settings and link it to Unraid's "/tmp" (Which is already a RAM Disk - and those files will be lost on reboot of course): Another step could be to analyze most recent writes in the appdata directory: find /mnt/cache/appdata -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 By that I found out that Nginx Proxy Manager wrote permanently logs: And again I created a new path to Unraid's /tmp path (which is already a RAM-Disk): That's how I reduced my writes by 90%. More information in this German thread: https://forums.unraid.net/topic/112617-ssd-abnutzung-maßgeblich-reduzieren/

Nur als Info. Wenn man das File Manager Plugin installiert, kann man das direkt über die Unraid GUI öffnen und bearbeiten. Kannst du vielleicht mal posten was du eingetragen hast? alturismo hat in seinem Beispiel "mariadb" bei Server eingetragen. Das funktioniert aber nicht in jedem Docker Netzwerk. Es kann also sein, dass du da eine IP eintragen musst.

Is there a special reason why you are using the proxynet network? Try to switch both to bridge to simplify your setup. And you need to find out why nextcloud is not reachable. As long you can't open Nextcloud, NPM can't reach it, too. I mean kinda logic, isn't it? Check the Nextcloud logs. Maybe they contain any errors.

Error? This is your problem I think. Which Nextcloud Container are you using? You tried https. Does your container really use https on port 444?

Genau das ändert rein gar nichts an dem Problem. appdata ist genau der Share, der NICHT von diesem Tool erfasst wird. Eben weil appdata Dateien mit unterschiedlichsten Rechten enthalten kann. Das könnte es lösen, weil du dann root:root eingestellt hast. Ob Privileged dann überhaupt noch nötig ist, weiß ich gar nicht. Muss man einfach mal testen.

Die Parität stellt nichts wieder her (wohin auch?!), sondern erlaubt so zu tun als sei die Platte noch da. Fährst du den Server also runter, baust die Platte aus und startest neu, kannst du ohne die Platte das Array starten und dank der Parität wird der Inhalt der fehlenden Platte simuliert. Du kannst die Daten dann auch auf andere Platten verschieben/kopieren. Die ausgebaute Disk kannst du dann übrigens nicht wieder einbauen. Jedenfalls nicht ohne weiteres. Sobald du alle Dateien verschoben hast, kannst du über Tools > New Config das Array wie zuvor, nur ohne die fehlende Disk zuordnen. Die Parität wird dann neu aufgebaut. Hier auch ein paar Infos wie so eine Parität funktioniert: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1021986

Wenn auch USB vorhanden ist, dann ja. Es gibt aber auch Einzelgehäuse mit reinem eSATA. Der NUC hat doch einen WiFi Slot oder? Wenn der PCIe kann und kein CNVi Müll ist, ging auch eine SATA Karte in dem Slot.

Are you serious? Sorry, but it seems you are giving a shit on the topic itself. I mean running a parity check and then asking about power consumption and now you even don't know which hardware you are using AND you don't know if your disks are spun down or not 🤨

Ist sie ja auch. Der 13700 hat ja eine viel geringere Base Clock: Und dass der i5 eine so viel höhere TDP im Base hat, zeigt, dass der offensichtlich schon im Base nicht mehr im Sweet Spot unterwegs ist. Es kann also durchaus helfen im BIOS beim i5 die Base Clock entsprechend zu reduzieren. Ich würde es so machen: Board bestellen. Danach erst den i5. Dann schauen, ob die Base Clock entsprechend einstellbar ist. Wenn nein, dann i7 bestellen. Im Leerlauf spart man ca 1 Watt und im Betrieb dadurch, dass die zusätzlichen Kerne gar nicht erst bei der Verteilung der Prozesse aktiviert werden können. Siehe auch hier: Durch die Isolation der Kerne kann man quasi den selben Effekt erzielen. Kerne die man nicht nutzen kann, können entsprechend auch nie den Leerlauf verlassen.

Doesn't make sense. A spinning disk consumes usually 6 to 8W and a non spinning disk 0.5 to 1.5W. This difference should be noticeable on your power meter. Did you even read the first post? As you are having "bad" entries it does not seem so. Aha, and why is your CPU having a load of 50%? Check your "C0 active" values. This is far away of an "not used" server. Execute "top" and check what is causing this huge load.

Wenn du sie einer VM durchreichst, bezweifle ich, dass überhaupt noch C-States gehen. Die VM hat ja schließlich auch eine gewisse Grundlast.

Ich weiß willst du nicht hören: USB taugt nichts für Unraid. Ich hatte schon selbst 2 verschiedene Modelle im Einsatz. Aber ich hatte immer Fehler beim Parity Check. Also Sleep funktionierte fehlerfrei, aber trotzdem stimmte was nicht mit den Daten. Das wäre eine Bastellösung, aber vielleicht solltest du in den M.2 Slot einen ASM1166 stecken und dann SATA Kabel nach außen mit eSATA führen. Die Platte dann in ein eSATA Gehäuse. Vielleicht findet man auch ein reines eSATA Gehäuse mit mehrere HDDs und mehreren eSATA Anschlüssen (nicht nur einen oder USB, dann ist ein Controller im Gehäuse). EDIT: Das hier hat zb natives SATA (4 HDDS mit 4x eSATA): http://www.istarusa.com/il/raidage/products.php?model=DAGE440DE-ES

Das ist egal. Alle CPUs vom i3 bis i9 sind identisch. Beim i3 sind nur die Kerne während der Produktion kaputt gegangen und weil Intel die nicht wegschmeißen will, machen sie einen i3 draus. Im Leerlauf macht jeder zusätzliche Kern 0,2 bis 0,5W aus. Allerdings gibt es bei der 13ten Generation tatsächlich erstmals einen Unterschied. Nur der i7 in allen Varianten und der i5 als K sind baugleich. Alle anderen sind von der Vorgängergeneration. Ansonsten gilt wie gehabt: Langsamer machen geht immer, schneller, also übertakten, kann man nur K und nur mit dem Z oder W Chipsatz. Will man also den geringsten Leerlaufverbrauch sollte in der Theorie der i5 K der sparsamste sein. Bei dem dann eben den Turbo abschalten, wenn man ihn oben rum bändigen möchte. Vielleicht sind die ja sogar richtig sparsam, wenn man alle Performance Kerne abschaltet, aber hat noch keiner ausprobiert. Ob man Kerne abschalten kann, hängt übrigens vom BIOS ab. Keine Ahnung ob das Supermicro Boards erlauben.

Falsche Annahme. Der DB ist das völlig egal welche IP sie hat.

Wie "in der DB"? Der Fehler klingt eher so als könnte die Applikation die DB nicht erreichen.

To collect more feedback for the Go file code, I started a new thread here: Note: This is a new version. The very first release caused in rare cases multiple mounts on the same path, which caused a stalling server.