Platten voll, obwohl laut df -h nicht ?

[flashman]

Hilfe....Der folgende Fehler erscheint mir obskur.

1. dmesg:
Jun 2 00:07:09 srv kernel: pid 23163 (httpd), uid 80 inumber 2802688 on /: filesystem full
Jun 2 00:07:09 srv kernel: pid 22838 (mysqld), uid 88 inumber 2384659 on /: filesystem full
Jun 2 00:07:09 srv kernel: pid 22838 (mysqld), uid 88 inumber 2384661 on /: filesystem full
Jun 2 00:07:13 srv kernel: pid 23166 (httpd), uid 80 inumber 2802688 on /: filesystem full

...OK, kann ja passieren, aber:

2. df -h
/dev/da0s1a 31G 17G 22G 47% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da1s1d 33G 16G 14G 54% /www

...Holla, da ist aber viel frei

3. Idee: fsck_ufs gestartet, dann diese Meldung (mit aufsteigendem I) für ca. 7min auf dem Schirm, also viele zehntausend mal
UNREF FILE I=4478246 OWNER=538 MODE=100644
SIZE=24315 MTIME=May 3 11:43 2004
RECONNECT? no


CLEAR? no

.
.
.
Zum Ende
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

374093 files, 8985317 used, 7998985 free (53761 frags, 993153 blocks, 0.3% fragmentation)

Ich habe das Gefühl, dass die Programme denken, die Platten seien voll, weil da "Inodes" irgendwie nicht freigegeben wurden und noch Platz belegen.

Dazu ist zu sagen, dass vor kurzem, dass Dateisystem wirklich überlief, weil ein Logfile auf über 20Gbyte überquoll (innerhalb von Stunden). Wurde dann gelöscht.

Sonnige Grüße zur Nacht, über Hilfe, Tipps und Anregungen würde ich mich sehr freuen.

Danke,
Andreas

 

[nintendo]

nicht die Platte ist voll, sondern der / slice (die FreeBSD root-Partition)
das wäre für mich die einzige Erklärung :-/

 

[thor]

Schau doch mal bitte, was auf / voll ist, also welcher Bereich, vielleicht knallt es dir grade wieder /var oder /tmp dicht.

Gruß,

Thorsten

 

[asg]

Was sagt "df -i"?

 

[Ice]

@flashman

Ich denke, dass Du mit Deiner Vermutung bezüglich der Inodes durchaus recht haben könntest. Ich würde, wie ags bereits empfohlen hat, mal mit "df -i" die Statistiken zu den Inodes überprüfen. Ansonsten "fsck -y" drüberrennen lassen.

Gruß,

Ice

 

[flashman]

Guten Morgen :-)

df -i bringt:

Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/da0s1a 32767276 6652856 23493038 22% 68816 4170542 2% /
devfs 1 1 0 100% 0 0 100% /dev
/dev/da1s1d 34750342 17275908 14694408 54% 362909 4135521 8% /www

Dazu ist zu sagen, dass ich einige Sachen gestern nacht noch gelöscht habe, deshalb steht da jetzt was von 22% Nutzung. Ich kam auch schon auf die Idee, nach neuen (find / -ctime +100m) oder übergroßen (find / -size +100000) Dateien zu suchen, aber diesmal sieht alles normal aus.

Ich habe auch schon fsck -y laufen lassen, aber seltsamerweise antwortet das System doch immer mit "n" auf die fsck Fragen und es steht am Anfang immer da "NO WRITE"..

fsck -y
** /dev/da0s1a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1413122 (16 should be 0)
CORRECT? no

Das System ist FreeBSD 5.1 mit UFS und Softupdate enabled.

Thema Slice: Der Slice ist eigentlich so groß, wie die Platte und die war zuvor auch dirchaus schon übervoll: wegen eines Logfiles (das wird jetzt nach /dev/null geschrieben) .

fsck -y könnte sicher klappen, aber wie... -y scheint ja nichts zu bringen?

Sonnige Grüße,
Andreas

 

[MrFixit]

Aua, aua, aua. Ist das hier Linux? Warum packst du alles auf eine Partition? Ist ja nicht so, dass du fuer jede Partition einen eigenen Slice benoetigst (wie bei einem anderen populaeren Unix-artigen OS).

/ braucht nur ca. 200MB gross sein. Fuer /var und /usr macht man dann eigene Partitionen. Fuer /www kannst du natuerlich ebenfalls eine eigene Partition erstellen.

Das ganze macht man auch nicht zum Selbstzweck, nein, der erfahrenen Unix-Admin kann dann auf den versch. Part. die FS-Parameter entsprechend tunen (INode Dichte, space reserve, time/space optimierung). Aber das sind noch nicht mal alle Gruende...

Gib doch nochmal bitte die Ausgabe von df -i, aber packe sie in einen code-Tag, das kann man sonst so schlecht lesen...

 

[flashman]

Holla :-))

Auch bei Linux stimmt Dein Hinweis natürlich. Man sollte die Partitionierung etwas mehr durchdenken. Aber nun ist es erstmal so, wie es ist

Filesystem  1K-blocks     Used    Avail Capacity iused   ifree %iused  Mounted on
/dev/da0s1a  32767276  6748156 23397738    22%   68780 4170578    2%   /
devfs               1        1        0   100%       0       0  100%   /dev
/dev/da1s1d  34750342 17516130 14454186    55%  370558 4127872    8%   /www

Ich denke mal, aufgrund der Ausgaben von fsck (ca. 7min bei DSL via SSH), dass "viele" Inodes einfach nicht "Reconnected" wurden?! Leider behebt fsck den Fehler nicht automatisch, ich muss wohl die Platte als Read-Only remounten (was ich aber irgendwie nicht via SSH tun sollte / kann) und dann fsck nochmal drüberlaufen lassen. Oder gibt es eine andere Lösungsidee?

fsck -F -y bringt nix, es startet mit "NO WRITE" und antwortet auf alle Fragen min "no". Einen Force-Mode gibts wohl nicht.

Sonnigst,
Andreas

 

[MrFixit]

(Re-)Boote in den Singleuser Modus und lasse da fsck laufen. An zu wenigen INodes kanns ja anscheinend nicht liegen...
fsck -f ist fuer force gedacht, -F heisst foreground. Siehe fsck(1). rw-gemountete Partitionen koennen auch nicht gefixt werden, die muss man unmounten bzw. ro mounten.

 

[flashman]

Oh, ich sehe gerade, der Server läuft ja gar nicht auf FreeBSD sondern Windows... Nurn Spass!

Die Option -f brauche ich auch nicht eingeben, der läuft schon automatisch an. Aber besten Dank für die Bestätigung meiner Vermutung, für das Reparieren, mal den Single-User-Mode anzusteuern. Sind denn die aufgezeigten Fehler schwerer natur oder eher als Bagatelle einzustufen?

So siehts aus:

** /dev/da0s1a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1413122 (16 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2393857 (4 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2395073 (32 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2395074 (1440 should be 384)
CORRECT? no

INCORRECT BLOCK COUNT I=2395190 (4 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2395191 (3456 should be 384)
CORRECT? no

INCORRECT BLOCK COUNT I=2473380 (103424 should be 102848)
CORRECT? no

INCORRECT BLOCK COUNT I=2474011 (33248 should be 33216)
CORRECT? no

INCORRECT BLOCK COUNT I=2474029 (20224 should be 20096)
CORRECT? no

INCORRECT BLOCK COUNT I=2802688 (8 should be 4)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
UNREF DIR  I=3179962  OWNER=662 MODE=40777
SIZE=2560 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3579905  OWNER=www MODE=40755
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3579904  OWNER=www MODE=40755
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3579908  OWNER=www MODE=40755
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3556397  OWNER=www MODE=40777
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3556390  OWNER=www MODE=40777
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3556389  OWNER=www MODE=40777
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

UNREF DIR  I=3556373  OWNER=662 MODE=40755
SIZE=512 MTIME=Jun  2 00:07 2004 
RECONNECT? no

Die letzten Meldungen rasseln für ca. 10min über den Schirm.

Danke und sonnige Grüße,
Andreas

 

[flashman]

Puh...Überstanden. Besten Dank für die Hilfe. Ich konnte doch via SSH die / Partition auf read-only remounten und dann fsck -y drüberlaufen lassen. Hat 20min gedauert, dann war er fertig. Seit dem laufen alle Prozesse wieder einwandfrei. (Ja, ich habe rebootet).

Eine Sache war allerdings sehr seltsam. Nach dem Neustart schrieb er (Ende dmesg), dass er nun auch /www (extra Platte) checken würde und hat dann zwei(!) Neustarts (jeweils nach etwa 10min) ausgeführt. Kann es sein, dass fsck im Hintergrund die Platte repariert hat und die Neustarts für wichtig hielt?

Auf jeden Fall läuft er wieder wie eine Eins...Danke nochmal für die Hilfe! Wenn jemand mal Hilfe mit seinem Jeep braucht, bin gerne zur Stelle.

Bis dann,
Andreas

 

[kazcor]

Hmm, automatische Neustarts macht vielleicht Windows, aber bei BSD kann man glaub ich eher davon ausgehen, dass da was ziemlich im Eimer ist/war - wenn ich nicht irre.

Wenn du deine /etc/syslog.conf nicht groß geändert hast und syslog läuft schreibt er die Sachen zum background-fsck ins log /var/log/messages, d.h. ein

cat /var/log/messages | grep "fsck"

sollte alle fscks der letzten zeit auflisten.
Falls das Datum schon länger her ist tut's auch ein

bzcat /var/log/messages.*.bz2 | grep "fsck"

Die Frage ist, ob das log da beim fsck noch sauber gelandet ist, oder eher beim Neustart mit zerschrotet wurde.

 

[MrFixit]

Neustart beim fsck? Niemals.
-> Schrottiger RAM (fsck braucht RAM entsprechden der Partitionsgroesse)
-> schwaches NT (Wenn die Platte gut Strom zieht)
-> Ueberhitzung
-> schrottige ATA-Hardware