List Info

Thread: RE: Xen Guest Disk Formatting Unfeasibly Slow
RE: Xen Guest Disk Formatting Unfeasibly Slow
country flaguser name
United States		 2008-04-08 01:49:39 

  


  

        Sparse files are really bad... not only 
it takes ages to mkfs on 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.

 



Daniel



 






From: rhelv5-list-bouncesredhat.com 
[mailto:rhelv5-list-bouncesredhat.com] On Behalf Of Dave 
Costakos
Sent: Monday, April 07, 2008 5:38 PM
To: Red Hat 
Enterprise Linux 5 (Tikanga) discussion mailing-list
Subject: 
[rhelv5-list] Xen Guest Disk Formatting Unfeasibly Slow



I'm trying to troubleshoot a problem where mkfs commands take a 
really, really long time to complete in my Xen guests.   

I'm 
using sparse file-backed images created using the 'virt-install' command on RHEL 
5.1 x86_64.  I'm kickstarting paravirtualized RHEL 4.5 and 5.1 x86_64 
guests and they are going through a standard, unattended install with a common 
diskmap.  When they get to formatting the various local disks, all file 
system formats are taking unfeasibly long. ; A 20+ GB file system takes 
upwards of 20 minutes to run an mkfs on.  During the mkfs, the underlying 
filesystem on the DOM0 shows high utilization via iostat (upwards on 99% 
utilization), but still the mkfs is horribly, horribly slow. ; mkfs is 
horribly slow whether I use a GFS, ext3 or NFS underlying filesystem, so I don't 
think that is the issue here.

If I create a non-sparse disk image or a 
physical partition or logical volume, formatting times are drastically 
increased.  However, I'm trying to be judicious with overall storage 
utilization and flexibility, I would very much like to stick with sparse 
files.

Any advice on how I can troubleshoot this further or possibly find 
a solution?  Is there another local disk driver I can use besides "tap:aio" 
(like "file") during the install process?

Note:  My underlying 
storage devices are Fibre Channel Hitachi OPEN-V*3 disks if it helps at all.

-- 
Dave Costakos
mailto:gmail.com">david.costakosgmail.com 

  

  
  
   
     
    

  

    Re:  Xen Guest Disk Formatting
Unfeasibly Slow
  


  

     user name

     2008-04-08 03:38:47
  


  

    
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.



>  
> Daniel
>  
> 
> 
>   _____  
> 
> From: rhelv5-list-bouncesredhat.com
> [mailto:rhelv5-list-bouncesredhat.com] On Behalf Of
Dave Costakos
> Sent: Monday, April 07, 2008 5:38 PM
> To: Red Hat Enterprise Linux 5 (Tikanga) discussion
mailing-list
> Subject: [rhelv5-list] Xen Guest Disk Formatting
Unfeasibly Slow
> 
> 
> I'm trying to troubleshoot a problem where mkfs
commands take a really,
> really long time to complete in my Xen guests.   
> 
> I'm using sparse file-backed images created using the
'virt-install'
> command on RHEL 5.1 x86_64.  I'm kickstarting
paravirtualized RHEL 4.5
> and 5.1 x86_64 guests and they are going through a
standard, unattended
> install with a common diskmap.  When they get to
formatting the various
> local disks, all file system formats are taking
unfeasibly long.  A 20+
> GB file system takes upwards of 20 minutes to run an
mkfs on.  During
> the mkfs, the underlying filesystem on the DOM0 shows
high utilization
> via iostat (upwards on 99% utilization), but still the
mkfs is horribly,
> horribly slow.  mkfs is horribly slow whether I use a
GFS, ext3 or NFS
> underlying filesystem, so I don't think that is the
issue here.
> 
> If I create a non-sparse disk image or a physical
partition or logical
> volume, formatting times are drastically increased. 
However, I'm trying
> to be judicious with overall storage utilization and
flexibility, I
> would very much like to stick with sparse files.
> 
> Any advice on how I can troubleshoot this further or
possibly find a
> solution?  Is there another local disk driver I can use
besides
> "tap:aio" (like "file") during the
install process?
> 
> Note:  My underlying storage devices are Fibre Channel
Hitachi OPEN-V*3
> disks if it helps at all.
> 
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> rhelv5-list mailing list
> rhelv5-listredhat.com
> h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list


-- 

Cheers
John

-- spambait
1aaaaaaacoco.merseine.nu  Z1aaaaaaacoco.merseine.nu
-- Advice
http://webfoo
t.com/advice/email.top.php
ht
tp://www.catb.org/~esr/faqs/smart-questions.html
http://support
.microsoft.com/kb/555375

You cannot reply off-list

_______________________________________________
rhelv5-list mailing list
rhelv5-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list



  


  

    
  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )