mgutt

@jonp As many users flood their logs by installing "atop", it would be nice if this package would contain a smaller log timeframe. The default is 28 days: cat /etc/atop/atop.daily | grep mtime ( (sleep 3; find $LOGPATH -name 'atop_*' -mtime +28 -exec rm {} \;)& ) I think 7 days are more than enough.

Nein. Bitte das ausführen: du -sh /var/log/* Mein Ergebnis: 4.0K /var/log/apcupsd.events 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 60K /var/log/dmesg 4.0K /var/log/docker.log 0 /var/log/faillog 0 /var/log/lastlog 4.0K /var/log/libvirt 0 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 0 /var/log/nginx 0 /var/log/packages 0 /var/log/pkgtools 0 /var/log/plugins 0 /var/log/pwfail 0 /var/log/removed_packages 0 /var/log/removed_scripts 0 /var/log/sa 1.5M /var/log/samba 0 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 0 /var/log/swtpm 160K /var/log/syslog 0 /var/log/vfio-pci 8.0K /var/log/wtmp Falls ein Pfad besonders viele Daten enthält, dazu mal recherchieren. In der Regel gibt es dazu schon Lösungsvorschläge.

Geht es um das Plugin? Dann frag bitte dort. Vor allen bitte mehr Input. Was hast du eingestellt und was steht in den Logs usw. Ich tippe aber auf das hier: https://forums.unraid.net/topic/42320-wake-on-lan-for-virtual-machines-for-61/page/5/?tab=comments#comment-1029485

@OOmatrixOO I changed the script, so it supports multiple times, now:

Ja, wenn man das Script entsprechend anpasst. Ich war mal so frei: https://forums.unraid.net/topic/47160-how-to-automatically-wake-from-sleep/?tab=comments#comment-1030273

Das nennt man schwerpunktorientierte Paranoia ^^

Nur wenn das Array aus Parity + einer Disk bestand. Dann ist es nämlich ein RAID1. Aber wenn es verschlüsselt war, wäre auch das egal.

Und warum heißt das jetzt nicht Anleitungen/Leitfäden? Ich dachte alles muss immer korrekt übersetzt werden ☝️😅

Siehe oben die Beiträge. Wenn es kein RAM-Problem ist, dann evtl irgendwas anderes was mit der Hardware zusammenhängt.

Ja. 1x Nullen reicht laut letzten Aussagen von Fachleuten.

Verstehe ich nicht. Du hast doch drei neue Platten. Pack die ins Array und kopier da die Daten von den ext4 Platten drauf. Dann bist du doch schon fertig oder habe ich was falsch verstanden? Geht schneller, weil die Parität ja bremst und solange die Daten noch auf den ext4 liegen, ist es ja "egal" falls eine Platte kaputt gehen sollte, solange noch keine Parität da ist. Kann man machen oder direkt auf eine Disk schieben, in dem man den Cache bei allen Shares erstmal deaktiviert (No). Jo Brauchst du nicht. PreClear machen Paranoide bei neuen Platten. Aber die Platten sind ja in Ordnung. Das standardmäßige High-Water sorgt automatisch dafür, dass die Daten gleichmäßig verteilt werden. Die Entscheidung kann dir keiner abnehmen. Ich bin paranoid und aktualisiere erst bei 6.10.2 oder so ^^

No, it produces only useless CPU load. Except the target is outside of the server.

Sollen wir das mal für "Anleitungen" bei Limetech anfragen?

Bitte Diagnostics posten. Die Fehler ergeben sich vermutlich aus den Logs.

/mnt/user has a much higher CPU load, but as NPM does not write so much, it shouldn't be as relevant as with MariaDB. So you're right, I will change this default path to /mnt/user and let the user decide which one he prefers.

Sonst kann was sein? Hab's auch mal ohne gemacht und sieht auch ok aus: apt list -a openssl Listing... Done openssl/now 1.1.1d-0+deb10u7 amd64 [installed,local]

Hatte ich auch probiert. Ok, also 1.1.1d-0+deb10u7 wurde angepasst und ist quasi auf dem Stand von 1.1.1l was den Fix der Lücke anbelangt. Nur wie kann ich prüfen, dass genau diese Unterversion installiert ist? EDIT: Ok herausgefunden: # apt list -a openssl Listing... Done openssl/oldstable,now 1.1.1d-0+deb10u7 amd64 [installed] openssl/oldstable 1.1.1d-0+deb10u6 amd64

Es gibt aktuell eine Sicherheitslücke in OpenSSL. Nun habe ich mir die Version in meinem Nginx Proxy Manager angeschaut und die ist veraltet. Ich habe herausgefunden, dass der Container diesen als Basis nutzt: https://github.com/NginxProxyManager/docker-nginx-full/blob/master/docker/Dockerfile Was ich nun nicht verstehe: Warum ist die OpenSSL Version veraltet, obwohl im Dockerfile apt-get update ausgeführt wird? Sollte das dann nicht auch automatisch die neueste OpenSSL Version installieren? Ich habe den Container auch extra inklusive der Images gelöscht, aber das hat genauso wenig was geändert wie selbst ein "apt-get update" (oder upgrade) auszuführen: Heißt das, dass in Debian Buster die neueste OpenSSL Version eben 1.1.1d ist? Wenn ja, bleibt das so oder aktualisiert Debian auch ältere Releases? @ich777 ?

Vor allem: Warum nicht BTRFS oder ZFS, die das ja schon von Haus aus mitbringen.

Zu spät, ist schon XFS. ^^ Im Sinne des Kunden ist das effizienter gewesen. Ich kann da ja nicht auf dessen Kosten stundenlang herumprobieren. Wenn das außerdem wirklich so ist, dass BTRFS Subvolumes das Parent still legen können, sehe ich BTRFS eh als keine Option mehr, außer Docker ist exklusiv auf einem Pool. Da hat mir Docker eindeutig zu viel Einfluss auf VMs, SMB, usw.

Wenn wirklich überschrieben wird und nicht erst gelöscht oder wie bei manchen Backup-Softwares, erst eine temporäre Datei erstellt, dann wird die Datei auf Disk 1 größer und nicht auf Disk 2 verschoben. Falls man die Platten wirklich so krass auslastet, könnte man in den Share-Einstellungen einen Minimum Free Space einstellen: Auf die Art bleiben auf der jeweiligen Disk 100GB frei und wenn bestehende Dateien überschrieben werden, kann diese Datei fehlerfrei wachsen. Wenn man allerdings "High-Water" eingestellt hat, ist das überflüssig, da Unraid dann ja eh schon zwischen den Disks je nach Füllstand springt. Damit dann eine Disk komplett voll wird, müssen erstmal alle voll sein. Stimmt. Unraid macht ja ein RAID1 für die Metadaten. Daher kommt das. Ist also korrekt.

Das wäre ja das selbe, nur dass die Subvolumes dann direkt in der Hauptpartition stecken. Ansonsten würde natürlich schon die Umstellung alleine helfen, weil dadurch ja alle Subvolumes neu erstellt werden. Aber falls es wieder zu dem Fehler käme, wäre auch hier wieder das ganze RAID kaputt. Das wundert mich, weil man ja rein theoretisch das BTRFS Image auch auf einer XFS Partition liegen haben könnte. Das gemountete BTRFS setzt dann bei Fehlern ja auch nicht die XFS Partition auf read-only. Also was hier als "parent" betrachtet wird, finde ich komisch. Auch weil es einfach eine viel zu krasse Reaktion ist, da es ja nur um ein Subvolume von Container XYZ geht. Soll der eben kaputt sein. Dafür muss man ja nicht gleich das ganze RAID "killen". Weißt du mit welchen Optionen das docker.img gemountet wird? Es gibt doch bestimmt eine Option wo man die Auswirkungen auf das Parent Volume verhindern kann, evtl über subvol und/oder subvolid?!

Ja war es. Der Nutzer hat auch massig Container im Einsatz. Naja, wenn du healthcheck überall deaktiviert hast, dann hast du ja schon aktiv was gemacht. Dieser Nutzer und ich denke das gilt für die meisten, wissen ja gar nicht was das überhaupt bedeutet. Die wundern sich nur einfach, wenn die SSD nach kurzer Zeit wieder tot ist und schieben das dann natürlich auf Unraid. Crucial MX500 im BTRFS RAID1 und das docker.img entsprechend auch BTRFS. Wie viel da geschrieben wird, konnte ich nicht testen, da nach kurzer Zeit die SSDs auf read only wechselten. Auch hier wieder nervig, dass Unraid in der GUI nichts dazu meldet. Weder kommen Benachrichtigungen, noch sieht man optisch, dass der Cache Pool hinüber ist. Ich habe daher empfohlen auf XFS zu wechseln, die zweite SSD als Backupziel zu verwenden und Docker auf Pfad umzustellen. Dann gibt es auch keine BTRFS Subvolumes mehr. Findest du es denn nicht auch komisch, dass ein Subvolume in einem Disk-Image die Hauptpartition beeinflussen kann?

Meiner Ansicht nach ist das ein RAID6: https://carfax.org.uk/btrfs-usage/?c=1&slo=1&shi=100&p=2&d=4000&d=4000&d=5000&d=5000&d=5000 Bei einem RAID5 sollte man 18TB Speicherplatz haben, aber du hast 13TB: Das wäre dann ein RAID6: https://carfax.org.uk/btrfs-usage/?c=1&slo=1&shi=100&p=1&d=4000&d=4000&d=5000&d=5000&d=5000 Dazu habe ich dir schon mal gesagt, dass es absolut untypisch ist, dass man überhaupt mit den HDDs arbeitet. Ich habe verstanden, dass du dadurch deine SMR HDDs schneller nutzen kannst, aber was bringt es leise und kleine Platten zu haben, die ständig laufen, wenn man stattdessen 2 bis 4 große CMR HDDs haben könnte, die den ganzen Tag aus sind? Schlussendlich ist deine Motivation eher eine Budgetfrage. Also mit dem was du an Komponenten hast, ist deine Lösung denke ich ok, wobei ich nicht verstehe warum du die zweite NVMe ins Array gepackt hast. Lass sie doch als RAID1 oder wolltest du von BTRFS weg? Du hast aber nicht in unterschiedliche Ordner kopiert, geschweige denn von C auf D, sondern von C:/ordner auf C:/ordner. Quelle und Ziel waren also identisch. In quasi allen Betriebssystemen können zwei verschiedene Pfade auf das selbe Ziel verweisen. Und genau das ist bei /mnt/user/sharename und /mnt/disk1/sharename der Fall. Und wenn du die Quelle mit sich selbst überschreibst, kommt es eben im idealen Fall zu einem Fehler und im anderen zur Zerstörung der Datei. In Windows geht das übrigens auch, aber es kommt zum Glück zu einem Fehler: In Linux führt das normalerweise auch zu einem Fehler. Hatte ich dir ja gezeigt. Aber nicht, wenn Fuse im Einsatz ist. Und Unraid nutzt bei "/mnt/user" eben Fuse (da es alternativlos ist). Ich habe dazu mal ein Issue aufgemacht, aber Fuse hat aktuell keinen fest zugeordneten Entwickler, weshalb es unwahrscheinlich ist, dass sich da jemand in absehbarer Zeit drum kümmert: https://github.com/libfuse/sshfs/issues/262