On Mon, Feb 14, 2022 at 01:11:52PM +0200, Nir Soffer wrote:
On Mon, Feb 14, 2022 at 11:56 AM Richard W.M. Jones
<rjones(a)redhat.com> wrote:
>
> This change slowed things down (slightly) for me, although the change
> is within the margin of error so it probably made no difference.
>
> Before:
...
> [ 79.3] Copying disk 1/1
> █ 100% [****************************************]
> [ 89.9] Creating output metadata
10.6 seconds...
> After:
...
> [ 81.6] Copying disk 1/1
> █ 100% [****************************************]
> [ 91.3] Creating output metadata
9.7 seconds - 9% speedup.
We cannot compare the total time since creating a disk can be take 4-16
seconds.
What kind of storage is this? Is this the local storage hack used as NFS?
You may get much better performance with local disk, hiding the delays in
writing to shared storage. But most oVirt users use NFS or GlsuterFS.
Yes, it's the Posix local storage attached to a single oVirt node (the
only node).
I tested on NFS, tuned to simulate a fast NFS server.
Testing such changes should be done on a real server with real storage.
I'll try to get a server in our scale lab to do more real testing.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW