qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Re-evaluating subcluster allocation for qcow2 ima


From: Alberto Garcia
Subject: Re: [Qemu-devel] [RFC] Re-evaluating subcluster allocation for qcow2 images
Date: Fri, 28 Jun 2019 17:12:33 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Fri 28 Jun 2019 05:09:11 PM CEST, Kevin Wolf wrote:
> Am 28.06.2019 um 17:02 hat Alberto Garcia geschrieben:
>> On Fri 28 Jun 2019 04:57:08 PM CEST, Kevin Wolf wrote:
>> > Am 28.06.2019 um 16:43 hat Alberto Garcia geschrieben:
>> >> On Thu 27 Jun 2019 06:05:55 PM CEST, Denis Lunev wrote:
>> >> > Please note, I am not talking now about your case with COW. Here the
>> >> > allocation is performed on the sub-cluster basis, i.e. the abscence of
>> >> > the sub-cluster in the image means hole on that offset. This is
>> >> > important difference.
>> >> 
>> >> I mentioned the possibility that if you have a case like 2MB / 64KB
>> >> and you write to an empty cluster then you could allocate the
>> >> necessary subclusters, and additionally fallocate() the space of the
>> >> whole cluster (2MB) in order to try to keep it contiguous.
>> >> 
>> >> With this we would lose the space saving advantage of having
>> >> subclusters. But perhaps that would work for smaller cluster sizes
>> >> (it would mitigate the fragmentation problem).
>> >
>> > There seem to be use cases for both ways. So does this need to be an
>> > option?
>> 
>> Probably a runtime option, or a heuristic that decides what to do
>> depending on the cluster size.
>
> How would the heuristic decide whether the user wants to save disk space
> or whether they consider avoiding fragmentation (i.e. performance) more
> important?

Well I suppose the fragmentation problem is more important when you have
small clusters and less so when you have large clusters, so that would
be a way to do it.

Of course with an option the user would have the final choice.

Berto



reply via email to

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