From: Denis Lunev <den@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>, Alberto Garcia <berto@igalia.com>
Cc: Anton Nefedov <anton.nefedov@virtuozzo.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Re-evaluating subcluster allocation for qcow2 images
Date: Thu, 27 Jun 2019 17:08:29 +0000 [thread overview]
Message-ID: <8ac8776c-f1d7-14eb-1a22-3db12fde7aef@virtuozzo.com> (raw)
In-Reply-To: <20190627165434.GE5618@localhost.localdomain>
[snip]
>> ===========================
>>
>> And I think that's all. As you can see I didn't want to go much into
>> the open technical questions (I think the on-disk format would be the
>> main one), the first goal should be to decide whether this is still an
>> interesting feature or not.
>>
>> So, any questions or comments will be much appreciated.
> It does like very interesting to me at least for small subcluster sizes.
>
> For the larger ones, I suspect that the Virtuozzo guys might be
> interested in performing more benchmarks to see whether it improves the
> fragmentation problems that they have talked about a lot. It might end
> up being interesting for these cases, too.
>
> Kevin
There is no difference in terms of data continuity if the space
under the whole cluster is allocated with fallocate() as noted
by Berto.
For large sizes I have posted different use case but with
slightly different constraints. Subcluster option could be
interesting in terms of random IO on big disks even after
the allocation.
But can we get a link to the repo with actual version of
patches.
Den
next prev parent reply other threads:[~2019-06-27 17:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 13:59 [Qemu-devel] [RFC] Re-evaluating subcluster allocation for qcow2 images Alberto Garcia
2019-06-27 14:19 ` Denis Lunev
2019-06-27 15:38 ` Alberto Garcia
2019-06-27 15:42 ` Alberto Garcia
2019-06-28 9:20 ` Kevin Wolf
2019-06-28 9:53 ` Alberto Garcia
2019-06-28 10:04 ` Kevin Wolf
2019-06-28 13:19 ` Alberto Garcia
2019-06-28 14:16 ` Kevin Wolf
2019-06-28 16:31 ` Alberto Garcia
2019-06-27 16:05 ` Denis Lunev
2019-06-28 14:43 ` Alberto Garcia
2019-06-28 14:47 ` Denis Lunev
2019-06-28 14:57 ` Kevin Wolf
2019-06-28 15:02 ` Alberto Garcia
2019-06-28 15:03 ` Denis Lunev
2019-06-28 15:10 ` Alberto Garcia
2019-06-28 15:15 ` Kevin Wolf
2019-06-28 15:09 ` Kevin Wolf
2019-06-28 15:12 ` Alberto Garcia
2019-07-01 6:22 ` Kevin Wolf
2019-06-27 16:54 ` Kevin Wolf
2019-06-27 17:08 ` Denis Lunev [this message]
2019-06-28 16:32 ` Alberto Garcia
2019-07-11 14:08 ` Alberto Garcia
2019-07-11 14:32 ` Kevin Wolf
2019-07-11 14:56 ` Alberto Garcia
2019-06-28 12:57 ` Alberto Garcia
2019-06-28 13:03 ` Alberto Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ac8776c-f1d7-14eb-1a22-3db12fde7aef@virtuozzo.com \
--to=den@virtuozzo.com \
--cc=anton.nefedov@virtuozzo.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).