Well you are not doing this in the guest but in Dom0... If you
create a sparse file, add it to a DomU as a virtual block device and
then try mkfs, it takes a really long time. tapdisk is having trouble
with sparse files, normally they are reasonably fast in Linux (the only
issue with them is possibly increased fragmentation).


# dd if=/dev/zero count=0 of=big.img seek=100G bs=1
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.3e-05 seconds, 0.0 kB/s


# time mke2fs -F -q big.img

real   0m8.153s
user   0m0.040s
sys   0m4.492s


# ls -Shls big.img
1.6G -rw-r----- 1 root root 100G Apr 8 11:30 big.img


# rm big.img
# dd if=/dev/zero count=0 of=big.img seek=100G bs=1

(now I added it to a DomU as /dev/xvdb and I am working in DomU)
# time mke2fs -q /dev/xvdb

real   2m4.595s
user   0m0.020s
sys   0m0.672s


 As you see, it takes about 15 times longer in a DomU...
 Moreover, the journal aborts and FS remounts have happened to
me, sparse files are not reliable! There is nothing wrong with using
normal file-backed virtual block devices, but if you use a sparse file
for that purpose, then you may run into problems.. The use of sparse
files for DomUs is discouraged even in the virt-manager installer.


Regards,
 Daniel


-----Original Message-----
From: rhelv5-list-bounces@(protected)
[mailto:rhelv5-list-bounces@(protected)
Sent: Tuesday, April 08, 2008 10:39 AM
To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list
Subject: Re: [rhelv5-list] Xen Guest Disk Formatting Unfeasibly Slow

Zavodsky, Daniel (GE Money) wrote:
>   Sparse files are really bad... not only it takes ages to mkfs on

??

16:29 [summer@(protected)
bs=1
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.1e-05 seconds, 0.0 kB/s
16:29 [summer@(protected)

real   1m16.787s
user   0m0.076s
sys   0m9.353s
16:31 [summer@(protected)
Apr 8 16:31 big.img
16:32 [summer@(protected) ~]$

ext3 happens about as quickly.

If you think that improbably fast, try on your own hardware.


> them but you can get journal aborts and remounting the FS read-only
> under heavier disk load in the guest! Use them only for testing
> purposes and/or when you are really low on space.

I don't see why a disk image should be any less reliable than any other
kind of file, catastrophic system failures (I'm thinking power and host
crashes) aside.

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list