> >
> > Now that I have tap:aio working under GPLPV, I have found that the
> > performance is terrible (as in something is wrong). Under any sort
of> > load, the system becomes effectively frozen - block requests appear
to> > be taking seconds.
> >
> > Currently I have up to 16 requests ''in the air'' at a
time... is that
> too
> > much for tap:aio? Is there something else I could be doing wrong?
> >
> > It''s got me baffled at the moment...
> >
>
> This continues to frustrate me. I thought maybe using
''sparse'' files
to> back tap:aio might be causing problems so I freed up some space and
> created a non-sparse file, but that didn''t change anything.
>
> The backup exec restore fly''s along at about 600mb/min until it
has
> restored about 500mb and then it drops to about 12mb/min, and the DomU
> is effectively unusable (anything that needs disk activity takes
forever> to get there...). Once the restore finally cancel''s (this takes a
long
> time too) the performance comes back to being usable.
>
> Next I''ll try it under Linux instead of GPLPV... but I
can''t think why
> that would make a difference...
>
Just for the archives, I have resolved the problem. The disks are all on
a HP Smart Array E200 controller using the cciss driver. Using a disk on
the onboard SATA interface instead, tap:aio can easily sustain restore
throughput of over 600mb/min.
Looking more closely, the raid controller and Ethernet adapter are both
sharing an interrupt, so I think that the Ethernet interrupts were being
serviced at the expense of the raid interrupts.
I''ll try moving the raid controller to a different slot and
I''m sure
that the problem will go away, but either way the problem is not xen or
tap:aio related.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel