PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : virtuelle Festplatte bzw. Images kopieren



caspartroy
08.05.09, 12:41
Hallo zusammen,

virtuelle Festplatten kann man bekanntlich so anlegen, dass sie nur den Platz belegen, den Sie tatsächlich brauchen (z.B. qemu-img create test.img 4G). Das so erzeugte Image verbraucht nach dem Erzeugen (auf einem Dateisystem, das holes unterstützt) gar keinen Platz, nach dem kopieren (scp) aber die vollen 4G. Wie kopiere ich diese Images so, dass sie denselben Platz wie die ursprüngliche Datei brauchen?

stefan.becker
08.05.09, 18:14
Was machst du denn wie wo wann mit welchem Dateisystem auf was für einem OS?

caspartroy
08.05.09, 19:59
OS: überall Debian Lenny, fs ist überall ext3
Ich mache (z.B. heute ;-) ) sowas wie:



ssh xy
qemu-img create test.img 50M
du -sm test.img
# 0 test.img
tar cjf test.img.tar.bz2 test.img
exit
scp xy:test.img .
du -sm test.img
# 51 test.img
scp xy:test.img.tar.bz2 .
tar xf test.img.tar.bz2
du -sm test.img
# 51 test.img
qemu-img create test.img 50M
du -sm test.img
# 0 test.img

stefan.becker
08.05.09, 20:06
Äh, schon mal was von qcow gehört?

caspartroy
08.05.09, 20:25
Äh, schon mal was von qcow gehört?
ja, die Frage war aber nicht, ob es ein Image-Format gibt, das diese Aufgabe erleichtert, sondern ob man solche Dateien über Rechnergrenzen hinweg bei gleichbleibender Größe kopieren kann. Meinetwegen kann das auch eine Datei sein, die so erstellt wurde:



dd if=/dev/zero of=test.img bs=1 seek=8192 count=0

stefan.becker
08.05.09, 20:27
qcow heißt: zunächst klein, dann wachsend.

Alles andere ist raw: Direkt Endgröße.

Bei VMWARE ist das halt "growable.

caspartroy
08.05.09, 21:47
Alles andere ist raw: Direkt Endgröße.

Nene, ist es nicht. Wie gesagt, auch ein raw-Image belegt, ebenso wie die mit dd angelegte Datei, nur soviel Speicher, wie Bits mit Informationen belegt sind, d.h. am Anfang gar keine. Man kann sozusagen eine reguläre Datei der Größe 50 MB anlegen (ls -lh test.img zeigt 50 MB), die aber keinen Platz verbraucht (du -sm test.img zeigt 0 MB).

Leider überlebt diese Eigenschaft (bisher) nicht den Transport über das Netzwerk. Ich probier's mal mit nfs.

caspartroy
08.05.09, 23:00
Mit nfs geht's!

Falls jemand eine etwas praktischere Lösung kennt, z.B. irgendeinen Packer, der das beim auspacken richtig macht, würde mich das sehr interessieren.

caspartroy
13.05.09, 14:22
Habe die Lösung gefunden: GNU-tar kennt die Option -S bzw. --sparse, die dafür sorgt, dass diese sogenannten Sparse-Dateien beim auspacken so klein bleiben. BSD-tar kann das anscheinend auch.