Imagefile von vServer vergrößern

[blueroot]

Hallo,
ich würde gerne wissen ob es eine Möglichkeit gibt ein Image zu vergrößeren.
Ich habe aktuell ein ext3 Debian Image erstellt.
Es läuft auch soweit alles, aber ich würde gerne nach und nach Speicher hinzufügen [ dd if=/dev/zero of=blubb.img bs=1k seek=6048k count=1 ].
Lässt sich dies möglichst einfach durchsetzen oder muss ich ein neues Image machen und alles rüberkopieren (Würde ich mehr als ungern machen)?

Besten Dank :)

[Roger Wilco]

Lässt sich dies möglichst einfach durchsetzen oder muss ich ein neues Image machen und alles rüberkopieren (Würde ich mehr als ungern machen)?

Geht recht einfach. Du mußt danach nur das Dateisystem mit ext2resize an die neue Größe des Containers anpassen.

[blueroot]

Nach dem erstellen eines neuen Containers?
Ich möchte dies nicht wirklich machen, da ich dann kurze Zeit zuviel Speicher benötige. So müsste ich dann immer die halbe Platte leer lassen...
Ich könnte auch LVM benutzen, welches mir aber nicht zusagt.
cfdisk/resize2fs/ext2resize scheinen nicht wirklich zu gehen oder ich verstehe etwas nicht.
Ich bekomme das File nicht vergrößert. Was genau meinst du mit dem "danach"?

[Roger Wilco]

Nach dem erstellen eines neuen Containers?

Nach Vergrößern des ursprünglichen Containers...

Ich bekomme das File nicht vergrößert. Was genau meinst du mit dem "danach"?

Wieso nicht? Dein Ansatz mit dd sah doch recht gut aus. Und resize2fs kann definitiv auch eine Datei, die kein Blockdevice ist, vergrößern.

[blueroot]

Ich habe es nun hinbekommen das Image zu vergrößeren. Also von 1GB auf 2GB. Das Dateisystem scheint aber noch nicht zu passen. Es wird noch 1GB im vServer angezeigt. Mit ext2resize bekomme ich es irgendwie nicht hin. Wahrscheinlich irgendein Bedienfehler von mir. Muss ich ext2resize "im" vServer ausführen oder geht es auch von "außen"?
Hast du vielleicht noch einen Tipp für mich?
Ich habe es auch schon mit der "force" Option probiert, leider ohne Erfolg.
Kann ich den Container eigendlich auch ohne Datenverluste verkleinern?
Es wird auch überall gesagt das die Methode über das LoopDevice eine sehr schlechte I/O Performance hat. Ich habe aber schon 2-3 Benchmarks gesehen, wo dies nicht der Fall war. Mir gefällt es mit den Containern
auch besser als mit LVM.
Ich habe aktuell ein Software Raid1 und darauf ein Minimal Debian mit xen. Läuft soweit stabil. Wenn ich aber nun noch ein LVM als Hauptpartition dazwischenstecke... Ich weiß ja nicht... Es ist ja eigendlich nicht notwenig. Mit insgesammt 2-5% Overheat kann ich leben. Mehr ist es mir aber nicht wert.
Vielleicht werde ich mir auch mal einen Hardwarecontroller reinhauen und dann mal LVM testen.
Mir gefällt es aber aktuell auch besser, da ich auf Dom0 95% der Festplattenkapazität habe. So kann ich immer schön von einem auf den anderen Server kopieren und mir Backups ziehen.
Mit LVM müsste ich die Platte ja nochmal teilen (DomUXX).
So hätte ich dann noch mehr unnötigen Speicherplatz verloren :)

[Roger Wilco]

Muss ich ext2resize "im" vServer ausführen oder geht es auch von "außen"?

Ich meine vom Hostsystem aus.

Hast du vielleicht noch einen Tipp für mich?

Spielen wir das mal mit einem kleinen Loopfile durch:

Code: Select all

$ dd if=/dev/zero of=/tmp/loopfile bs=1M count=16
16+0 records in
16+0 records out
16777216 bytes (17 MB) copied, 0.022168 seconds, 757 MB/s
$ mkfs.ext2 loopfile
mke2fs 1.38 (30-Jun-2005)
loopfile is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
4096 inodes, 16384 blocks
819 blocks (5.00%) reserved for the super user
First data block=1
2 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
$ mount -o loop /tmp/loopfile /tmp/mountpoint/
$ df -h /tmp/mountpoint/
Filesystem            Size  Used Avail Use% Mounted on
/tmp/loopfile          16M   13K   15M   1% /tmp/mountpoint
$ umount /tmp/mountpoint/
$ dd if=/dev/zero of=/tmp/loopfile bs=1M seek=16 count=16
16+0 records in
16+0 records out
16777216 bytes (17 MB) copied, 0.023439 seconds, 716 MB/s
$ ls -sh /tmp/loopfile
33M /tmp/loopfile
$ e2fsck -f /tmp/loopfile
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/tmp/loopfile: 11/4096 files (0.0% non-contiguous), 534/16384 blocks
$ resize2fs /tmp/loopfile
resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /tmp/loopfile to 32768 (1k) blocks.
The filesystem on /tmp/loopfile is now 32768 blocks long.

$ mount -o loop /tmp/loopfile /tmp/mountpoint/
$ df -h /tmp/mountpoint/
Filesystem            Size  Used Avail Use% Mounted on
/tmp/loopfile          31M   13K   30M   1% /tmp/mountpoint

Ich hoffe du verstehst, was ich da getrieben habe. Alles mit '$' am Zeilenanfang sind Eingaben.

[blueroot]

Besten Dank für das kleine Howto :)
Ich habe aber leider noch ein paar Probleme ->

Code: Select all

serv:/vserver/images/default# dd if=/dev/zero of=vm_debian-3.1-root.old.omg bs=1M seek=500 count=500
500+0 Datensätze ein
500+0 Datensätze aus
524288000 bytes transferred in 13,363390 seconds (39233159 bytes/sec)
serv:/vserver/images/default# ls -sh vm_debian-3.1-root.old.omg
1001M vm_debian-3.1-root.old.omg
serv:/vserver/images/default# dd if=/dev/zero of=vm_debian-3.1-root.old.omg bs=1M seek=500 count=500
500+0 Datensätze ein
500+0 Datensätze aus
524288000 bytes transferred in 12,513247 seconds (41898638 bytes/sec)
serv:/vserver/images/default# ls -sh vm_debian-3.1-root.old.omg
1001M vm_debian-3.1-root.old.omg
serv:/vserver/images/default# e2fsck -f vm_debian-3.1-root.old.omg
e2fsck 1.37 (21-Mar-2005)
Die Dateisystem Größe ( laut SuperBlock) ist 1280000 Blocks
Die physikalische Größe von Gerät ist 256000 Blocks
Entweder der SuperBlock oder die Partionstabelle ist beschädigt!
Abbrechen<j>? nein

Durchgang 1: Prüfe Inodes, Blocks, und Größen

Lesefehler - Block 262146 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? ja

Rückschreiben erzwingen<j>? ja

Lesefehler - Block 262147 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? nein

Fehler während der Suche Inodes (128000): Can't read next inode
e2fsck: abgebrochen
serv:/vserver/images/default#
serv:/vserver/images/default# e2fsck -f vm_debian-3.1-root.old.omg
e2fsck 1.37 (21-Mar-2005)
Die Dateisystem Größe ( laut SuperBlock) ist 1280000 Blocks
Die physikalische Größe von Gerät ist 262147 Blocks
Entweder der SuperBlock oder die Partionstabelle ist beschädigt!
Abbrechen<j>? nein

Durchgang 1: Prüfe Inodes, Blocks, und Größen
Lesefehler - Block 262147 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? ja

Rückschreiben erzwingen<j>? ja

Lesefehler - Block 262148 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? ja

Rückschreiben erzwingen<j>? ja

Lesefehler - Block 262149 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? ja

Rückschreiben erzwingen<j>? ja

Lesefehler - Block 262150 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? ja

Rückschreiben erzwingen<j>? ja

Lesefehler - Block 262151 (Attempt to read block from filesystem resulted in short read) während Inode-Scan  Ignoriere Fehler<j>? nein

Fehler während der Suche Inodes (128000): Can't read next inode
e2fsck: abgebrochen

Irgendwie will das nicht so recht :-D
Ab dem "dd if=/dev/zero of=/tmp/loopfile bs=1M seek=16 count=16" bekomme ich Probleme.
Das Image ist ein bestehendes altes Image mit Debian Image, bzw. war wohl eher :P
Vielleicht liegt es daran, dass es ein ext3 Filesystem war?
Er hat mir auf jedenfall das Image nicht vergrößert.

[Roger Wilco]

Bist du sicher, dass dein Loopfile ursprünglich genau 500 MB groß ist? Die Meldung "Die Dateisystem Größe ( laut SuperBlock) ist 1280000 Blocks
Die physikalische Größe von Gerät ist 256000 Blocks" sagt nämlich, dass plötzlich nur noch 1/5 der Blöcke da ist...

[blueroot]

Aha, nun habe ich meinen Fehler gefunden.
Vielen Dank :-D

PS: Ist es eigendlich auch möglich das Image zu verkleinern, ohne Verlust von den alten Daten?

[Roger Wilco]

PS: Ist es eigendlich auch möglich das Image zu verkleinern, ohne Verlust von den alten Daten?

ext2 Dateisysteme können auch verkleinert werden, siehe resize2fs(8) oder ext2resize(8). Du solltest aber trotzdem schonmal ein Backup anfertigen. ;)

[blueroot]

OK.

Nun habe ich nun ein größeres Problem.
Ich habe mir ca. 60GB große Images erstellt.
Lösche ich diese mit "rm "image"", sind diese nicht mehr einsehbar.
Leider wird der Speicherplatz noch verwendet (df -h behauptet dies).
Hier hilft dann nur ein Reboot. Der Server macht mir dann ein Filesystemcheck und es scheint soweit alles in Ordnung zu sein.
Dies ist aber nicht die optimale Lösung.
Ist dies ein Bug/Funktion von ext3? Wie kann ich das Problem umgehen?
Zusätzlich steht der Server nun in einem Rechenzentrum.

[captaincrunch]

Leider wird der Speicherplatz noch verwendet (df -h behauptet dies).

...sehr wahrscheinlich, weil noch ein Prozess auf diese Daten zugreift.

Ist dies ein Bug/Funktion von ext3? Wie kann ich das Problem umgehen?

Nein (s.o.). Finde raus, welcher Prozess die Daten im Zugrif hat und beende ihn.

[blueroot]

Danke für deinen heißen Tipp :)
Ich habe den Rechner gestern mal rebootet und mir ein neues Image erstellt.
Nun möchte ich dieses wieder löschen:

Warscheinlich greift "loop1" noch auf das File zu. Leider bekomme ich den Prozess nicht beendet. Er scheint auch nicht wieder gestartet zu werden. Er lässt sich also einfach nicht killen.

Code: Select all

init─┬─cron
     ├─events/0
     ├─events/1
     ├─6*[getty]
     ├─inetd
     ├─khelper
     ├─2*[kjournald]
     ├─klogd
     ├─kseriod
     ├─ksoftirqd/0
     ├─ksoftirqd/1
     ├─kswapd0
     ├─kthread─┬─aio/0
     │         ├─aio/1
     │         ├─ata/0
     │         ├─ata/1
     │         ├─kacpid
     │         ├─kblockd/0
     │         ├─kblockd/1
     │         ├─kmirrord/0
     │         ├─kmirrord/1
     │         ├─2*[pdflush]
     │         ├─xenbus
     │         └─xenwatch
     ├─loop1
     ├─md0_raid1
     ├─md1_raid1
     ├─md2_raid1
     ├─mdadm
     ├─migration/0
     ├─migration/1
     ├─scsi_eh_0
     ├─scsi_eh_1
     ├─sshd───sshd─┬─bash───pstree
     │             └─sshd
     ├─syslogd
     ├─xenblkd
     ├─xenconsoled───xenconsoled───xenconsoled
     └─xenstored

Die vm01.img möchte ich löschen:

Code: Select all

-rw-r--r--  1 root root 84934656000 2006-01-24 23:17 vm01.img
-rw-r--r--  1 root root  1048576000 2006-01-24 22:38 vm01-root.img
-rw-r--r--  1 root root  1048576000 2006-01-09 21:12 vm01-swap.img

Folgende Domains laufen (xen):

Code: Select all

Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      126     2 r-----    41.2

[captaincrunch]

Hast du das Loopdevice denn vor dem löschen unmounted?

[blueroot]

Ich wüsste nicht, wo das loopdevice herkommt.
Ich schätze von xen, dass die Domain noch hängt.
Ansonsten habe ich nichts mit mount -o loop gemountet.

Code: Select all

Dateisystem          1K-Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/md1             238433528  89067984 137253744  40% /
tmpfs                    64168         0     64168   0% /dev/shm
/dev/md2                964408     37040    878376   5% /boot

Ich kann aber leider keine Console oder sonstiges mit xen schließen.
Ich hatte den vServer mal kurz gestartet, er ist aber nicht durchgebootet und dann hat er automatisch die Console geschlossen.
"Normal" sollte auch kein loop mehr offen sein und Domain0 verwendet ansonsten ja keine loopdevices.
Hast du vielleicht eine Idee, wie ich überprüfen kann, wo das loopdevice genutzt wird und wie ich es beenden kann?

[captaincrunch]

Ich hätt's jetzt mal lsof nachgeschaut. ;)

[blueroot]

Code: Select all

COMMAND  PID USER   FD      TYPE DEVICE SIZE NODE NAME
loop1   2531 root  cwd       DIR    9,1 4096    2 /
loop1   2531 root  rtd       DIR    9,1 4096    2 /
loop1   2531 root  txt   unknown                  /proc/2531/exe

Leider bringt mich das irgendwie auch nicht weiter 8O

[captaincrunch]

Doch, spätestens da die Zahl hinter /proc die PID angibt. ;)

[blueroot]

Könntest du dich vielleicht etwas genauer ausdrücken?
Ich habe schon versucht den Prozess zu killen.
Die proc Informationen helfen mir auch nicht weiter, da hatte ich schon vorher geschaut.
Warscheinlich habe ich auch nur etwas übersehen.

[captaincrunch]

Ich habe schon versucht den Prozess zu killen.

Welcher Prozess hat denn die PID 2531? Welches Signal hast du ihm denn mit auf den Weg gegeben? "Nur" kill?

[blueroot]

PID "2531" ist der "loop1" Prozess.
Der Prozess ist aktuell am ideln.
"kill -9" habe ich an den Prozess geschickt.
Genauso wie ein "killall -9 loop1", was aber auf das gleiche hinauslaufen sollte.

[captaincrunch]

Und was sagt ein cat /proc/2531/status

[blueroot]

Code: Select all

Name:   loop1
State:  S (sleeping)
SleepAVG:       0%
Tgid:   2531
Pid:    2531
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups:
Threads:        1
SigQ:   1/1064
SigPnd: 0000000000000000
ShdPnd: 0000000000000100
SigBlk: ffffffffffffffff
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 00000000ffffffff
CapEff: 00000000fffffeff

PS: Wenn der Threat länger wird, können wir ihn ja zusammenfassen ;-)

PPS: Ich bin 20min weg :)

[blueroot]

Für alle die ein änhliches Problem haben sollten:
Man kann mit "losetup -d /dev/loopX" das loopdevice hart entfernen.
Bis jetzt scheint es damit gelöst zu sein.
Ich schätze, dass xen 3.0.0 hier noch sehr bugy ist...

[captaincrunch]

Man kann mit "losetup -d /dev/loopX" das loopdevice hart entfernen.

Ã?hm...ich war davon ausgegangen, dass genau das schon längst passiert war?!? Aber umso besser, dass es jetzt gelöst ist.