mgutt

I would try it with Ubuntu. Maybe unRAID is shipped with an older driver.

Ausbauen und vergleichen.

Ja der JMB unterstützt keinen Standby. Du musst die Kommandos einzeln ausführen und die bei den SATA bezogenen Kommandos nur bei den Onboard "hostX" SATA Buchsen das Kommando ausführen. Die Kommandos sind im englischen Powertop Thread aufgeführt.

Powertop liest Werte von der CPU aus und interpretiert die als C9 oder C10. Es kann gut sein, dass die in einer der Versionen falsch ausgelesen werden. Ändert aber nichts daran, dass die entsprechenden so anliegen. Naja 15 ist deutlich aktueller als 8.

Man greift auch zu Hause über die Domain zu. Die genannten Warnungen sind auch nicht anders lösbar.

Ja bei powertop runterscrollen und du solltest sehen, dass die iGPU auf RC6 steht.

Auto tune ausgeführt? iGPU Treiber installiert? Anderen M.2 Slot getestet?

Ja, da hätte ich auch mal drauf kommen können 😅 Danke!

Da gibt es aber auch massig weitere Angebote: https://www.mydealz.de/search?q=Thinkcentre Ich hätte auch noch einen M920x für 350 € zu verkaufen. Der hat den Charm, dass echt viele SSDs reinpassen. Spielt keine Rolle.

Hast du wie gepostet p- geschrieben?

Der würde sich genauso anbieten. Zum Lenovo gibt es hier übrigens auch einen Thread: Jo DLNA halte ich für ziemlichen Müll, aber ja warum nicht. Du brauchst nur eben einen Container, der einen DLNA-Server bereitstellt. Ich würde aber eher Plex oder Jellyfin nutzen. Wirst du erst sehen, wenn du es testest. Normalerweise laufen aber Intel 2.5G Controller sehr sparsam. Nur ob sie C8 verhindern, hängt extrem von der jeweiligen Hardware ab. Wenn sie günstig ist, ok, aber ansonsten brauchst du eigentlich keine so gute SSD. Eine Evo reicht. Du kannst 3200 Mhz überall verbauen. Langsamer taktet RAM immer.

Ich habe eben in den Logs diverse Fehlermeldungen vorgefunden. Hier ein Beispiel: 2023-09-24 22:06:39.214 WARNING (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x709E:1:0x0002]: async_initialize: all attempts have failed: [DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>')] Wenn man googled, stößt man auf Themen rund um Zigbee Aktoren. Also habe ich versucht herauszufinden welcher Aktor das sein könnte. Ist natürlich super, dass da nur "0x709E" steht. 😒 Ich habe dann aber herausgefunden, dass man ein Zigbee Gerät anklicken und dann auf "Netzwerk anzeigen" gehen muss: Und dann kann man oben links in der Suche die Zeichenfolge eingeben und der entsprechende Aktor wird hervorgehoben: Aber was ist nun das ":1:0x0002" ? Ist da mit die "DeviceTemperature" gemeint? Und wenn ja, was soll mir das nun sagen. Kann HA den Wert nicht auslesen oder was ist das Problem? Wirklich Sinn macht das jedenfalls nicht, da genau dieser Wert nicht verfügbar ist: Oder ist das schon das Problem? Ich habe den Wert aus Spaß mal aktiviert und er wird scheinbar auch ausgelesen: Ich habe daher das Gefühl, dass ich an der falschen Stelle schaue?!

Da ich mittlerweile bei 8GB angekommen bin 😅, wollte ich mal schauen, wo man vielleicht noch was Platz sparen kann. Ein wie ich finde interessanter Punkt ist folgender: Bei einem benutzerdefinierten Sensor (configuration.yaml), der sich auf mehrere Entitäten bezieht, wird dieser jedes mal berechnet, wenn nur eine der beteiligen Entitäten einen neuen Wert meldet. Addiert man also zB wie ich drei Sensoren eines Shelly 3EM, um den Gesamtverbrauch aller drei Phasen als Summe zu erhalten, so würde das Ergebnis alle paar Sekunden berechnet und in die Datenbank geschrieben. Das kann man verhindern, in dem man einen time_pattern trigger dem sensor-Block voranstellt. Hier aktualisiere ich zB die Summe nur alle 5 Minuten: - name: Wärmepumpe Summe unique_id: shelly3wp_energy unit_of_measurement: 'kWh' state: >- {#- on reboot some sensors do not return a number (instead they return "unknown" or "unavailable") -#} {%- if is_number(states("sensor.shelly3wp_channel_a_energy")) and is_number(states("sensor.shelly3wp_channel_b_energy")) and is_number(states("sensor.shelly3wp_channel_c_energy")) -%} {{ (states("sensor.shelly3wp_channel_a_energy") | float + states("sensor.shelly3wp_channel_b_energy") | float + states("sensor.shelly3wp_channel_c_energy") | float) | round(2) }} {%- else -%} unavailable {%- endif -%} device_class: energy state_class: total_increasing Oder hier nur alle 30 Sekunden: - trigger: - platform: time_pattern seconds: "/30" sensor: - name: Wärmepumpe Verbrauch unique_id: shelly3wp_power unit_of_measurement: 'W' state: >- {#- on reboot some sensors do not return a number (instead they return "unknown" or "unavailable") -#} {%- if is_number(states("sensor.shelly3wp_channel_a_power")) and is_number(states("sensor.shelly3wp_channel_b_power")) and is_number(states("sensor.shelly3wp_channel_c_power")) -%} {{ (states("sensor.shelly3wp_channel_a_power") | float + states("sensor.shelly3wp_channel_b_power") | float + states("sensor.shelly3wp_channel_c_power") | float) | round(2) }} {%- else -%} unavailable {%- endif -%} device_class: power state_class: measurement P.S. das Prüfen auf "is_number" und Setzen auf "unavailable" hat geholfen, dass der Sensor nach einem Neustart des Containers nicht mehr auf 0 zurückspringt. Seitdem habe ich ausschließlich saubere Werte in der Datenbank. Was eventuell auch noch interessant ist, dass neben der Datenbank-Tabelle "states" auch "statistics_short_term" einiges an Speicherplatz belegt: Dazu recherchiere ich aber später noch mal. Bis dahin habe ich die Abfrage aus dem verlinkten Thread noch mal ausgeführt: SELECT COUNT(*) AS cnt, COUNT(*) * 100 / (SELECT COUNT(*) FROM states) AS cnt_pct, SUM(LENGTH(attributes)) AS bytes, SUM(LENGTH(attributes)) * 100 / (SELECT SUM(LENGTH(attributes)) FROM states) AS bytes_pct, entity_id FROM states GROUP BY entity_id ORDER BY cnt DESC Das Ergebnis von damals: Und von heute: Was mir dabei auffällt: 1.) Umso häufiger ein Gerät beim Verbrauch schwankt, umso häufiger kommt es zu DB-Einträgen. Vom Prinzip logisch, ich hätte nur nicht gedacht, dass alleine der Shelly 3EM, der den Allgemeinstrom des Stromzählers ermittelt, 39% (14+13+12) aller DB-Einträge ausmacht. Wie soll ich das reduzieren?! 2.) Benutzerdefinierte Sensoren / Entitäten werden nicht aus der DB entfernt, obwohl sie nicht mehr existieren. zB alles was mit "stromzahler" anfängt, gibt es gar nicht mehr. Ich habe schon über Entwicklerwerkzeuge > Dienste > Recorder: Purge Entities > Entity Globs to remove > "- sensor.stromzahler*" versucht diese Entitäten zu löschen, aber sie bleiben hartnäckig in der Datenbank enthalten 🤔 3.) Man sollte grundsätzlich jeden Sensor / Entität beim Hinzufügen zu Home Assistant umbenennen. zB "lumi_lumi_blablabla" ist wenig aussagekräftig. Da darf man dann erst mal die Entitäten-Liste durchsuchen: Wobei ich aber auch hier überfragt bin, wie ich die Menge der DB-Einträge beeinflussen könnte. 🤔

Mit RAM Defekt hat das nichts zu tun. Da gäbe es andere Fehler. Jetzt musst du einfach warten bis der Fehler erneut nachvollziehbar ist. Wie gesagt schreibt irgendwas in den RAM oder überlastet im Allgemeinen den RAM.

Du brauchst logischerweise zusätzliche Platten für die Daten von unRAID. Wenn du die in BTRFS formatierst, kannst du sogar mit einem Windows Treiber auf die Daten zugreifen. Dann eben Stick rein, unRAID bootet, Stick raus, Windows bootet. Du darfst nur eben wie gesagt nicht mit unRAID die Windows Platte irgendwo einbinden. Also als Unassigned Disk lassen. Und in Windows darfst du nichts mit der Parity Disk machen und von den Array disks nur lesend zugreifen oder nach jedem Boot die Parity reparieren.

Oh, dann sollte ich an der Stelle das dry-run denke ich weg lassen. Der Test kann ja ruhig in beiden Fällen wirklich gemacht werden. Danke für den Hinweis. Laut meiner Recherche wird der Zugriff als Root-User automatisch in nobody geändert: https://superuser.com/a/1226152/129262 Das ist halt das was ich meine. Wenn du auf ein externes System schreibst, kannst du niemals sicher sein, dass du auch da root bist, außer du nutzt wirklich den root-Login der Zielmaschine, was ich wieder als unsicher betrachten würde. Nur damit du das auch mal selber prüfen kannst. So kannst du alle Dateien finden, die dem User root gehören, die im appdata Share liegen: find /mnt/user/appdata -uid 0 Wenn du nun dieses Verzeichnis sicherst, kannst du das selbe Kommando auf der Zielmaschine selbst ausführen, um zu schauen, ob die Rechte noch passen. Zählen könnte man dann zB so: find /mnt/cache/appdata -uid 0 | wc -l find /mnt/extern/server/backups/appdata -uid 0 | wc -l Beide müssen logischerweise die exakte selbe Anzahl zurückgeben. Noch eine Option wäre es die Backups von Cache auf Array zu machen und das Backup dann in ein tar zu packen, was du dann auf ein externes Ziel deiner Wahl kopierst. Dafür reicht dann "cp". Die Hardlinks gehen dann natürlich nicht. Aber wenn man den gesamten Backup-Ordner sichert, dann erkennt tar die Hardlinks und fügt die Datei auch nur jeweils 1x im Archiv hinzu. Vorteil in einem tar ist, dass die Dateirechte im Archiv selbst gesichert werden. Dadurch kann man ein tar auch zB auf eine Windows-Maschine sichern und verliert nichts.

Ich habe zwischenzeitlich schon wieder welche gekauft. Sind noch 2 oder 3 sogar noch da. Schreib mir einfach eine Email / PN.

Was ist in diesem Ordner? Und wie sieht aktuell deine RAM Auslastung aus? Eventuell wiederholst du das Kommando einfach alle paar Stunden / Tage, um eine Tendenz auszumachen. Das wirkt auch als sei es zu viel. Mich wundert auch, dass /usr bei dir nichts zählt. Hat unRAID dafür neuerdings eine separate Partition? Führe bitte mal df -h aus.

Wenn du sie nicht gerade auf den Cache kopierst, befinden sich keine Dateien irgendwo doppelt. Dateien liegen bei unRAID entweder auf dem Array ODER dem Cache. Und du entscheidest, ob eine Datei permanent auf dem Cache liegen soll oder vom Mover auf das Array verschoben werden soll. Liegt dann eine Datei oder ein kompletter Share auf dem Array und die SSD geht kaputt, dann sind die Dateien verloren. Daher braucht es entweder ein RAID als Cache oder zeitnahe Backups. Desweiteren ist es meist wenig sinnvoll HDDs und SSDs im Array zu mischen. Ich mein wer will schon mit 50 bis 80 MB/s auf eine SSD schreiben. Dafür holt man sich ja eigentlich keine SSDs. Aber klar, machen kann man das. Wobei ich dann in den Disk Settings auf Reconstruct Write umstellen würde. Das sollte die Schreibgeschwindigkeit auf 200 MB/s erhöhen (es laufen dann beim Schreiben immer alle Disks des Arrays parallel, aber SSDs ziehen ja nicht so viel Strom bzw gehen schnell wieder schlafen, weshalb das in Ordnung sein sollte). Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=951565

Kurze Garantie, dafür mit 199 € für 18TB deutlich günstiger: https://www.ebay.de/itm/185843432850?epid=16060611231&hash=item2b4521bd92:g:CgUAAOSwRwhkLSbF Ich habe von dem Händler zwei 22TB Platten gekauft und bin zufrieden. Ansonsten würde ich aber eh nie mehr als 15 € pro TB zahlen. Also selbst so ein Angebot würde ich nicht wahrnehmen: https://www.mydealz.de/deals/2-x-western-digital-wd-red-pro-16tb-35-nas-hdd-ca-1754eur-tb-sata-7200rpm-512mb-cache-cmr-5-jahre-garantie-2227912 Jedenfalls geht es deutlich günstiger als 350 €. Man muss nur eben auf Angebote warten.

unRAID läuft im RAM, wie auch diese Datei. Dein RAM läuft also warum auch immer voll. Das ist natürlich nicht normal. Meist liegt es an Dateien, die in Verzeichnissen gespeichert werden, wo sie nicht sein sollten. Mit dem Kommando kannst du die jeweilige Belegung prüfen: du -hsx /* 2> /dev/null So sieht es bei mir aus: 12M /bin 715M /boot 0 /dev 15M /etc 0 /home 0 /hugetlbfs 0 /init 8.2M /lib 30M /lib64 0 /mnt 0 /opt 0 /proc 20K /root 1.1M /run 23M /sbin 0 /sys 76M /tmp 776M /usr 13M /var Weicht bei dir etwas auffällig ab?

Du kannst auch einfach den bestehenden Stick weiterverwenden. unRAID wird bei jedem Booten neu installiert. Wenn du das Array neu konfigurieren willst, dann geht das zb über Tools > New Config. Und wenn die Shares bzw Dateien auf Platten wegsollen, dann eben einfach die Ordner löschen.

On Port 80 or 443? Not possible as Nginx can't recognize other traffic than http. You could add a different port as a stream host, but then you could even forward the used irc port directly to your irc server without using nginx at all. If your provider allows only forwarding 80 and 443 you would need to use an additional container in front of Nginx like this one: https://github.com/yrutschle/sslh By that you could forward by the used protocol to the nginx or irc container.

Ja da steht ja auch dry run. Dann hast du denke ich die --dry-run Zeile aktiviert.

Dein Log sagt aber was anderes?!