Mein Toshi, das Subnotebook hat nur eine kleine 1.8 Zoll Platte mit 20 GB. Da heisst es haushalten. Auf meiner root Partition war mir der freie Platz etwas knapp.
Ausgangssituation:
toshi:~# df -h
Dateisystem Größe Benut Verf Ben% Eingehängt auf
/dev/mapper/toshi-root
4,9G 4,5G 235M 96% /
tmpfs 245M 0 245M 0% /lib/init/rw
udev 10M 60K 10M 1% /dev
tmpfs 245M 0 245M 0% /dev/shm
/dev/hda1 236M 40M 184M 18% /boot
/dev/mapper/toshi-home
13G 1,9G 11G 16% /home
lvscan liefert:
toshi:~# lvscan
ACTIVE '/dev/toshi/root' [4,96 GB] inherit
ACTIVE '/dev/toshi/swap_1' [616,00 MB] inherit
ACTIVE '/dev/toshi/home' [12,82 GB] inherit
lvs liefert
toshi:~# lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
home toshi -wi-ao 12,82G
root toshi -wi-ao 4,96G
swap_1 toshi -wi-ao 616,00M
Ich habe frohen Mutes dann einfach die home Volumegroup um 2 Gig verkleinert. Ein Fehler, wie sich wenig später herausstellte.
toshi:~# lvresize /dev/toshi/home --size -2G
WARNING: Reducing active and open logical volume to 10,82 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce home? [y/n]: y
Reducing logical volume home to 10,82 GB
Logical volume home successfully resized
Die root Volumegroup habe ich um 2 Gig vergrößert
toshi:~# lvresize /dev/toshi/root --size +2G
Extending logical volume root to 6,96 GB
Logical volume root successfully resized
toshi:~# lvscan
ACTIVE '/dev/toshi/root' [6,96 GB] inherit
ACTIVE '/dev/toshi/swap_1' [616,00 MB] inherit
ACTIVE '/dev/toshi/home' [10,82 GB] inherit
Für den Volume Manager ist alles ok
toshi:~# df -h
Dateisystem Größe Benut Verf Ben% Eingehängt auf
/dev/mapper/toshi-root
4,9G 4,5G 235M 96% /
tmpfs 245M 0 245M 0% /lib/init/rw
udev 10M 60K 10M 1% /dev
tmpfs 245M 0 245M 0% /dev/shm
/dev/hda1 236M 40M 184M 18% /boot
Hier oben sieht man, das sich an den Filesystemen noch nichts geändert hat. Physikalisch habe ich zwar den Platz verändert, nur die Filesysteme (ext3) haben davon noch nichts mitbekommen. Ich habe dann mit
apt-get install ext2resize
den ext2 filesystem resizer installiert.
Mit ext2online -v /dev/toshi/root konnte ich das gemountete root Filesystem im Multiusermodus vergrössern. Prima.
[update 18.07.2009]: Das Paket heißt in Lenny nun e2fsprogs und das Kommando resize2fs und nicht ext2online.
Ich habe dann im singleusermodus mit resize2fs versucht home um 2 Gig zu verkleinern. Man wird aufgefordert, zuerst einen Filesystemcheck zu machen. Ok, also e2fsck -f /dev/toshi/home
. Es gab viele, im nachhinein nachvollziehbare Fehlermeldungen, schliesslich habe ich dem Filesystem einiges am oberen Ende geklaut. Nach dem erfolgreichen beenden ließ sich resize2fs nun starten, monierte aber resize2fs: Can't read an block bitmap beim Versuch, die Größe von home zu ändern
Ich habe mich dann so aus der Affäre gezogen, das ich vom /home ein Backup gemacht habe, das Filesystem neu angelegt habe und das Backup zurückgespielt.
Merksatz für später: Beim verkleinern einer Partition/Volumegroup zuerst das Filesystem verkleinern, dann die Partition / Volume group
Vergrößern ist genau umgekehrt, leuchtet ja auch ein. Erst die Partition/Volumegroup vergrößern, danach ist online die Vergrößerung des Filesystems möglich.
Um diese Geschichte nachvollziehbar zu machen, kann man Versuche mit Filesystemen in Dateien machen, das tut niemanden weh und erleichtert einem das Verständnis. Weil ich im Singleuser Modus mir die Fehlermeldung nicht aufgehoben hatte, war das eine Möglichkeit den Fehler noch einmal zu simulieren, ohne gleich wieder alles platt machen zu müssen.
dd if=/dev/zero of=/root/versuch count=400000
400000+0 Datensätze ein
400000+0 Datensätze aus
204800000 Bytes (205 MB) kopiert, 10,5104 Sekunden, 19,5 MB/s
Filesystem anlegen:
mkfs.ext3 -j versuch
mke2fs 1.40-WIP (14-Nov-2006)
versuch ist kein spezielles Block-Gerät.
Trotzdem fortsetzen? (y,n) y
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=1024 (log=0)
Fragmentgröße=1024 (log=0)
50000 Inodes, 200000 Blöcke
10000 Blöcke (5.00%) reserviert für den Superuser
erster Datenblock=1
Maximum filesystem blocks=67371008
25 Blockgruppen
8192 Blöcke pro Gruppe, 8192 Fragmente pro Gruppe
2000 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729
Schreibe Inode-Tabellen: erledigt
Erstelle Journal (4096 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt
Das Dateisystem wird automatisch alle 27 Mounts bzw. alle 180 Tage überprüft,
je nachdem, was zuerst eintritt. Veränderbar mit tune2fs -c oder -t .
Nun irgendetwas auf das gemountete versuch kopieren:
mount -o loop versuch /mnt
cp irgendwas /mnt
umount /mnt
dd if=/root/versuch of=/root/versuch-shrinked count=300000
300000+0 Datensätze ein
300000+0 Datensätze aus
153600000 Bytes (154 MB) kopiert, 9,80157 Sekunden, 15,7 MB/s
Ich habe also das 190MB grosse Filesystem absichtlich mit unzureichender count Angabe kopiert. Das Resultat ist ein Filesystem von den man lt. df -h annimmt, das es noch 190 MB groß ist,
df -h /mnt/
Dateisystem Größe Benut Verf Ben% Eingehängt auf
/root/versuch-shrinked
190M 5,6M 174M 4% /mnt
man aber physikalisch gar nicht mehr den Platz hat (ll)
ll versuch*
-rw-r--r-- 1 root root 204800000 2007-04-21 16:01 versuch
-rw-r--r-- 1 root root 153600000 2007-04-21 16:04 versuch-shrinked
Interessant ist in dem Zusammenhang, das ohne Filesystemcheck dem System es ebenfalls nicht klar ist, es glaubt immer noch an ein 190 MG großes Filesystem, das kann fatal werden 
Bevor ich aber resize2fs loslossen kann, muss ich ein korrigiertes Filesystem haben. Das erledigt fsck
fsck.ext3 -f versuch-shrinked
e2fsck 1.40-WIP (14-Nov-2006)
Die Dateisystem Größe ( laut SuperBlock) ist 200000 Blocks
Die physikalische Größe von Gerät ist 150000 Blocks
Entweder der SuperBlock oder die Partionstabelle ist beschädigt!
Abbrechen?
Die Angabe des Schalters -y ist nicht möglich, weil die erste Frage verneint werden muß (gibt es da einen Trick?)
Natürlich bekommt man haufenweise Fehler:
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Lesefehler - Block 155651 (Attempt to read block from filesystem resulted in short read) während Inode-Scan Ignoriere Fehler? ja
Rückschreiben erzwingen? ja
Ich behelfe mir mit einer mechanischen Konstruktion, die mir die RETURN Taste andauernd drückt...Wozu so ein Taschenmesser doch alles gut ist ...Ps: Das Bild ist nicht ganz scharf, weil ich der Warnanzewige der Canon nicht traute und ich mal sehen wollte wie schlimm des verwackeln ist.
Lesefehler - Block 196860 (Attempt to read block from filesystem resulted in short read) während Inode-Scan Ignoriere Fehler? ja
Rückschreiben erzwingen? ja
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Äberprüfe die Referenzzähler
Durchgang 5: Äberprüfe Gruppe Zusammenfassung
Block Bitmap differieren: +(155649--155900) +(163841--164092) +(172033--172284) +(180225--180476) +(188417--188668) +(196609--196860)
Repariere? ja
versuch-shrinked: ***** DATEISYSTEM WURDE VERÄNDERT *****
versuch-shrinked: 12/50000 files (8.3% non-contiguous), 12028/200000 blocks
Bei dieser Konstellation gab es übrigens keinen Fehler:
resize2fs -f versuch-shrinked
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on versuch-shrinked to 196860 (1k) blocks.
The filesystem on versuch-shrinked is now 196609 blocks long.
Bei einem früheren Versuch mit größeren Dateien bekam ich allerdings genau denselben Fehler wie mit der Volumegroup
resize2fs -f versuch-shrinked
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on versuch-shrinked to 246105 (4k) blocks.
resize2fs: Can't read an block bitmap beim Versuch, die Größe von versuch-shrinked zu ändern
toshi:~#
Fazit: Erst nachdenken, dann schrinken
Gott sei Dank ist dieses Abenteuer noch einmal gut gegangen. Wird mir eine Lehre sein.
Und wer kein Taschenmesser hat steckt ein Stück Werbeprospekt unter die Taastatur
100mal lv verkleinert aber trotzdem vergessen vorher das fs zu verkleinern, man man..
Yig