Hi! Kürzlich ist auf einem der Server, die ich administriere, folgendes passiert: Jan 23 11:15:17 xxxx squid[733]: diskHandleWrite: FD 16: disk write error: (28) No space left on device Jan 23 11:15:17 xxxx squid[733]: storeUfsWriteDone: got failure (-6) Jan 23 11:15:17 xxxx squid[733]: WARNING: Shrinking cache_dir #0 to 98298 KB Das Problem führte dann letztendlich dazu, daß Squid sich beendete... Und dabei ist *massig* Platz auf der Squid-Cache-Partition! Etwas später passierte dann folgendes: Jan 24 13:23:51 xxxx dhcpd: Wrote 9 leases to leases file. Jan 24 13:23:51 xxxx dhcpd: commit_leases: unable to commit: No space left on device Jan 24 13:23:51 xxxx dhcpd: Can't commit leases to new database: No space left on device ... Jan 24 13:23:51 xxxx dhcpd: exiting. Nach einem manuellen Neustart von Squid und Dhcpd läuft jetzt beides wieder - aber was ist da passiert? Hat hier jemand schon ähnliches beobachtet? Ich tippe mal auf ein Kernel-Problem (Linux xxxx 2.4.7-4GB #1 Thu Oct 25 17:53:12 GMT 2001 i686 unknown) - sollte ich generell auf die letzte offizielle SuSE-Version (2.4.16-20011220 für SuSE 7.2) updaten, oder handele ich mir damit neue Probleme ein? (SuSE hat ja anscheinend gerade zwei neuere 2.4.16-Versionen (-20020121 und -20020123) wieder vom Update-Server genommen...) Martin
Hallo Martin, _____________________________________ On Fri, 25 Jan 2002, Martin Köhling wrote:
Jan 23 11:15:17 xxxx squid[733]: diskHandleWrite: FD 16: disk write error: (28) No space left on device Das Problem führte dann letztendlich dazu, daß Squid sich beendete...
Und dabei ist *massig* Platz auf der Squid-Cache-Partition!
Das ist kein Kernel-Bug, sondern die Inode-Dichte Deiner Cache-Partition reicht nicht aus. Die Partition enthaelt anzahlmaessig viele kleine Files. Abhilfe: eine groessere Inode-Dichte waehlen. Regards Gerhard
Hi!
On Fri, 25 Jan 2002, Martin Köhling wrote:
Jan 23 11:15:17 xxxx squid[733]: diskHandleWrite: FD 16: disk write error: (28) No space left on device Das Problem führte dann letztendlich dazu, daß Squid sich beendete...
Und dabei ist *massig* Platz auf der Squid-Cache-Partition!
Das ist kein Kernel-Bug, sondern die Inode-Dichte Deiner Cache-Partition reicht nicht aus. Die Partition enthaelt anzahlmaessig viele kleine Files. Abhilfe: eine groessere Inode-Dichte waehlen.
Ups - an die Möglichkeit hab' ich ja garnicht gedacht! Thanx!! Das Problem hatte ich allerdings bisher (bei Default-Partitionierung mit Yast) noch nie - aber vielleicht ist beim Partionieren diesmal was schiefgegangen... Werd' ich gleich mal checken... [Später] xxxx:~ # df -i /var/. Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda6 640640 22674 617966 4% /var Das war's dann wohl doch nicht; ABER: xxxx:~ # df -h /var/. Filesystem Size Used Avail Use% Mounted on /dev/sda6 2.4G 2.2G 122M 95% /var Wie es sich herausstellt, erzeugt der Samba-Server in kürzester Zeit ein monströs langes Logfile in /var/log: xxxx:~ # find /var -size +100000000c -ls 576865 1954068 -rw-r--r-- 1 root root 1999004324 Jan 25 12:32 /var/log/samba.log.old Dieses File wird anscheinend regelmäßig umbenannt (samba.log -> samba.log.old), und die alte Version dabei überschrieben - dadurch ist die Partition abwechselnd fast voll, dann wieder lerr, usw. *Warum* macht der smbd das? Ich hatte vor einiger Zeit testweise den Debug-Level auf 9 gesetzt, diese Zeile aber nachher wieder auskommentiert - hätte ich explizit "debug level = 0" schreiben müssen, damit die Änderung übernommen wird? Werd' ich jetzt mal probieren... Aber trotzdem danke für den Tip mit den Inodes - darüber bin ich früher tatsächlich schon einmal gestolpert! (Zu dumm, daß "Platte voll" und "keine freien Inodes mehr" offenbar denselben Fehlercode erzeugen... :-() Martin
Am Fre, 2002-01-25 um 13.27 schrieb Martin Köhling:
Hi!
On Fri, 25 Jan 2002, Martin Köhling wrote:
Jan 23 11:15:17 xxxx squid[733]: diskHandleWrite: FD 16: disk write error: (28) No space left on device Das Problem führte dann letztendlich dazu, daß Squid sich beendete...
Und dabei ist *massig* Platz auf der Squid-Cache-Partition!
Das ist kein Kernel-Bug, sondern die Inode-Dichte Deiner Cache-Partition reicht nicht aus. Die Partition enthaelt anzahlmaessig viele kleine Files. Abhilfe: eine groessere Inode-Dichte waehlen.
Ups - an die Möglichkeit hab' ich ja garnicht gedacht!
Thanx!!
Das Problem hatte ich allerdings bisher (bei Default-Partitionierung mit Yast) noch nie - aber vielleicht ist beim Partionieren diesmal was schiefgegangen...
Du könntest bei sowas auch noch über eien andere Lösung nachdenken, nämlich den Einsatz von reiserfs. Ich sage das, obwohl ich kein Freund von reiserfs bin, aber wenn m,an es nicht zusammen mit nfs benutzen muß hat es an manchen Stellen auch Vorteile. Wir hatte hier das Systemverzeichnis von der Backupsoftware ARKEIA auf einer ext2-Partition liegen. Arkeia legt als Datenbank eine Art leere Kopie der Kompletten Dateibäume an, die es sichert. Wir kommen da leicht auf 2mio. Dateien und Unterverzeichnisse mit minimalem Inhalt. Irgend wann wurde die Sicherung immer langsamer und braucte Irgend wann gut 30 Stunden, viel zu lange. Irgendwann habe ich dann die Datenbank von einer ext2 auf eine andere ext2 kopiert, nix wars. Dann habe ich die alte neu mit reiserfs eingerichtet, die Daten wieder zurückkopiert und siehe da, 15 Stunden läuft sie nur noch. reiserfs kommt mit vielen kleinen datein super zurecht, weil da teilweise geringe Datenmengen in den Verwaltungsstrukturen mit abgelegt wird. Das geht natürlich fix. Ansonsten setze ich es nicht ein, schon garnicht mit nfs. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
participants (3)
-
Gerhard Schwan
-
Martin Köhling
-
Peter Kuechler