From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qjvwc-0000Xm-N6 for qemu-devel@nongnu.org; Thu, 21 Jul 2011 12:17:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qjvwb-0008LV-QV for qemu-devel@nongnu.org; Thu, 21 Jul 2011 12:17:50 -0400 Received: from mail-wy0-f173.google.com ([74.125.82.173]:58939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qjvwb-0008LR-JX for qemu-devel@nongnu.org; Thu, 21 Jul 2011 12:17:49 -0400 Received: by wyf28 with SMTP id 28so1087340wyf.4 for ; Thu, 21 Jul 2011 09:17:48 -0700 (PDT) From: Frediano Ziglio Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 21 Jul 2011 18:17:44 +0200 Message-ID: <1311265064.17547.2.camel@ricky> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] qcow2: 2 way to improve performance updating refcount List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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