No space left on device....

[shuo]

Hallo zusammen,

ich habe openhabian 3.1 im Einsatz. Neuerdings kommen immer wieder Fehlermeldungen, dass ich kein Speicherplatz mehr zur Verfügung habe.

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/zram1      275M    269M     0  100% /opt/zram/zram1
overlay1        275M    269M     0  100% /var/lib/openhab/persistence
/dev/zram2      178M    174M     0  100% /opt/zram/zram2
overlay2        178M    174M     0  100% /var/log

Für was sind denn diese Partitionen und das gewünscht das nur 275MB bzw 178MB dafür reserviert werden?

Nach einem Neustart sieht es so aus:

Code: Alles auswählen

/dev/zram1      275M    332K  254M    1% /opt/zram/zram1
overlay1        275M    332K  254M    1% /var/lib/openhab/persistence
/dev/zram2      178M    126M   38M   77% /opt/zram/zram2
overlay2        178M    126M   38M   77% /var/log

Ist das etwa eine Swap-Partition?

Vielen Dank vorab!

[udo1toni]

Wenn das alles ist, was df -h ausspuckt, dann fehlt die SD-Karte.

Code: Alles auswählen

udo1toni@player1:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            426M       0  426M    0% /dev
tmpfs            93M    2,7M   90M    3% /run
overlay         463M    101M  362M   22% /
tmpfs           463M       0  463M    0% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           463M       0  463M    0% /sys/fs/cgroup
/dev/mmcblk0p1  253M     57M  196M   23% /boot
tmpfs            93M       0   93M    0% /run/user/1001
udo1toni@player1:~ $

So sieht das bei mir auf einem System aus (ich habe per raspi-config die SD-Karte nur lesbar eingebunden)
Ein anderes System (ohne ReadOnly) zeigt dies:

Code: Alles auswählen

udo1toni@raspberrypi:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        30G    2,7G   26G   10% /
devtmpfs        213M       0  213M    0% /dev
tmpfs           217M       0  217M    0% /dev/shm
tmpfs           217M     22M  195M   11% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           217M       0  217M    0% /sys/fs/cgroup
/dev/mmcblk0p1   44M     23M   21M   52% /boot
tmpfs            44M       0   44M    0% /run/user/1001
udo1toni@raspberrypi:~ $

Unterschied ist, glaube ich, gut erkennbar. Bei Dir fehlt aber der Einhängepunkt /, der ist nicht optional. Kann natürlich sein, dass das mit ZRAM zusammenhängt, das nutze ich nirgends.

[shuo]

hatte nicht alle Partitionen gepostet. So sieht es vollständig aus:

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        59G     55G  935M   99% /
devtmpfs        455M       0  455M    0% /dev
tmpfs           487M       0  487M    0% /dev/shm
tmpfs           487M    1,4M  486M    1% /run
tmpfs           5,0M    8,0K  5,0M    1% /run/lock
tmpfs           487M       0  487M    0% /sys/fs/cgroup
/dev/mmcblk0p1  253M     48M  205M   19% /boot
/dev/zram1      275M    269M     0  100% /opt/zram/zram1
overlay1        275M    269M     0  100% /var/lib/openhab/persistence
/dev/zram2      178M    132M   33M   81% /opt/zram/zram2
overlay2        178M    132M   33M   81% /var/log
tmpfs            98M       0   98M    0% /run/user/1000

Und zram ist seit dem Neustart jetzt und weitere 4% gestiegen

Was ist denn zram für eine Partition und warum wächst die so schnell an?

[udo1toni]

Siehst Du, nun wird ein Schuh draus.

Deine Root-Partition ist so gut wie voll.

Vermutlich gibt es ein einzelens Programm, welches verrückt spielt. Zum Eingrenzen kannst Du mit dem Befehl du -hs * den Schuldigen lokalisieren.
Du bewegst Dich also Schritt für Schritt im Verzeichnisbaum dorthin, wo der große Brocken ruht. Du startest in / und wechselst dann jeweils in das Verzeichnis, welches am meisten Platz braucht.

Es gibt einen heißen Kandidaten, den Du auf diese Weise aber ebenfalls sehr gut identifizieren kannst, und falls er es nicht ist, bist Du dennoch ein Stück weiter. Der heiße Kandidat ist das openHAB Backup. Falls Du also im backups Ordner eine Reihe von zip-Dateien findest, welche ungewöhnlich groß sind, kannst Du die einfach löschen. Aber wie gesagt, das ist nur eine Vermutung ins Blaue, es gibt noch diverse andere "Kandidaten", je nachdem, was alles auf dem Raspberry installiert ist.

[shuo]

Es waren die backups. Danke für den Tipp. Gelöscht und inzwischen wieder alles okay.

Ist das ein bekanntes Problem? Kann ich irgendwie Vorkehrungen treffen?

Btw: zram1 ist dennoch bei 100%? zram2 ist bei 71%

[udo1toni]

Das Problem mit den Backups tritt auf, wenn Du ein Backup anlegst, das zip-File aber nicht aus dem backups-Verzeichnis entfernst. openHAB wird dann beim nächsten Mal das Zip-File mit ins Backup packen (ja, das sollte nicht passieren - passiert aber immer wieder...) und solange die zip-Dateien nicht weggeschoben werden, wiederholt sich der Vorgang jedes Mal auf's neue. Dabei wächst das Archiv im Verhältnis zu seinen Vorgängern vermutlich geometrisch oder so... lange her..., weil die zip-Dateien alle nicht inhaltlich ähnlich sind.

Das Problem ist bekannt, ich war aber bisher davon ausgegangen, dass es (vor laaaanger Zeit) gefixt wurde. Es hat den Anschein, als wäre diese Annahme falsch

[shuo]

Hi Uwe,

Kurze Frage. Ich habe immer noch das Problem, dass zram1 und zram2 bei 100% sind. Hast Du eine Idee woran das liegen könnte?

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        59G    8,0G   48G   15% /
devtmpfs        455M       0  455M    0% /dev
tmpfs           487M       0  487M    0% /dev/shm
tmpfs           487M     57M  431M   12% /run
tmpfs           5,0M    8,0K  5,0M    1% /run/lock
tmpfs           487M       0  487M    0% /sys/fs/cgroup
/dev/sda1       117G     28G   83G   26% /media/SSD
/dev/mmcblk0p1  253M     48M  205M   19% /boot
/dev/zram1      275M    269M     0  100% /opt/zram/zram1
overlay1        275M    269M     0  100% /var/lib/openhab/persistence
/dev/zram2      178M    174M     0  100% /opt/zram/zram2
overlay2        178M    174M     0  100% /var/log
tmpfs            98M       0   98M    0% /run/user/1000

[udo1toni]

Ist das denn tatsächlich ein Problem (also: hat das Auswirkungen)? Es könnte durchaus sein, dass ZRAM immer auf 100% steht, das ist ja kein gewöhnliches Dateisystem. da ich das nicht nutze, ist das aber nur eine Vermutung.

[shuo]

Keine Ahnung ob es Auswirkungen hat. Dazu müsste ich erstmal verstehen was es macht:)

Muss mich mal durchgooglen. Werde berichten....

[udo1toni]

Na, Auswirkungen hat es, wenn irgendwas nicht wie erwartet funktioniert. Graphen werden nicht gezeichnet, openHAB stürzt mit Speicherfehler ab usw.
Wenn Du nichts dergleichen bemerkst, lohnt es sich nicht, dort intensiv zu suchen. ZRAM minimiert die Schreibzugriffe auf die SD-Karte, das macht es, indem die Schreibzugriffe auf ein Overlay Dateisystem umgeleitet werden, welches in einer (bzw. mehreren) RAM-Disks angelegt ist. Wenn der Rechnet mittels shutdown -h now heruntergefahren wird, schreibt ZRAM den Inhalt des Overlay in einem Rutsch auf die SD-Karte. Damit wird wearout verhindert.
Wichtig ist nur, dass der Rechner immer sauber heruntergefahren wird.

ZRAM nimmt nicht einfach soundsoviel RAM für das Overlay, sondern passt vermutlich die Größe dynamsich an, so dass das Maximum an RAM für andere Software zur Verfügung steht. Offensichtlich beeinflusst das die Anzeige von df.