qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Ivan Ren <renyime@gmail.com>
Cc: mreitz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3] qcow2: fix preallocation with metadata on bare block device
Date: Mon, 14 May 2018 08:23:43 +0200	[thread overview]
Message-ID: <20180514062343.GA6665@localhost.localdomain> (raw)
In-Reply-To: <CA+6E1==PkxLdnEGWMe5X0eKSPeGsVk3VQQ+fNs5+b_CDAcPMGg@mail.gmail.com>

Am 13.05.2018 um 15:37 hat Ivan Ren geschrieben:
> > Doesn't this defeat the purpose of preallocation? Usually, the idea with
> > preallocation is that you don't need to update any metadata on the first
> > write, but if you set QCOW_OFLAG_ZERO, we do need a metadata update
> > again.
> >
> > So what's the advantage compared to not preallocating at all?
> 
> Yes, when do this, the qcow2_alloc_cluster_offset will call handle_alloc
> again, and will lead metada update. Good news is that in handle_alloc the
> preallocated zero cluster offset will be reuse. In this case, the
> preallocated metata will be keeped except some flags, and the cluster
> offset is fixed.

Oh, yes, there is no doubt that the result will be correct. My point is
that people aren't usually interested so much in the physical layout of
the clusters, but more about the fact that no metadata updates and no
COW is necessary when you write to a cluster for the first time (i.e.
because preallocation brings some performance improvements).

Do you have a use case where the layout is more important? If there
are good reasons for either option, maybe we need two different
preallocation modes.

Kevin

  reply	other threads:[~2018-05-14  6:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 15:36 [Qemu-devel] [PATCH v3] qcow2: fix preallocation with metadata on bare block device Ivan Ren
2018-05-11 17:29 ` Kevin Wolf
2018-05-13 13:37   ` Ivan Ren
2018-05-14  6:23     ` Kevin Wolf [this message]
2018-05-14 14:30       ` Ivan Ren

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=20180514062343.GA6665@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=renyime@gmail.com \
    /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).