From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqyzj-0002ob-7n for qemu-devel@nongnu.org; Wed, 19 Nov 2014 01:44:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xqyzd-0000Z9-2e for qemu-devel@nongnu.org; Wed, 19 Nov 2014 01:44:03 -0500 Received: from relay.parallels.com ([195.214.232.42]:39448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqyzc-0000Ak-RH for qemu-devel@nongnu.org; Wed, 19 Nov 2014 01:43:57 -0500 Message-ID: <546C37CC.2000504@parallels.com> Date: Wed, 19 Nov 2014 09:25:16 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <545CB9CE.9000302@parallels.com> <20141108071919.GB4940@fam-t430.nay.redhat.com> <54607427.8040404@parallels.com> <5462327C.5080704@redhat.com> <5464B80E.6060201@parallels.com> <546A88DD.10006@redhat.com> <546B254D.2020808@parallels.com> <546B44F4.9020301@parallels.com> <546B6EFE.5000108@redhat.com> In-Reply-To: <546B6EFE.5000108@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Vladimir Sementsov-Ogievskiy , Fam Zheng Cc: "Denis V. Lunev" , stefanha@redhat.com, qemu-devel@nongnu.org On 18/11/14 19:08, John Snow wrote: > > > On 11/18/2014 08:09 AM, Vladimir Sementsov-Ogievskiy wrote: >>> (3) Data Integrity >>> >>> The dirty flag could work something like: >>> >>> - If, on first open, the file has the dirty flag set, we need to >>> discard the bitmap data because we can no longer trust it. >>> - If the bitmap file is clean, proceed as normal, but take a lock >>> against any of the bitmap functions to prevent them from marking any >>> bits dirty. >>> - On first write to a clean persistent bitmap, delay the write until >>> we can mark the bitmap as dirty first. This incurs a write penalty >>> when we try to use the bitmap at first... >>> - Unlock the bitmap functions and allow them to mark blocks as needed. >>> - At some point, based on a sync policy, re-commit the dirty >>> information to the file and mark the file as clean once more and >>> re-take the persistence lock. >> Correct me if I'm wrong. >> - first of all what we are protecting against? Any QEMU or kernel crash leads to the disaster. You can not guarantee at all the consistency between data written to the main file (disk) and data written to bitmap except if you wait that dirty bitmap is really updated. In this case you will have performance halved in comparison with the host (each guest write means 2 IOPS instead of 1) - this effectively means that we can not be protected against crash - if we don't we could not care at all about bitmap updates when QEMU is running. We should write it only on stop/suspend/etc. This simplifies things a lot. So, the procedure is simple - stop main VM by using vm_pause - open/create bitmap file - set dirty - unpause That's all. If QEMU is running, bitmap is always dirty. The only exception is backup creation. New backup means that old bitmap is synced with dirty clear, new one is created with dirty set and backup starts working with old bitmap. Once again. In all other cases we can not guarantee that we will report _all_ changed blocks to backup software if crash happens in the middle. One missed block in the bitmap and the entire backup is blown up. This also means that (4) aka sync policy is simple. Do this on close. >> #Read bitmap: >> read in blockdev_init, before any write to device, so no lock is needed. >> >> #Set bits in bitmap: >> if bitmap.dirty_flag: >> set bits >> else: >> LOCK >> set bits >> set bitmap.dirty_flag >> set dirty_flag in bitmap file >> UNLOCK >> >> #Sync: >> if not bitmap.dirty_flag: >> skip sync >> else: >> LOCK >> save one of bitmap levels (saving the last one is too long and not >> very good idea, because it is fast-updateing) >> unset dirty_flag in bitmap file >> unset bitmap.dirty_flag >> UNLOCK >> >> #Last sync in bdrv_close: >> Just save the last bitmap level and unset dirty_flag in bitmap file >> >> Also.. I'm not quite sure about locking.. As I understand, co-routines >> in qemu are not running in parallel, is locking required? Or sync timer >> will not be co-routine based? >> >> Best regards, >> Vladimir > > Might be being too informal. I just meant a lock or barrier to prevent > actual IO throughput until we can confirm the dirty flag has been > adjusted to indicate that the persistent bitmap is now officially out of > date. Nothing fancy. > > Wasn't trying to imply that we needed threading protection, just > "locking" the IO until we can configure the bitmap as we need it to be. >