From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0VVj-0003d2-6N for qemu-devel@nongnu.org; Thu, 23 Feb 2012 05:02:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0VVY-0001Vd-RD for qemu-devel@nongnu.org; Thu, 23 Feb 2012 05:02:51 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:59661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0VVY-0001VW-Az for qemu-devel@nongnu.org; Thu, 23 Feb 2012 05:02:40 -0500 Received: by lahi5 with SMTP id i5so1342150lah.4 for ; Thu, 23 Feb 2012 02:02:39 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20120223083204.GA10698@stefanha-thinkpad.localdomain> References: <20120223083204.GA10698@stefanha-thinkpad.localdomain> From: PANKAJ RAWAT Date: Thu, 23 Feb 2012 15:32:19 +0530 Message-ID: Content-Type: multipart/alternative; boundary=90e6ba308e8886ae6404b99ebe98 Subject: Re: [Qemu-devel] Cluster_size parameter issue on qcow2 image format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org --90e6ba308e8886ae6404b99ebe98 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reply . i am not using a backing file. My concern is growing file system. The performance of 64K is better than 1M , 2M or 32K Is the degrade in performance is only due to allocation of large cluster during expansion of qcow2 image ? But the trend is same in case of Sequential write Random write of 1 GB data In random i can understand the sparseness of data But in sequential write I don't understand as the write is performed on sequential bases is there is any reason behind it or i am not getting it right ? On Thu, Feb 23, 2012 at 2:02 PM, Stefan Hajnoczi wrote: > On Thu, Feb 23, 2012 at 11:01:46AM +0530, PANKAJ RAWAT wrote: > > I theory regarding cluster size it is written that as the size of > cluster > > increase performance should increase. > > > > But something surprising happen The performance is degrading as the size > of > > cluster increased from 64K to 1M ( during expansion of qcow2 image) > > It's not true that performance should increase by raising the cluster > size, otherwise the default would be infinity. It's an algorithms/data > structure trade-off. > > Most importantly is the relative latency between a small guest I/O > request (e.g. 4 KB) and the cluster size (e.g. 64 KB). If the cluster > size latency is orders of magnitude larger than a small guest I/O > request, then be prepared to see extreme effects described below: > > * Bigger clusters decrease the frequency of metadata operations and > increase metadata cache hit rates. Bigger clusters means less > metadata so qcow2 performs fewer metadata operations overall. > > Performance boost. > > * Bigger clusters increase the cost of allocating a new cluster. For > example, a 8 KB write to a new cluster will incur a 1 MB write to the > image file (the untouched regions are filled with zeros). This can > be optimized in some cases but not everywhere (e.g. reallocating a > data cluster versus extending the image file size and relying on the > file system to provide zeroed space). This is especially expensive > when a backing file is in use because up to 1 MB of the backing file > needs to be read to populate the newly allocated cluster! > > Performance loss. > > * Bigger clusters can reduce fragmentation of data on the physical > disk. The file system sees fewer, bigger allocating writes and is > therefore able to allocate more contiguous data - less fragmentation. > > Performance boost. > > * Bigger clusters reduce the compactness of sparse files. you use more > image file space on the host file system when the cluster size is > large. > > Space efficiency loss. > > Here's a scenario where a 1 MB cluster size is great compared to a large > cluster size: > > You have a fully allocated qcow2 image, you will never need to do any > allocating writes. > > Here's a scenario where a 1 MB cluster size is terrible compared to a > small cluster size: > > You have an empty qcow2 file and perform 4 KB writes to the first sector > of each 1 MB chunk, and there is a backing file. > > So it depends on the application. > > Stefan > -- *Pankaj Rawat* --90e6ba308e8886ae6404b99ebe98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the reply .
i am not using a backing file.
My concern is = growing file system.
The performance of 64K is better than 1M , 2M or 3= 2K

Is the degrade in performance is only due to allocation of large= cluster during expansion of qcow2 image ?

But the trend is same in case of
Sequential write
Random write=A0= of 1 GB data

In random i can understand the sparseness of data
B= ut in sequential write I don't understand as the write is performed on = sequential bases

is there is any reason behind it or i am not getting it right ?

=
On Thu, Feb 23, 2012 at 2:02 PM, Stefan Hajnoczi= <stefanha@gmail= .com> wrote:
On Thu, Feb 23, 2012 at 11= :01:46AM +0530, PANKAJ RAWAT wrote:
> I theory regarding =A0cluster size it is written that as the size of c= luster
> increase performance should increase.
>
> But something surprising happen The performance is degrading as the si= ze of
> cluster increased from 64K to 1M =A0( during expansion of qcow2 image)=

It's not true that performance should increase by raising the clu= ster
size, otherwise the default would be infinity. =A0It's an algorithms/da= ta
structure trade-off.

Most importantly is the relative latency between a small guest I/O
request (e.g. 4 KB) and the cluster size (e.g. 64 KB). =A0If the cluster size latency is orders of magnitude larger than a small guest I/O
request, then be prepared to see extreme effects described below:

=A0* Bigger clusters decrease the frequency of metadata operations and
=A0 increase metadata cache hit rates. =A0Bigger clusters means less
=A0 metadata so qcow2 performs fewer metadata operations overall.

=A0 Performance boost.

=A0* Bigger clusters increase the cost of allocating a new cluster. =A0For<= br> =A0 example, a 8 KB write to a new cluster will incur a 1 MB write to the<= br> =A0 image file (the untouched regions are filled with zeros). =A0This can<= br> =A0 be optimized in some cases but not everywhere (e.g. reallocating a
=A0 data cluster versus extending the image file size and relying on the =A0 file system to provide zeroed space). =A0This is especially expensive<= br> =A0 when a backing file is in use because up to 1 MB of the backing file =A0 needs to be read to populate the newly allocated cluster!

=A0 Performance loss.

=A0* Bigger clusters can reduce fragmentation of data on the physical
=A0 disk. =A0The file system sees fewer, bigger allocating writes and is =A0 therefore able to allocate more contiguous data - less fragmentation.<= br>
=A0 Performance boost.

=A0* Bigger clusters reduce the compactness of sparse files. you use more =A0 image file space on the host file system when the cluster size is
=A0 large.

=A0 Space efficiency loss.

Here's a scenario where a 1 MB cluster size is great compared to a larg= e
cluster size:

You have a fully allocated qcow2 image, you will never need to do any
allocating writes.

Here's a scenario where a 1 MB cluster size is terrible compared to a small cluster size:

You have an empty qcow2 file and perform 4 KB writes to the first sector of each 1 MB chunk, and there is a backing file.

So it depends on the application.

Stefan



--
Pankaj Rawat

--90e6ba308e8886ae6404b99ebe98--