All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frediano Ziglio <freddy77@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [RFC] qcow2: 2 way to improve performance updating refcount
Date: Thu, 21 Jul 2011 18:17:44 +0200	[thread overview]
Message-ID: <1311265064.17547.2.camel@ricky> (raw)

Hi,
  after a snapshot is taken currently many write operations are quite
slow due to
- refcount updates (decrement old and increment new )
- cluster allocation and file expansion
- read-modify-write on partial clusters

I found 2 way to improve refcount performance

Method 1 - Lazy count
Mainly do not take into account count for current snapshot, that is
current snapshot counts as 0. This would require to add a
current_snapshot in header and update refcount when current is changed.
So for these operation
- creating snapshot, performance are the same, just increment for old
snapshot instead of the new one
- normal write operations. As current snaphot counts as 0 there is not
operations here so do not write any data
- changing current snapshot, this is the worst case, you have to
increment for the current snapshot and decrement for the new so it will
take twice
- deleting snapshot, if is the current just set current_snapshot to a
dummy not existing value, if is not the current just decrement counters,
no performance changes

Method 2 - Read-only parent
Here parents are readonly, instead of storing a refcount store a numeric
id of the owner. If the owner is not current copy the cluster and change
it. Considering this situation

A --- B --- C

B cannot be changed so in order to "change" B you have to create a new
snapshot

A --- B --- C
         \--- D

and change D. It can take more space cause you have in this case an
additional snapshot.

Operations:
- creating snapshot, really fast as you don't have to change any
ownership
- normal write operations. If owner is not the same allocate a new
cluster and just store a new owner for new cluster. Also ownership for
past-to-end cluster could be set all to current owner in order to
collapse allocations
- changing current snapshot, no changes required for owners
- deleting snapshot. Only possible if you have no child or a single
child. Will require to scan all l2 tables and merge and update owner.
Same performance

Regards
  Frediano Ziglio

             reply	other threads:[~2011-07-21 16:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-21 16:17 Frediano Ziglio [this message]
2011-07-22  8:05 ` [Qemu-devel] [RFC] qcow2: 2 way to improve performance updating refcount Kevin Wolf
2011-07-22  9:13   ` Frediano Ziglio
2011-07-22  9:29     ` Stefan Hajnoczi
2011-07-22 14:21       ` Frediano Ziglio
2011-07-22 16:47         ` Stefan Hajnoczi
2011-07-22  9:30     ` Kevin Wolf

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=1311265064.17547.2.camel@ricky \
    --to=freddy77@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.