On 06/04/2010 08:38 AM, Daniel P. Berrange wrote:
>> In that case, it may be better to have two constants - the preferred
>> transfer size (1M), and the XML padding block size (512 as before, or
>> perhaps 4k given newer disk architectures that prefer 4k), along with
>> code that allows the final t
On 06/04/2010 10:38 AM, Daniel P. Berrange wrote:
On Fri, Jun 04, 2010 at 08:23:32AM -0600, Eric Blake wrote:
In that case, it may be better to have two constants - the preferred
transfer size (1M), and the XML padding block size (512 as before, or
perhaps 4k given newer disk architectures t
On Fri, Jun 04, 2010 at 08:23:32AM -0600, Eric Blake wrote:
> On 06/04/2010 02:28 AM, Daniel P. Berrange wrote:
> > On Thu, Jun 03, 2010 at 11:57:33PM -0400, Laine Stump wrote:
> >> See https://bugzilla.redhat.com/show_bug.cgi?id=599091
> >>
> >> Saving a paused 512MB domain took 3m47s with the old
On 06/04/2010 02:28 AM, Daniel P. Berrange wrote:
> On Thu, Jun 03, 2010 at 11:57:33PM -0400, Laine Stump wrote:
>> See https://bugzilla.redhat.com/show_bug.cgi?id=599091
>>
>> Saving a paused 512MB domain took 3m47s with the old block size of 512
>> bytes. Changing the block size to 1024*1024 decr
On Thu, Jun 03, 2010 at 11:57:33PM -0400, Laine Stump wrote:
> See https://bugzilla.redhat.com/show_bug.cgi?id=599091
>
> Saving a paused 512MB domain took 3m47s with the old block size of 512
> bytes. Changing the block size to 1024*1024 decreased the time to 56
> seconds. (Doubling again to 2048
See https://bugzilla.redhat.com/show_bug.cgi?id=599091
Saving a paused 512MB domain took 3m47s with the old block size of 512
bytes. Changing the block size to 1024*1024 decreased the time to 56
seconds. (Doubling again to 2048*1024 yielded 0 improvement; lowering
to 512k increased the save time t
