rm löscht dateien nicht "richtig"

[harteknut]

Hallo zusammen,

bei mir ist auf einer NAS ein Laufwerk vollgelaufen, der imap-Server will nicht mehr
Ich habe also ca. 10GB alte Filme gelöscht, die da noch rumlagen, und zwar mit rm über eine ssh-Konsole.

Danach waren die Dateien zwar weg, es gibt aber nach wie vor keinen verfügbaren Speicherplatz:

Code: Alles auswählen

root@Netzplatte-3:~# df
Dateisystem                                            1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf
rootfs                                                 480114424 468893520         0  100% /
udev                                                       10240         0     10240    0% /dev
tmpfs                                                      12560      1452     11108   12% /run
/dev/disk/by-uuid/be46378c-5f46-45c4-853d-45630ecb82a3 480114424 468893520         0  100%
tmpfs                                                       5120         0      5120    0% /run/lock
tmpfs                                                      98220         0     98220    0% /run/shm
/dev/sda1                                                 233191     12717    208033    6% /boot
tmpfs                                                      98220         0     98220    0% /tmp

Laufwerk /dev/disk/by-uuid/be46378c-5f46-45c4-853d-45630ecb82a3 hat zwar mehr Blöcke als benutzt werden, trotzdem ist 0% verfügbar...
Versteh ich nicht, was ist denn da los? Kann mir das jemand erklären? Dateisystem ist ext4

Würde mich über jede Antwort freuen,
Simon

[schorsch_76]

Ein Prozess hat sie noch geöffnet. Am einfachsten ... neu booten.

[cosmac]

hi,

wenn die Platte randvoll war, muss man mindestens 24GB löschen, bevor es bei df sichtbar wird und normale User wieder schreiben können. Das sind die 5% von 460GB, die für root reserviert sind.

[harteknut]

Danke für die schnellen Antworten!
Reboot hab ich schon versucht, ohne Erfolg.
Und das mit dem root verstehe ich nicht:
Wieso konnten denn die 5% vorher beschrieben werden?

Werde mal weiterlöschen und gucken, wann sich was tut...

[cosmac]

naja, "für root reserviert" heisst ja, dass root dort schreiben darf...

[Meillo]

wenn die Platte randvoll war, muss man mindestens 24GB löschen, bevor es bei df sichtbar wird und normale User wieder schreiben können. Das sind die 5% von 460GB, die für root reserviert sind.

Kannst du das bitte erklaeren? Hat das was mit ext4 zu tun?

Ich habe hier ein 8 GB ext3 root filesystem (ext3) das regelmaessig weniger als 400 MB freien Platz hat, und das ohne dass ich den Platz als root fuelle.

[frox]

Schau mal via "versteckte Dateien anzeigen", ob da nicht irgendwo ein lokaler Trashordner angelegt wurde.

Das Problem hatte ich mal mit Thunar/XFCE4. Der hatte mir auf jeder Externen beim Löschen ein Trashverzeichnis in quasi gleicher Größe angelegt. Also nichts gelöscht, sondern nur intern verschoben. Platzersparnis = Null.

Und ja, ich habe gelesen, dass du auf der Konsole unterwegs warst. Aber nachschauen muss ja nichts schaden. Ich habe mich da damals dumm und dämlich gesucht.

[cosmac]

Hat das was mit ext4 zu tun?

ich glaube nicht, dass sich ext3 und ext4 in der Hinsicht unterscheiden. Auch der Default-Wert ist laut "man mkfs.ext4" immer noch 5%.

Ich habe hier ein 8 GB ext3 root filesystem (ext3) das regelmaessig weniger als 400 MB freien Platz hat, und das ohne dass ich den Platz als root fuelle.

wer sagt das, df oder?
* wenn df "400MB Available" sagt, dann sind in Wirklichkeit 800MB frei.
* wenn df "0MB Available" sagt, kann ein normaler User nicht mehr schreiben, außer, jemand hat mit "tune2fs -u" oder "tune2fs -g" gespielt (oder du hast ein anderes df).
* wenn wirklich weniger als 400MB frei sind und der User noch schreiben kann, dann hat jemand die 5% reduziert.
* was anderes fällt mir nicht ein

ein paar Links, die die Frage auch nicht beantworten:
viewtopic.php?f=29&t=144854
http://www.redhat.com/archives/ext3-use ... 00026.html
http://de.linwiki.org/wiki/Linuxfibel_- ... teisysteme

[Meillo]

Ich habe hier ein 8 GB ext3 root filesystem (ext3) das regelmaessig weniger als 400 MB freien Platz hat, und das ohne dass ich den Platz als root fuelle.

wer sagt das, df oder?

Ja.

* wenn df "400MB Available" sagt, dann sind in Wirklichkeit 800MB frei.

Tatsaechlich!

Code: Alles auswählen

$ df / | awk 'NR>1{print; print "blocks usable:\t", $3+$4}'
/dev/sda1        7827080 6756260    673216  91% /
blocks usable:   7429476

Ist ja unglaublich! ... das hoere ich zum ersten Mal. Danke fuer die Erleuchtung.

Jetzt brauche ich mir ja keine Sorgen mehr ueber das scheinbar (!) volle Dateisystem machen: Ich wechsel einfach zu root und habe -- schwupps -- weitere 400 MB zur Verfuegung.

[Radfahrer]

Jetzt brauche ich mir ja keine Sorgen mehr ueber das scheinbar (!) volle Dateisystem machen: Ich wechsel einfach zu root und habe -- schwupps -- weitere 400 MB zur Verfuegung.

Guter Plan!

[peschmae]

Jetzt brauche ich mir ja keine Sorgen mehr ueber das scheinbar (!) volle Dateisystem machen: Ich wechsel einfach zu root und habe -- schwupps -- weitere 400 MB zur Verfuegung.

Oder du wirfst tune2fs an und nimmst Root die Blöcke weg!

MfG Peschmä

[Radfahrer]

So mache ich es bei meinen Datenpartitionen. Allerdings setze ich reservierten Blöcke nicht ganz auf Null, sondern auf 0.1%.
Bei der /-Partition würde ich das lieber nicht machen. Wenn die dann mal aus irgendeinem Grund vollläuft, wäre das nicht so gut, weil root sich dann nicht mehr einloggen und etwas unternehmen kann.

[harteknut]

Hier lernt man was, aber ganz hab ichs noch nicht verstanden:
Wenn 5% für root reserviert sind, dann sind die doch immer reserviert, oder nicht?
Bei mir ist folgendes passiert:
Füllstand ist auf 100% angelaufen, indem ich Dateien draufschiebe. Dann lösche ich die Dateien wieder, der Füllstand bleibt aber auf 100%.

Es klingt echt nach einer Art Papierkorb, aber auch die Papierkorbdateien werden doch bei df als "Benutzt" angezeigt, oder nicht?
Habe übrigens keinen versteckten Trash gefunden.

Ich verschiebe fleißig auf externe USB-Platten und bin gespannt, wann der verfügbare Platz über 0% steigt...

[cosmac]

oO, wir haben das wichtigste aus den Augen verloren: die Suche nach dem Schuldigen. Wenn du Pech hast, schreibt der die Platte schneller voll, als du löschen kannst. Mehrmals "df" ohne "-h" im Abstand von ein paar Sekunden oder Minuten wäre jetzt angesagt.

Dann müsste man die zu großen Datei(en) finden. Dafür fällt mir leider nur "du -h /var | grep G" ein (evt. auch "du -h /var | more"). Wenn in /var nichts zu finden ist, kommt /tmp dran, dann würde ich "ls -la /" probieren.. Danach bleibt wohl nur noch "du" mit allen anderen Verzeichnissen -- außer, jemand hat eine bessere Idee.

[harteknut]

Hmm, da schreibt aber keiner. Die benutzten Blöcke sinken ja kontinuierlich, wenn ich lösche. Ich hab nur nix davon, weil nix verfügbar wird.

Aber der Erfolg von tune2fs gibt euch Recht! Habe den reservierten Platz mal auf 0.2% gesetzt, schon sind knapp 20GB verfügbar und die Verw% sinkt von 100% auf 96%.

Code: Alles auswählen

root@Netzplatte-3:~# tune2fs -m 0.2 /dev/sda2
tune2fs 1.42.5 (29-Jul-2012)
Der Prozentsatz reservierter Böcke wird auf 0.2% (243884 Blöcke) gesetzt
root@Netzplatte-3:~# df
Dateisystem                                            1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf
rootfs                                                 480114424 458832132  20306756   96% /
udev                                                       10240         0     10240    0% /dev
tmpfs                                                      12560       472     12088    4% /run
/dev/disk/by-uuid/be46378c-5f46-45c4-853d-45630ecb82a3 480114424 458832132  20306756   96% /
tmpfs                                                       5120         0      5120    0% /run/lock
tmpfs                                                      98220         0     98220    0% /run/shm
/dev/sda1                                                 233191     12717    208033    6% /boot
tmpfs                                                      98220         0     98220    0% /tmp

Das ist doch plausibel oder?
Dann kanns ja endlich weiter gehen
Vielen Dank an die umfangreiche Hilfe!