From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, pbonzini@redhat.com,
Fam Zheng <famz@redhat.com>,
stefanha@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps
Date: Thu, 27 Aug 2015 13:08:13 +0300 [thread overview]
Message-ID: <55DEE18D.5060006@virtuozzo.com> (raw)
In-Reply-To: <5589F800.40302@redhat.com>
On 24.06.2015 03:21, John Snow wrote:
>
> On 06/17/2015 10:29 AM, Vladimir Sementsov-Ogievskiy wrote:
>> On 12.06.2015 22:34, John Snow wrote:
>>>
...
>>>
>>> (9) Data consistency
>>>
>>> We need to discuss the data safety element to this. I think that
>>> atomically before the first write is flushed to disk, the dirty bitmap
>>> needs to *at least* set a bit in the bitmap header that indicates that
>>> the bitmap is no longer up-to-date.
>>>
>>> When the bitmap is later flushed to disk, that bit can be cleared until
>>> the next write occurs, which repeats the process.
Not the next write, but next change in the bitmap. Write possibly may
not change the bitmap (if corresponding bit is already dirty). This is
the key thing, which can seriously extent life of in_use=0.
>>>
>>> We have discussed this (long ago) in the past, but one of the ideas was
>>> to monitor the relative utilization rate of the disk and attempt to
>>> flush the bitmap whenever there was a lull in disk IO, then clear the
>>> "inconsistent" bit.
>>>
>>> On close, the flush of data and bitmap both would lead us to clear this
>>> bit as well.
>>>
>>> Upon boot, if the inconsistent bit was set, we'd know that the bitmap
>>> was outdated and we'd have to recommend that the bitmap be cleared and a
>>> new bitmap started.
>>>
>>> (Or, perhaps, a data-intensive mode where we compare the current data
>>> mode with the most recent incremental backup to re-determine what data
>>> has changed. This would be very, very slow but an option at least for
>>> recovery if started a new full backup is even less desirable.)
>>>
>>> Other ideas involve regularly flushing the bitmap at certain timed
>>> intervals, certain usage intervals (e.g. when the changed bitmap data
>>> reaches some total size, like 64KiB of changed bits), or a combination
>>> of regular intervals with "opportunistic" flushing during Disk IO lulls.
>>>
>>> This is a key feature that absolutely needs to make it into the base
>>> series, IMO.
>> I don't understand, what the use of flushing bitmap not only on
>> disk:close? If there no failures with disk, than bitmap will be flushed
>> on close and will be consistent for next open(). If there is a disk
>> crash, even if we flush the bitmap regularly, what is the possibility of
>> crashing immediately after last flush, before further io-s?
>>
> The usage case is QEMU crash, power failure, etc. Not disk crash. If we
> periodically flush to HD, we increase the chances that we don't corrupt
> our image and bitmap.
>
> If we NEVER flush, we guarantee that any segfault or power outage will
> absolutely trash our data.
Also, I have the following idea:
Disk is written often.
Bitmap is updated more seldom.
HBitmap previous level is updated even more seldom..
To not store all bitmap levels in file, just save in the image file the
number of largest consistent level:
flush bitmap: consistent_level = HBITMAP_MAX_LEVEL
change bitmap level X: if consistent_level > X then consistent_level = X
- 1 (and flush consistent_level to file)
Then, after fail, we can restore the bitmap from last consistent level:
gran = 1 << (level_bits * (HBITMAP_MAX_LEVEL - consistent_level))
bitmap[i] = bitmap[i - i % gran] OR bitmap[i - i % gran + 1] OR ... OR
bitmap[i - i % gran + (gran - 1)]
to make this scheme independent of HBitmap, it may be better to number
levels from 0 (0 is largest level), and save level_bits to Image file too.
--
Best regards,
Vladimir
* now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.
prev parent reply other threads:[~2015-08-27 10:08 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 15:21 [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps Vladimir Sementsov-Ogievskiy
2015-06-08 15:21 ` [Qemu-devel] [PATCH 1/8] spec: add qcow2-dirty-bitmaps specification Vladimir Sementsov-Ogievskiy
2015-06-09 16:01 ` John Snow
2015-06-09 17:03 ` Stefan Hajnoczi
2015-06-10 8:19 ` Vladimir Sementsov-Ogievskiy
2015-06-10 8:49 ` Vladimir Sementsov-Ogievskiy
2015-06-10 13:00 ` Eric Blake
2015-06-11 10:16 ` Vladimir Sementsov-Ogievskiy
2015-06-10 13:24 ` Stefan Hajnoczi
2015-06-11 10:19 ` Vladimir Sementsov-Ogievskiy
2015-06-11 13:03 ` Stefan Hajnoczi
2015-06-11 16:21 ` John Snow
2015-06-12 10:28 ` Stefan Hajnoczi
2015-06-12 15:19 ` John Snow
2015-06-10 15:34 ` Kevin Wolf
2015-06-11 10:25 ` Vladimir Sementsov-Ogievskiy
2015-06-11 16:30 ` John Snow
2015-06-12 8:33 ` Kevin Wolf
2015-08-24 10:46 ` Vladimir Sementsov-Ogievskiy
2015-08-24 13:30 ` Vladimir Sementsov-Ogievskiy
2015-08-24 14:08 ` Vladimir Sementsov-Ogievskiy
2015-08-24 14:04 ` Vladimir Sementsov-Ogievskiy
2015-08-31 22:21 ` Eric Blake
2015-08-31 22:24 ` John Snow
2015-06-08 15:21 ` [Qemu-devel] [PATCH 2/8] qcow2: add dirty-bitmaps feature Vladimir Sementsov-Ogievskiy
2015-06-09 16:52 ` Stefan Hajnoczi
2015-06-10 14:30 ` Stefan Hajnoczi
2015-06-12 19:02 ` John Snow
2015-06-15 14:42 ` Stefan Hajnoczi
2015-06-23 17:57 ` John Snow
2015-06-24 9:39 ` Stefan Hajnoczi
2015-08-14 17:14 ` Vladimir Sementsov-Ogievskiy
2015-08-26 9:09 ` Stefan Hajnoczi
2015-06-11 23:04 ` John Snow
2015-06-15 14:05 ` Vladimir Sementsov-Ogievskiy
2015-06-15 16:53 ` John Snow
2015-06-12 21:55 ` John Snow
2015-08-26 13:15 ` Vladimir Sementsov-Ogievskiy
2015-08-26 14:14 ` Vladimir Sementsov-Ogievskiy
2015-08-27 12:43 ` Vladimir Sementsov-Ogievskiy
2015-06-08 15:21 ` [Qemu-devel] [PATCH 3/8] block: store persistent dirty bitmaps Vladimir Sementsov-Ogievskiy
2015-06-08 15:21 ` [Qemu-devel] [PATCH 4/8] block: add bdrv_load_dirty_bitmap Vladimir Sementsov-Ogievskiy
2015-06-09 16:01 ` Stefan Hajnoczi
2015-06-10 22:33 ` John Snow
2015-06-11 10:41 ` Vladimir Sementsov-Ogievskiy
2015-06-08 15:21 ` [Qemu-devel] [PATCH 5/8] qcow2: add qcow2_dirty_bitmap_delete_all Vladimir Sementsov-Ogievskiy
2015-06-08 15:21 ` [Qemu-devel] [PATCH 6/8] qcow2: add autoclear bit for dirty bitmaps Vladimir Sementsov-Ogievskiy
2015-06-09 15:49 ` Stefan Hajnoczi
2015-06-09 15:50 ` Stefan Hajnoczi
2015-08-27 7:45 ` Vladimir Sementsov-Ogievskiy
2015-08-31 11:06 ` Vladimir Sementsov-Ogievskiy
2015-08-31 22:39 ` Eric Blake
2015-08-31 22:50 ` Eric Blake
2015-06-10 23:42 ` John Snow
2015-06-11 8:35 ` Kevin Wolf
2015-06-11 10:49 ` Vladimir Sementsov-Ogievskiy
2015-06-11 16:36 ` John Snow
2015-06-08 15:21 ` [Qemu-devel] [PATCH 7/8] qemu: command line option " Vladimir Sementsov-Ogievskiy
2015-06-11 20:57 ` John Snow
2015-06-12 21:49 ` John Snow
2015-06-08 15:21 ` [Qemu-devel] [PATCH 8/8] iotests: test internal persistent dirty bitmap Vladimir Sementsov-Ogievskiy
2015-06-09 16:17 ` Eric Blake
2015-06-10 15:27 ` [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps Stefan Hajnoczi
2015-06-11 11:22 ` Vladimir Sementsov-Ogievskiy
2015-06-11 13:14 ` Stefan Hajnoczi
2015-06-11 20:06 ` Stefan Hajnoczi
2015-06-12 9:58 ` Denis V. Lunev
2015-06-12 10:36 ` Stefan Hajnoczi
2015-08-26 6:26 ` Vladimir Sementsov-Ogievskiy
2015-08-26 9:13 ` Stefan Hajnoczi
2015-06-12 19:34 ` John Snow
2015-06-17 14:29 ` Vladimir Sementsov-Ogievskiy
2015-06-24 0:21 ` John Snow
2015-07-08 12:24 ` Vladimir Sementsov-Ogievskiy
2015-07-08 15:21 ` John Snow
2015-08-27 10:08 ` Vladimir Sementsov-Ogievskiy [this message]
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=55DEE18D.5060006@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--cc=famz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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.