Re: Problem mit den INodes auf /var

Hi Achim,

zähl doch mal selbst, wie die jetzige Situation aussieht: Belegt sind: 824016 KB
und 131616 Inodess. Das macht ein Verhältnis von

$echo $[824016*1024/131616]
6411

Inodes/Byte. Das nächstniedrigere Vielfache von 1024 wäre also 6144 (6) was Du
als Maximum nehmen solltest, um nicht nochmal den gleichen Fehler zu machen.
Eher würde ich da noch weniger nehmen (5) um noch sicherer zu sein.

Bei den Angewohnheiten von Squid und Leafnode ist es selbstverständlich auch
empfehlenswert, kleinere Blöcke zu wählen. Das wäre ein Fall für's Experiment.
Dieses würde ich von einer Knoppix aus durchführen, weil das sonst unbequem
wird, /var zu unmounten. (nicht unmöglich, aber es ist weniger Aufwand, schnell
ein CD-ROM anzuschließen zum Booten) Den Inhalt von /var kopiert man solange mit
"cp -a" oder bei Platzmangel mit "tar cvjf" irgendwo hin, wo Platz ist. und wo
anständige Dateiattribute unterstützt werden. "cp -a" erhält Dateiattribute,
soweit es kann. Ist der einzige Verfügbare Platz auf bspw. einer
FAT32-Partition, mußt Du selbstverst. mit "tar" arbeiten, weil FAT die
interessanten Attribute nicht hat. Für mehr Tempo kann man auch das "j" zu "z"
machen oder gar weglassen. (Kompression)

Das ReiserFS käme hier fast wie gerufen, bei seiner Effizienz mit kleinen
Dateien, zumal es IIRC sogar mehrere Dateien in einen Block bekommen kann.
Andererseits machte ich kürzlich schon wieder schlechte Erfahrung mit ReiserFS
auf aktuellem Kernel (hat ein hartes Ausschalten ohne Runterfahren nicht
überlebt) und damit halte ich es für noch nicht ausgereift genug. Ext3 hat mich
hingegen noch nie im Stich gelassen. Den offiziellen Entwicklungsstatus von
ReiserFS kenne ich nicht.

Vielleicht lesen wir weitere Meinungen zu dieser Frage.

Aber vor der ganzen Aktion: Daten der gesamten Platte sichern. Zu leicht
vertippt man sich beim mkfs. Und beim Durchführen lieber dreimal denken vor dem
Abschicken der Befehle. Ich bin nicht schuld, wenn die falsche Partition dran
glaubt.

HTH, vG
   Kevin

> PS: man geht (natürlich) auch nicht mehr:
> man: Kann /var/cache/man/catn/3976 nicht erzeugen: Auf dem Gerät ist kein
> Speicherplatz mehr verfügbar

P.S.: Gut, daß die Logdateien bereits existieren, sonst wäre es unbequem
geworden! Vielleicht willst Du für Funktionalität auf die Schnelle den Inhalt
von Squid und Leafnode löschen. Das würde auch Backup/Restore beschleunigen. Bei
ersterem kannst Du locker (bei nicht laufendem Proxy!!) den ganzen Inhalt von
/var/spool/squid löschen und später die Struktur mit einem einfachen Befehl
wiederherstellen (ohne Inhalte versteht sich) andererseits würde eine solche
Aktion die Möglichkeit des Experiments (Blockgrößen tunen) nehmen.

-- 
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=214656
http://wwwkeys.pgp.net:11371/pks/lookup?op=vindex&search=0x7A56501D
ICQ # 75570407