All of lore.kernel.org
 help / color / mirror / Atom feed
* Large IO Waits for srm.
@ 2005-04-10  7:07 Nicholas Lee
  0 siblings, 0 replies; 2+ messages in thread
From: Nicholas Lee @ 2005-04-10  7:07 UTC (permalink / raw)
  To: xen-devel

I've got four VMs running including dom0, on U320 SCSI md-raid1.

In domO I'm srm (secure delete) a couple 600Mb+ files. The other domUs are idle.

Xen 2.0.6-testing/2.6.11.6

nic@sea:/backup$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 3  1      4   1976     32  97020    0    0   193  1811  341   512  0  6 23 71
 0  1      4   2136     32  96836    0    0     3  2507  440   650  0  1  0 99
 0  1      4   2104     32  96872    0    0     0  2571  431   664  0  0  0 100
 0  1      4   2104     32  96868    0    0     0  2561  432   668  0  0  0 100
 0  1      4   2200     32  96792    0    0    37  2379  419   656  0  0  0 100

...

nic@sea:/backup$ w
 17:26:16 up  4:21,  1 user,  load average: 1.00, 1.00, 0.92
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
nic      pts/1    base-one.kiwa.co 17:22    0.00s  0.01s  0.00s w

The large IO wait level seems more than it should be. Here is an IDE
based non Xen system doing the same.

nic@lode:/home/bak$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  1  41984  57352   5856 352988    0    0     3     4    1     2  1  0 98  1
 1  1  41984  56264   5880 353000    0    0     1 24937 2584  5174  1 29  0 69
 1  0  41984  56264   5880 353020    0    0     0  6161 1417  1073  0 81  0 18
 1  0  41984  56208   5896 353052    0    0    11  1279 1106   462  0 97  0  3
 1  0  41984  56216   5904 353056    0    0     0  1256 1104   457  0 97  0  3
 1  0  41984  56216   5904 353068    0    0     0  1282 1120   457  0 97  0  3


Nicholas

^ permalink raw reply	[flat|nested] 2+ messages in thread
* RE: Large IO Waits for srm.
@ 2005-04-10 18:01 Ian Pratt
  0 siblings, 0 replies; 2+ messages in thread
From: Ian Pratt @ 2005-04-10 18:01 UTC (permalink / raw)
  To: Nicholas Lee, xen-devel

 
> nic@sea:/backup$ w
>  17:26:16 up  4:21,  1 user,  load average: 1.00, 1.00, 0.92
> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
> nic      pts/1    base-one.kiwa.co 17:22    0.00s  0.01s  0.00s w
> 
> The large IO wait level seems more than it should be. Here is 
> an IDE based non Xen system doing the same.

I wouldn't necessarily trust the iowait time to be correctly accounted.
Does the srm delete take noticeably longer? 

What happens if you do some simple tests to measure 'dd' performance in
both dom0 and the domU?

Best,
Ian 
 
> nic@lode:/home/bak$ vmstat 3
> procs -----------memory---------- ---swap-- -----io---- 
> --system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in  
>   cs us sy id wa
>  0  1  41984  57352   5856 352988    0    0     3     4    1  
>    2  1  0 98  1
>  1  1  41984  56264   5880 353000    0    0     1 24937 2584  
> 5174  1 29  0 69
>  1  0  41984  56264   5880 353020    0    0     0  6161 1417  
> 1073  0 81  0 18
>  1  0  41984  56208   5896 353052    0    0    11  1279 1106  
>  462  0 97  0  3
>  1  0  41984  56216   5904 353056    0    0     0  1256 1104  
>  457  0 97  0  3
>  1  0  41984  56216   5904 353068    0    0     0  1282 1120  
>  457  0 97  0  3
> 
> 
> Nicholas
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-04-10 18:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-10  7:07 Large IO Waits for srm Nicholas Lee
  -- strict thread matches above, loose matches on Subject: below --
2005-04-10 18:01 Ian Pratt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.