Hatte ich schon erwähnt, dass ich im September umgezogen bin? Bin ich, nur in anderes Viertel, aber mit jemandem zusammen in eine neue WG, der wie ich ebenfalls einen kleinen Server zu Haus stehen hatte. Da die Hardware heutzutage leistungsfähig genug ist und Xen zuverlässig läuft, sind wir dabei Schritt für Schritt die Dienste von den beiden ehemaligen Servern auf eine Maschine mit ein paar virtuellen Xen-Hosts zu packen. Da ich ungern an Produktivsystemen neue Dinge ausprobiere, teste ich solche Sachen auf einem anderen Rechner. Gestern hatte ich dank dieser Anleitung auf besagtem Testrechner unter Debian Etch in kurzer Zeit einen laufenden Xen-Wirt eingerichtet. Die 40GB-Platte war dort ungefähr zu gleichen Teilen in /home und / geteilt – klassische Partitionen. Da ich Xen gern mit LVM testen wollte und die Partitionen kaum belegt waren, entschied ich mich für eine Neuaufteilung: 8 GB für das root-Filesystem und der Rest für LVM. Auf dem Testsystem sind außer Testinstallationen keine wichtigen Daten, also die erste Gelegenheit für mich, mal resize2fs auszuprobieren…

Beim Verkleinern einer Partition soll man erst mit resize2fs das Dateisystem (ich benutze eigentlich immer ext3) verkleinern und dann mit fdisk die Partition selbst noch verkleinern. Das Manual sagt, dass die Partition natürlich nicht kleiner gemacht werden soll als das Dateisystem – logisch. Zunächst jedoch will resize2fs nochmal e2fsck aufgerufen haben:

e2fsck -f /dev/hdb3
resize2fs -p /dev/hdb3 8G

Dann habe ich fdisk /dev/hdb aufgerufen, hdb3 gelöscht und neu angelegt. Der vorgeschlagene Beginn der Partition war der gleiche wie zuvor, habe ich extra kontrolliert und dann die Partition mit +8300M neu angelegt. Reboot und siehe da: reicht wohl nicht, es kommt die Beschwerde, dass das Dateisystem 2 097 152 Blöcke hat, die Partition aber nur 2 026 458. Also nochmal Knoppix booten und Partition neu anlegen. Interessant ist dann zunächst die Ausgabe von fdisk -l

Platte /dev/hdb: 40.0 GByte, 40020664320 Byte
16 Köpfe, 63 Sektoren/Spuren, 77545 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes

    Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/hdb1   *           1         203      102280+  83  Linux
/dev/hdb2             204        2284     1048824   82  Linux Swap / Solaris
/dev/hdb3            2285       18367     8105832   83  Linux
/dev/hdb4           43895       77545    16960104    5  Erweiterte
/dev/hdb5           43895       77545    16960072+  83  Linux

fdisk zeigt hier auch Blöcke an, aber die Anzahl ist verschieden zu der, die zuvor e2fsck beim Boot des Systems zeigte – genau genommen exakt viermal so groß. Aber irgendwie stimmt das auch ungefähr mit den 8300 Megabyte von vorhin überein, in Kilobyte versteht sich. Ich habe dann also diesmal beim Neuanlegen der Partition +8388608K angegeben, das vierfache von dem Wert, den das System vorher beim Booten für die Größe des Dateisystem genannt hatte. Der kam wie gesagt ursprünglich von den 8G beim resize2fs. fdisk machte dann ein paar Blöcke mehr draus, als ich Kilobyte eingegeben hatte, umso besser. Da der Kernel noch nichts von der Änderung der Partitionstabelle durch fdisk wusste, lohnte ein e2fsck unter Knoppix nicht und ich hab gleich neu gestartet.

Das Debian etch beschwerte sich dann nicht mehr über ein Filesystem, das größer war als die Partition, ließ aber dennoch einen Check drüber laufen. Der weitere Systemstart verlief problemlos. Das LVM richte ich dann später ein…

Interessant finde ich jedoch noch die Frage, was ich hätte eingeben müssen, um von vornherein die passenden Größen für resize2fs und fdisk parat zu haben, einfach auch 8G bei fdisk wäre nämlich deutlich zu wenig gewesen. Ziel: möglichst wenig Platz auf der Partition verschenken. Wer da Ideen hat, den bitte ich um Kommentare!