I think you'll get the same sort of thing if you gzip the file. I've
gzip'd some 20G xen images down to around 2G.
Daniel P. Berrange wrote:
On Sat, Dec 01, 2007 at 12:42:40PM -0500, Aaron Metzger wrote:
Sadique Puthen wrote:
Basically it if you don't pre-allocate the entire image, virt-manager
creates a sparse file to store the guest data which only occupies disk
blocks while you write contents to that sparse file . When checking the
size of the pre-allocated and sparse images, you should use "du", not
"ls -lh".
Thank you for your insight. You are correct.
I have a guest image stored in a file called "subversion".
"du" shows the actual size being used is smaller than what "ls" thinks.
du -a subversion
2158768 subversion
ls -ld subversion
-rwxr-xr-x 1 root root 64424509441 2007-11-27 18:16 subversion
You don't need to use 'du' - just use the '-s' flag to ls
$ ls -lsh dan1.img
16K -rwxr-xr-x 1 root root 2.1G 2007-11-29 17:51 dan1.img
Shows its physical size is 16k, while its logical size is 2.1 GB.
I have a follow up question though. How do you cleanly backup and
restore these files using the smaller amount of space? Any simplistic
program that I try (e.g. "tar") also thinks my file is 60 Gig not 2 Gig
and creates a real file that uses 60 Gig of actual disk space.
Use the --sparse option with tar.
-S, --sparse
handle sparse files efficiently
Can anyone share the simple steps with "dd" or other programs that let
you cleanly store a backup of the guest image which uses the smaller
amount of space and also correctly restores from that backup in a way
that preserves the orginal idea of a 60 Gig max guest disk size?
'cp' will also try to detect sparse files & handle them properly, but
if it gets it wrong you can also use '--sparse=always'
Dan
--
Fedora-xen mailing list
Fedora-xen@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-xen
