Leap 42.1, Rootverzeichnis nicht aufräumbar

Hinweis: In dem Thema Leap 42.1, Rootverzeichnis nicht aufräumbar gibt es 25 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Hallo,


    mit großer Begeisterung mußte ich feststellen, daß einer meiner Rechner hängt, da das auf /dev/sda2 liegende
    Rootverzeichnis die Partition fast völlig ausfüllt: Löschen in /tmp und /var/tmp brachte kaum Erfolg, auch in
    /var/log alle auf ~ enden Dateien löschen brachte kaum etwas. snapper delete 1 funktioniert nicht, alle
    anderen Snapshots sind gelöscht.
    df -h liefert



    während du -hx -d 1 /

    liefert. btrfs filesystem df / meint

    Code
    Data, single: total=32.69GiB, used=15.55GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=3.62GiB, used=938.36MiB
GlobalReserve, single: total=320.00MiB, used=0.00B

    Ein fast baugleicher und mit fast gleicher Software bespielter Rechner, der allerdings längere Zeit nicht gelaufen ist, kommt nur auf eine 48%ige Belegung von /dev/sda2.
    Der Vollständigkeit halber noch snapper -list (Nach Löschaktion)

    Code
    Typ    | # | Vor # | Datum                       | Benutzer | Bereinigen | Beschreibung          | Benutzerdaten
-------+---+-------+-----------------------------+----------+------------+-----------------------+--------------
single | 0 |       |                             | root     |            | current               |              
single | 1 |       | Fr 13 Nov 2015 20:49:52 CET | root     |            | first root filesystem |

    Tja jetzt ist guter Rat teuer. Wie bekomme ich den wahrscheinlich vom Dateisystem verschwndeten Speicher wieder frei?



    MfG

    So wie ich das sehe, ist ja die Hälfte noch frei.


    df bei btrfs zu verwenden erzeugt falsche Ergebnisse.

    Für den Inhalt des Beitrages 98747 haftet ausdrücklich der jeweilige Autor: Sauerland

    sooo schlecht ist das btrfs nicht.


    Installiere dir das gleichnamige Konsolenprogramm und spiele damit ein wenig.
    Damit kann man ganz prima Platz schaffen.


    openSUSE hat da leider eine etwas moderne Konfiguration mitgegeben,
    die User halten eher an den längst vergangenen "aber 20GB für usr var boot und root sind doch genuch!" fest.

    Zitat von keineheulsuse

    mit großer Begeisterung mußte ich feststellen, daß einer meiner Rechner hängt, da das auf /dev/sda2 liegende
    Rootverzeichnis die Partition fast völlig ausfüllt: Löschen in /tmp und /var/tmp brachte kaum Erfolg, auch in
    /var/log alle auf ~ enden Dateien löschen brachte kaum etwas. snapper delete 1 funktioniert nicht, alle
    anderen Snapshots sind gelöscht.

    das blinde Aufräumen bringt gar nix und wenn du die root-partition schon auf 37 GB gesetzt hast ist btrfs höchstwahrscheinlich nicht der Schuldige.
    Btrfs ist zwar der 'übliche Verdächtige' - aber trotzdem selten der Verbrecher ..


    Das Problem sind vielfach log-dateien. Da kannst du zwar den Dateinamen löschen, sofern aber die dateien während des Löschvorgangs durch irgendein Programm geöffnet waren werden sie trotzdem kräftig weiter gefüllt ....und sie können überall sitzen ..
    -------
    soo .. um das mal genauer einzugrenzen:


    mit

    Code
    'zypper in ncdu'

    das tool ncdu installieren.


    dann die root-Konsole aufmachen und nach / navigieren
    dort eingeben

    Code
    ncdu -x /

    man achte auf das KLEINE 'x'


    dann kriegst du eine sehr aussagekräftige Übersicht, welche Ordner/verzeichniss wieviel Platz belegen.
    Mit dem Ergebnis meldest du dich dann hier wieder. Dann können die Ursachen etwas qualifizierter beseitigt werden.


    Das ganze machst du am besten mit einem neu gestarteten Rechner .. damit die 'Schuldigen' noch mit Dateiname existent sind.

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 98771 haftet ausdrücklich der jeweilige Autor: wurzel99

    ncdu ist nett, du -hx -d 1 / tut es allerdings auch. Die interessante Beobachtung: df -h zeigte gestern noch fast
    vollständige Belegung, heute dagegen nur noch 53%, was halbwegs zu den du-Daten paßt, obwohl am
    Dateisystem nichts mehr verändert wurde (bis auf /var/log u.ä. natürlich). Der Speicher wurde anscheinend
    verzögert freigegeben, obwohl ich den Rechner nach dem Löschen rebootet hatte, um alle Prozesse, die
    eventuell noch handles offenhaben, zu beenden.
    Wahrscheinlich setzte ich jetzt cronjobs auf, die /var/log usw. bereinigen.

    Zitat von keineheulsuse

    ncdu ist nett, du -hx -d 1 / tut es allerdings auch

    na ja ... ich glaub du hast dir ncdu nicht richtig angeschaut ..


    aber wenn dir dein 'du -hx -d 1' aussagekräftig genug ist .. es scheint dir aber nicht die Problemdateien zu liefern.


    Es sollte dir schon wichtig sein, wer hier das Filesystem vollmüllt. Dabei helfen cronjobs kaum.
    Ursachen bekämpfen - nicht die Symptome.

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 98781 haftet ausdrücklich der jeweilige Autor: wurzel99

    Bei Standardeinstellungen werden Tempfiles von systemd bei Systemstart gelöscht.
    Und das sogar in Abhängigkeit vom "Füllungsgrad".
    Viele, nicht alle.

    Zitat von wurzel99

    na ja ... ich glaub du hast dir ncdu nicht richtig angeschaut ..
    aber wenn dir dein 'du -hx -d 1' aussagekräftig genug ist .. es scheint dir aber nicht die Problemdateien zu liefern.


    Es sollte dir schon wichtig sein, wer hier das Filesystem vollmüllt. Dabei helfen cronjobs kaum.
    Ursachen bekämpfen - nicht die Symptome.

    ncdu verstehe ich als du mit ncurses-Oberfläche. Damit dürfte die Suche nach Quellen des Speicherplatzmangels
    in der Tat einfacher sein.
    Wer müllt mir die Platte zu - das Dateisystem selbst mit Snapshots, und zypper in /var/tmp. Gut in /var/log
    kann man auch noch auf ~ endende Dateien löschen.