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