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 redhat.com
[mailto:rhelv5-list-bouncesredhat.com] On Behalf Of
John Summerfield
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 [summernumbat ~]$ 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, 5.1e-05 seconds, 0.0 kB/s
16:29 [summernumbat ~]$ time mke2fs -F -q big.img
real 1m16.787s
user 0m0.076s
sys 0m9.353s
16:31 [summernumbat ~]$ ls -Shls big.img 1.6G
-rw-rw-r-- 1 summer 100G
Apr 8 16:31 big.img
16:32 [summernumbat ~]$
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-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list
|
It shouldn't be slow; has anyone tried it with kvm?
--
Cheers
John
-- spambait
1aaaaaaa