Falsche Ausgabe der Festplattenbelegung mit 'df'

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen,


    ich stehe vor einem für mich schier unlösbaren Rätsel: Nachdem ich eine Benachrichtigung erhalten habe, dass auf einer (ext4-)Partition (/dev/sda5) eines (openSuSE 11.4-)Servers der Schwellwert von 80% überschritten worde, wollte ich die Angaben verifizieren.


    Ergebnis:

    Code
    1. # df -h /dev/sda5
    2. /dev/sda5 2,0G 1,6G 287M 86% /var


    Okay, Wert >80%.


    Eine Berechnung der einzelnen Verzeichnisse unter /var und ein

    Code
    1. # du -h --max-depth=0


    ergeben jedoch 784M?!


    Auch über eine 'Größenberechnung' von /var mit bspw. WinSCP kommt - trotz leichter Abweichung - dennoch 816M (...was sich auch in etwa mit den /Daten unter /var deckt) heraus, und nicht 1.6G.


    Wie kommen nun die 1.6G zustande (...die bei dem check (check_mk-df) herangezogen werden)?


    Dankend für eure Unterstützung,
    Mario

  • Hallo Jörg,


    Code
    1. Reserved block count: 26201


    spuckt dumpe2fs aus.


    Was heißt das jetzt aber?


    [zitat]
    dumpe2fs gibt den Superblock und Block-Gruppeninformationen des
    Dateisystems auf der Gerätedatei aus.
    [/zitat]


    //EDIT
    'Reserved block count' sollten bei ext4 ja 5% der Festplatte sein?!

  • HI du,


    als welcher Benutzer machst du das? (Resevered root space maybe)
    Mach mal df als Benutzer root und danach als benutzer nagios (oder wenn auch immer dein monitoring nutzt)


    Gruß,
    Rene

  • Moin Rene,


    unabhängig vom Benutzer kam (!) es immer zur selben Angabe der Größe von /var (...unter 'df'). Ich habe mittlerweile ein Reboot durchgeführt und siehe da, die Partition ist nun unter 'df' mit der (tatsächlichen) Belegung angegeben. Als hätte zuvor 'etwas' temporär diese Partition belegt/reserviert. Nur was hätte das sein können (MySQL?!)?


    Ich werde nun in den kommenden Tagen das Verhalten bzgl. dieser Partition genauer beobachten.


    Danke für eure Hilfe!


    Grüßend,
    Mario

  • Du hast Dateien gelöscht die noch von einem Programm in Benutzung sind.


    Mit


    Code
    1. lsof | grep deleted


    kannst du dir die Dateien und das Programm anzeigen lassen das auf die Dateien noch zugreift.


    Wenn du das Programm restartest werden die Dateien freigegeben und in beiden Ausgaben wird der korrekte frei Speicherplatz angezeigt.

  • Hallo scha,


    es sind - mittlerweile nach einem Reboot des Servers (!) - lt. Ausgabe alles (gelöschte) Dateien (65 Files), die mit mysql 'in Verbindung stehen'.

    Code
    1. %PID% /var/tmp/mysql.r0TkMh/ib.... (deleted)
    2. ...


    (Nun folgt die 'übliche' Angabe:) Diese Files wurden von mir jedoch nicht gelöscht.


    Durch welchen Prozess wurden die Dateien nun aber gelöscht, obwohl sie noch geöffnet/offen sind?


    Dankend,
    Mario


    PS: Wodurch unterscheidet sich eigentlich die Befehle

    Code
    1. lsof | grep deleted


    und

    Code
    1. lsof +L1


    ?


    Bei letzterem Befehl werden nämlich 'nur' 5 Files aus dem obigen Verzeichnis gelistet.


    PPS: Berechtigungen tmpdir

    Code
    1. drwx------ 2 mysql mysql 4096 1. Mär 08:44 mysql.r0TkMh
  • Durch welchen Prozess wurden die Dateien nun aber gelöscht, obwohl sie noch geöffnet/offen sind?

    Das kann durchaus der mysqld selbst gewesen sein. Daß eine Datei, die man geöffnet hat, auch ohne Verzeichniseintrag benutzbar bleibt, ist ein offizielles Feature; Wenn man a) sicher sein will, daß die Datei auch dann gelöscht wird, wenn das sie benutzende Programm wegfliegt, oder b) verhindern will, daß jemand die Daten anhand des Verzeichniseintrags findet und liest, kann man sie also problemlos "voreilig" löschen.

    PS: Wodurch unterscheidet sich eigentlich die Befehle "lsof | grep deleted" und "lsof +L1"?

    Wenn ich der (meiner) Manpage glauben darf, zählt die erste Variante auch umbenannte Files ("to indicate that the path by which the file was opened has been deleted") und die zweite nur echt gelöschte.