qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster


From: Alberto Garcia
Subject: Re: [Qemu-block] [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Thu, 13 Apr 2017 15:36:27 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Thu 13 Apr 2017 03:09:53 PM CEST, Denis V. Lunev wrote:
>>> For nowadays SSD we are facing problems somewhere else. Right now I
>>> can achieve only 100k IOPSes on SSD capable of 350-550k. 1 Mb block
>>> with preallocation and fragmented L2 cache gives same 100k. Tests
>>> for initially empty image gives around 80k for us.
>> Preallocated images aren't particularly interesting to me. qcow2 is
>> used mainly for two reasons. One of them is sparseness (initially
>> small file size) mostly for desktop use cases with no serious I/O, so
>> not that interesting either. The other one is snapshots, i.e. backing
>> files, which doesn't work with preallocation (yet).
>>
>> Actually, preallocation with backing files is something that
>> subclusters would automatically enable: You could already reserve the
>> space for a cluster, but still leave all subclusters marked as
>> unallocated.
>
> I am spoken about fallocate() for the entire cluster before actual
> write() for originally empty image. This increases the performance of
> 4k random writes 10+ times. In this case we can just write those 4k
> and do nothing else.

You're talking about using fallocate() for filling a cluster with zeroes
before writing data to it.

As noted earlier in this thread, this works if the image is empty or if
it doesn't have a backing file.

And if the image is not empty you cannot guarantee that the cluster
contains zeroes (you can use FALLOC_FL_ZERO_RANGE, but that won't work
in all cases).

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]