df zeigt merkwürdige Werte

[catalpa]

Hallo,
ich habe das Dateisystem einer Platte (nicht boot) wohl etwas geschrottet als ich unvorsichtigerweise sie habe volllaufen lassen ... Ich habe wieder ein paar Brocken gelöscht und verschiedene fsck-Durchläufe gemacht, es scheint auch soweit alles o.k. zu sein. Aber df gibt für die betreffende Platte 100% Belegung aus, obwohl edliche Gb wieder frei sind. Inodes sind ebenfalls massig frei, auf der Platte sind nur große Files. Weiß jemand wie die scheinbelegten Bereiche wieder freigegeben werden können?

 

[SUSEDJAlex]

na dann zeig doch mal

df -a

und poste das Ergebnis als CODE-Tags hier.

LG SUSEDJAlex

 

[catalpa]

Hallo,

vielen Dank für die schnelle Antwort

Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                28703744   4788508  22457164  18% /
devtmpfs               1005796       136   1005660   1% /dev
tmpfs                  1011084         4   1011080   1% /dev/shm
devpts                       0         0         0   -  /dev/pts
/dev/sde2             28703744   4788508  22457164  18% /
proc                         0         0         0   -  /proc
sysfs                        0         0         0   -  /sys
debugfs                      0         0         0   -  /sys/kernel/debug
/dev/sda1            1922859912 1668504608 156679628  92% /srv/laufwerke/l1
/dev/sdb1            961433632 929569112         0 100% /srv/laufwerke/l2
/dev/sdc1            1922859912 1823569592   1614644 100% /srv/laufwerke/l3
rpc_pipefs                   0         0         0   -  /var/lib/nfs/rpc_pipefs
192.168.1.35:/laufwerke
                     5283237312 4423509184 859203840  84% /srv/backup
none                         0         0         0   -  /var/lib/ntp/proc
/dev/sdd1            961433632   4509748 908085808   1% /srv/laufwerke/l4

(Frage am Rande, warum entspricht die Reihenfolge hier nicht der in der fstab?)

Es geht wie man sieht um die /dev/sdb das sdc ist auch sehr voll, zeigt aber die
tatsächlichen Werte an.

hier noch das was beim letzten, intensiven check rausgekommen ist:

/dev/sdb1: Updating bad block inode.

    2986 inodes used (0.00%)
       5 non-contiguous files (0.2%)
       2 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 2626/350
236224260 blocks used (96.74%)
       0 bad blocks
      21 large files

    2773 regular files
     204 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       0 symbolic links (0 fast symbolic links)
       0 sockets
--------
    2977 files

vilen Dank für die Hilfe

 

[catalpa]

ich habe den für root reserv. Bereich mal auf 3% verringert, das brachte 2,5Gb verfügbar, immerhin nicht mehr null aber es sollten eher 30Gb sein... irgendwas ist faul! Kann man den Rootbereich auf den nicht-OS-Platten gefahrlos auf 0% setzen?

 

[spoensche]

ich habe den für root reserv. Bereich mal auf 3% verringert, das brachte 2,5Gb verfügbar, immerhin nicht mehr null aber es sollten eher 30Gb sein... irgendwas ist faul! Kann man den Rootbereich auf den nicht-OS-Platten gefahrlos auf 0% setzen?

Die 5% reservierten freien Platz der / sollte man nicht verkleinern und auch gar nicht erst daran denken. Wenn / vollgelaufen ist oder aber wegen Dateisystemfehlern eine Wiederherstellung durchgeführt werden muss ist man auf die 5% freien Platz angewiesen.

Bei Platten o. Partitionen, wo keine systemrelevanten Daten (Systemrelevant sind: /, /usr, /var) vorhanden sind, könnte man die 5% auf 0% setzen. Allerdings ist es sinnvoller nicht mehr verwendete Daten zu löschen oder ein paar Euros in größere Festplatten zu investieren.

 

[catalpa]

Hi, da es sich bei den vier Platten um reine Archive handel, die einmal vollgeschrieben werden und dann nicht mehr geändert werden (habe schon überlegt die vollen -ro zu mounten) könnte man dass also gefahrlos auf null setzen... hast du eine Idee was ich gegen die Unstimmigkeit zw. belegtem, freien und vorhandenem Speicherplatz der /dev/sdb machen könnte?

 

[Geier0815]

Wie hast Du denn gelöscht? Als root in der grafischen Oberfläche (um gleich das Schlimmste zu vermuten)? Hast Du dann auch deinen "Papierkorb" geleert?

 

[catalpa]

gelöscht wurde über eine smb-Freigabe als samba-user, ohne Windowspapierkorb. auf dem Server arbeite ich nur mit der Konsole, ich denke einen "Papierkorb" gibts dann nicht.

 

[Anonymous]

Wenn du genauere Werte benötigst, dann nimm "stat"
"df" rechnet immer gleich die 5% dort mit herein und gibt so den freien Platz für nicht RootUser an.
Desshalb sind die Laufwerke schon 100% voll und dennoch Platz zum schreiben frei.

Nimm

stat -f /irgend/eine/Datei/im/Filesystem

In der Zeile Blocks ist dann
Free: die genaue Anzahl an Filesystemblöcken die frei sind, (als in der Regel die freien 4096 Byte Blöcke)
Available: ist das was dir "df" anzeigt, also das was der normale User noch beschreiben könnte.

im Script ginge auch gleich: (da bräuchte man nicht mit "grep" und "cut" oder "awk" rumschmippeln)

stat -fc "%f"  /datei

robi

 

[catalpa]

Vielen Dank, probiere ich später aus. Aber eine echte Erklärung ist das nicht, oder? Wie kann es sein, das die Platte bis auf letzte Bit vollgeschrieben wird, Null frei, ich einige Gb lösche es aber bei Null bleibt so, dass ich schon von der root-Reserve was abzwacken muss um überhaupt ein Verzeichnis (leer) anlegen zu können. Für mich sieht das so aus als würde der Speicherplatz der gelöschten Files nicht freigegeben.

 

[RME]

Wie hast Du denn gelöscht? Als root in der grafischen Oberfläche (um gleich das Schlimmste zu vermuten)? Hast Du dann auch deinen "Papierkorb" geleert?

Wenn die gelöschten Dateien in den "Papierkorb" wandern, ändert sich nichts. Du musst den "Papierkorb" leeren.

 

[catalpa]

Beim Löschen von einem XP-Client aus und ohne dass eine GUI benutzt wurde?? Was ist denn dann der Papierkorb? "lost+found"? Hm, in den könnte ich wirklich mal reinsehe, dort könnte fsck was reingeworfen haben...

 

[catalpa]

in Lost+Found war nichts drin...

stat -f auf die Platte erbrachte folgendes:

    ID: 938cc6b9d06db0bf Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 240358408  Free: 7966102    Available: 640391
Inodes: Total: 61054976   Free: 61051962

Mir fällt auf, dass zw. Free und Available locker Faktor 10 ist, bei einer
anderen vollen Platte nur Faktor 2.

 

[Anonymous]

Mir fällt auf, dass zw. Free und Available locker Faktor 10 ist, bei einer
anderen vollen Platte nur Faktor 2.

Die Diffenz zwischen beiden ist immer eine feste Zahl und zwar genau die Anzahl der für root reservierten Blöcke. Wenn du da mit einem Faktor anfangen willst, ist das die falsche Rechenart, je mehr Blöcke belegt sind, desto größer wird der Faktor.
Diese festen reservierten Wert kannst du auch auslesen zB mit

tune2fs -l /dev/sd??

Reserved block count: ist dieser Wert.

robi

 

[RME]

Die Zahlen machen doch Sinn!?

    ID: 938cc6b9d06db0bf Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 240358408  Free: 7966102    Available: 640391
Inodes: Total: 61054976   Free: 61051962

          Total: 240358408
           Free:   7966102  (~ 3%   of Total)
      Available:    640391  (~ 0.3% of Total = ~ 2.6 GByte)

Free - Available = 9325711  (9325711 x 4096 = 38.2 GBytes = ~4% of Total)

Da die Prozentzahlen in "df ..." Befehl nur auf Ganze Prozent angegeben werden, gibt 0.3% = 0%

 

[catalpa]

es tut mir leid, ich verstehe euch nicht... ich hatte die Platte voll, habe einige Gb gelöscht und die Platte war immer noch randvoll, habe die rootreserve von 5% auf 3% gesetzt um überhaupt minmale Dateioperationen machen zu können. Das kann doch nicht normal sein! Wo ist der Speicherplatz geblieben der durch das löschen frei wurde? Ich benutze keine GUI und wüsste nichts von einem Papierkorb auf der Konsole. Bin echt langsam etwas von der Rolle...

 

[RME]

Für mich sieht das so aus als würde der Speicherplatz der gelöschten Files nicht freigegeben.

...könnte sein wenn die "gelöschten" Dateien noch von irgend welchen Prozessen "gelockt" werden ("open file descriptor"). Dann würden "du" und "df" den Unterschied zeigen:

# du -hsx /srv/laufwerke/l2

# df /srv/laufwerke/l2

Den Prozess (falls dies das Problem ist):

lsof | grep deleted

müsstest Du dann killen oder neu starten.

 

[catalpa]

Das war ein echt guter Ansatz, aber leider auch ergebnislos. Es ist vermutlich an der Zeit die Flinte ins Korn zu werfen :/ ich glaube dass ich keine Erklärung mehr finden werde und möchte allen sehr danken die sich Gedanken gemacht haben Das Dateisystem scheint ansonsten keinen Ärger zu machen, ich denke beim nächsten Umkopieren auf eine größere Platte wird das "Speicherloch" verschwinden.

 

[RME]

Es gibt noch die Möglichkeit dass Du verlinkte Dateien hast und Du lediglich ein Link gelöscht hast.

Beispiel:

> df -B 1MB /dev/sda6
Filesystem          1MB-blocks      Used Available Use% Mounted on
/dev/sda6                42295     13156     28065  32% /home
>

> dd if=/dev/zero of=zerofile.dat bs=64k count=5000
5000+0 records in
5000+0 records out
327680000 bytes (328 MB) copied, 2.21921 s, 148 MB/s
>

> ls -l zero*
-rw-r--r-- 1 user0 users 327680000 Oct 16 11:43 zerofile.dat
>

> df -B 1MB /dev/sda6
Filesystem          1MB-blocks      Used Available Use% Mounted on
/dev/sda6                42295     13483     27737  33% /home
>

> ln zerofile.dat zerofile_2.dat

> ls -l zero*
-rw-r--r-- 2 user0 users 327680000 Oct 16 11:43 zerofile_2.dat
-rw-r--r-- 2 user0 users 327680000 Oct 16 11:43 zerofile.dat
>

> df -B 1MB /dev/sda6
Filesystem          1MB-blocks      Used Available Use% Mounted on
/dev/sda6                42295     13484     27737  33% /home
>

Wenn Du jetzt entweder zerofile.dat oder zerofile_2.dat löschst, ändert sich nichts.

Gruss,
Roland

 

[catalpa]

Hi,
ich habe aber keine Links gelöscht, sondern einen Teil der Daten die ich auf der LW kopiert habe und diese habe ich von der Quelle noch mal auf eine weitere Platte kopiert. Kurz: ich habe eine 2TB Platte auf eine 1TB und eine andere 2TB aufgeteilt, aus Faulheit habe ich das, wissend dass es überlaufen wird, angeschmissen und nach dem Überlauf auf eine "optisch" nette Stelle zurückgeschnitten. Dabei hätten eigentlich n paar Gb frei werden sollen, sind es aber nicht. Links dürften keine dabei gewesen sein. Kopiert habe ich auf dem Server als root mit cp und gelöscht habe ich von einem XP-Client als Samba-user.