[Speicherplatz] Server Control Panel zeigt anderen Wert als df -h

  • Hallöchen zusammen.


    Ich hab schon die Suche bemüht, aber nichts gefunden, was mir bei meinem Problem/meiner Frage hilft (wenn doch, dann gebt mir gern nen Link ^^).


    Heute morgen stand im SCP noch folgendes:

    Speichernutzung 105 GB von 234 GB belegt


    Ich habe ein paar Einträge in den Datenbanken gelöscht, die nicht mehr gebraucht werden.

    Als ich dann wieder ins SCP guckte, stand folgendes:

    Speichernutzung 220 GB von 234 GB belegt


    Das steht seitdem auch weiterhin so da - ich kann mir nicht erklären, warum plötzlich angeblich so viel Speicher belegt ist :huh:


    Wenn ich in der Konsole

    Code
    1. df -h

    eintippe, dann sehe ich folgendes:

    Code
    1. Filesystem                                              Size  Used Avail Use% Mounted on
    2. rootfs                                                  229G   16G  202G   8% /
    3. udev                                                     10M     0   10M   0% /dev
    4. tmpfs                                                   1.2G  224K  1.2G   1% /run
    5. /dev/disk/by-uuid/06a6ce66-e8c9-4167-ade5-93bee20abf1a  229G   16G  202G   8% /
    6. tmpfs                                                   5.0M     0  5.0M   0% /run/lock
    7. tmpfs                                                   2.7G     0  2.7G   0% /run/shm


    Wenn ich

    Code
    1. lsblk

    nutze, dann kommt das raus:

    Code
    1. NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    2. vda    254:0    0   234G  0 disk
    3. |-vda1 254:1    0   1.4G  0 part [SWAP]
    4. `-vda2 254:2    0 232.6G  0 part /
    5. sr0     11:0    1  1024M  0 rom


    Nun bin ich total verwirrt und weiß nicht, was richtig ist und wieso es SO extreme Abweichungen gibt!? :/


    Kann mir vielleicht dabei jemand auf die Sprünge helfen oder mir sagen, was ich tun kann/machen muss, damit das "richtig" ist!? ^^


    Ich nutze aktuell den Rootserver Root-Server L SSD v6 mit 240GB SSD Speicher.


    Dankeschön schonmal im Voraus! :)

  • Hay,


    man fstrim



    und falls als filesystem btrfs im Einsatz ist, alte Snapshots löschen...


    CU, Peter

  • Danke schonmal für die Antworten, werd ich mir mal genauer angucken dieses fstrim :)


    Einen Snapshot gibt es aktuell allerdings nicht mehr, den hab ich gelöscht - daraufhin kam ich von 111 auf 105 runter.

    Aber das erklärt halt dennoch nicht, wieso es dann plötzlich 220 sind laut SCP ^^

  • fstrim wirkt mit etwas Verzögerung. Es werden auch nicht alle Blöcke als frei markiert, nur Stellen ab einer gewissen Größe.


    Führe bitte mal 'fstrim -va' aus. Manchmal gibt es da noch komische Bugs.

  • fstrim wirkt mit etwas Verzögerung. Es werden auch nicht alle Blöcke als frei markiert, nur Stellen ab einer gewissen Größe.


    Führe bitte mal 'fstrim -va' aus. Manchmal gibt es da noch komische Bugs.

    Das sollte ich vermutlich nicht im laufenden Betrieb machen, oder? :D

    Sorry für die dumme Frage - ich bin nur etwas übervorsichtig bei sowas 😅



    Eventuell zusätzlich mal im SCP defragmentieren, das hilft manchmal auch.

    Selbe Frage wie oben - dafür am besten den Server einmal runterfahren oder? :/

  • fstrim kann man auch im laufenden Betrieb ausführen, genau dafür ist es gedacht. ;-)

    Selbe Frage wie oben - dafür am besten den Server einmal runterfahren oder? :/

    Dazu wird der Server automatisch mittels ACPI-Event heruntergefahren. Das sollte aber afaik eh dabei stehen.


    Achtung: Das kann je nach HDD-Größe und Belegung auch mal mehrere Stunden dauern!

  • Ich bin mir nicht sicher, ob fstrim mit vda funktioniert. vda indiziert emuliertes IDE/SATA, während der im scp empfohlene Treiber scsi, virtio-scsi (Devicename dann „sda“) emuliert. Meines Wissens reicht nur scsi oder virtio-scsi trim-Befehle an den Controller durch. Ist das hier anders?


    Shirisu das Umstellen des Treibers bitte noch nicht machen. Ist vorerst nur eine Frage an die Mitposter.

  • Ah okay, also fällt fstrim also eh (erstmal) weg? Okay :/

    fstrim kann man auch im laufenden Betrieb ausführen, genau dafür ist es gedacht. ;-)

    Dazu wird der Server automatisch mittels ACPI-Event heruntergefahren. Das sollte aber afaik eh dabei stehen.


    Achtung: Das kann je nach HDD-Größe und Belegung auch mal mehrere Stunden dauern!

    Hmm, die Platte hat 240GB und laut df -h sind 16GB belegt - ich tippe aber mal, dass man dazu nicht wirklich eine ungefähre Zeitschätzung machen kann? 😅

  • Shirisu ich bin mir ob Deiner Vorkenntnisse nicht sicher, ob wir eine Umstellung auf den anderen Treiber wagen sollten. Sofern Deine /etc/fstab nicht von "/dev/vda" [1-x] spricht, sondern Einträge mit "UUID=" beinhaltet, und auch der Bootloader Deines Debian mit "UUID=" (siehe auch /etc/default/grub) arbeitet, solltest Du gefahrlos auf den SCSI-Treiber im SCP umstellen können. Sollte Linux dennoch nicht mehr booten, müsstest Du den Wert zurückstellen auf virtio. Wenn in grub etwas von "vda" steht, dann lass bitte vorerst die Finger davon und gib Bescheid, dann werden wir uns etwas Zeit nehmen müssen. Ein Backup hast Du ja -wie immer- parat - oder?

    Gelingt die Umstellung, steht Dir fortan fstrim zur Verfügung. Traust Du Dir das zu? Hast Du da noch Fragen dazu? Frag lieber einmal mehr als einmal zu wenig.

  • ich bin mir ob Deiner Vorkenntnisse nicht sicher, ob wir eine Umstellung auf den anderen Treiber wagen sollten. Sofern Deine /etc/fstab nicht von "/dev/vda" [1-x] spricht, sondern Einträge mit "UUID=" beinhaltet, und auch der Bootloader Deines Debian mit "UUID=" (siehe auch /etc/default/grub) arbeitet, solltest Du gefahrlos auf den SCSI-Treiber im SCP umstellen können. Sollte Linux dennoch nicht mehr booten, müsstest Du den Wert zurückstellen auf virtio. Wenn in grub etwas von "vda" steht, dann lass bitte vorerst die Finger davon und gib Bescheid, dann werden wir uns etwas Zeit nehmen müssen. Ein Backup hast Du ja -wie immer- parat - oder?

    Gelingt die Umstellung, steht Dir fortan fstrim zur Verfügung. Traust Du Dir das zu? Hast Du da noch Fragen dazu? Frag lieber einmal mehr als einmal zu wenig.

    Einen Snapshot kann ich aktuell leider nicht machen, weil dazu nicht genügend Speicher vorhanden ist (laut SCP), den alten hatte ich gelöscht.


    Spricht denn grundsätzlich etwas gegen die Defragmentierung (ohne Treiberumstellung)?

    Dann würd ichs erstmal vielleicht damit versuchen? Da geht hoffentlich nichts kaputt!? :D

  • Kaputt gehen kann immer was bei IT… :P


    Mir ist allerdings kein Fall bekannt, bei dem die Defragmentierungsfunktion im SCP etwas zerstört hat. In diesem Sinne: Go for it! :-)

    Ich hab da so ein gewisses Talent... :D

    Aber ich guck mir das morgen nochmal an - und sonst werd ich mir doch einfach einen neuen Server holen und da alles neu einrichten (was eigentlich eh der Plan war) - nur wollte ich vorher eben gucken, wie viel Platz denn nun WIRKLICH benutzt wird und welches Paket ich dann dafür nehme ^^

  • Bedenke, dass das direkte Einspielen eines Snapshots vom größeren auf den kleineren Server scheitern würde (Partitionsgrößen). Aber Du installierst jetzt ja einfach nur neu und richtest drüben Alles neu ein oder? Dann ist das kein Problem.

  • Bedenke, dass das direkte Einspielen eines Snapshots vom größeren auf den kleineren Server scheitern würde (Partitionsgrößen). Aber Du installierst jetzt ja einfach nur neu und richtest drüben Alles neu ein oder? Dann ist das kein Problem.

    Genau :)

    Ich wollte am neuen alles komplett neu einrichten und dann die Dateien und Datenbanken hochladen und alles anpassen, dass es dort genauso läuft.


    Ohne Snapshots oder sonstigem.