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!