From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj8Xm-0007cr-17 for qemu-devel@nongnu.org; Fri, 17 Apr 2015 11:51:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj8Xl-0003v6-5T for qemu-devel@nongnu.org; Fri, 17 Apr 2015 11:51:01 -0400 Message-ID: <55312BDA.2090009@redhat.com> Date: Fri, 17 Apr 2015 11:50:50 -0400 From: John Snow MIME-Version: 1.0 References: <1428531604-9428-1-git-send-email-jsnow@redhat.com> <1428531604-9428-2-git-send-email-jsnow@redhat.com> <5531215E.7090900@redhat.com> In-Reply-To: <5531215E.7090900@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 01/21] docs: incremental backup documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-block@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, mreitz@redhat.com On 04/17/2015 11:06 AM, Eric Blake wrote: > On 04/08/2015 04:19 PM, John Snow wrote: >> Reviewed-by: Max Reitz >> Signed-off-by: John Snow >> --- >> docs/bitmaps.md | 311 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 311 insertions(+) >> create mode 100644 docs/bitmaps.md >> >> diff --git a/docs/bitmaps.md b/docs/bitmaps.md >> new file mode 100644 >> index 0000000..ad8c33b >> --- /dev/null >> +++ b/docs/bitmaps.md >> @@ -0,0 +1,311 @@ >> +# Dirty Bitmaps and Incremental Backup >> + > > Still might be nice to list explicit copyright/license instead of > relying on implicit top-level GPLv2+, but I won't insist. > I think I would rather not clutter up the document itself, if that remains suitable. I don't mind those declarations in source code, but for a document like this, it seems weird to have it in the preamble. I can attach a license to the footer, if that's suitable? > >> +### Deletion >> + >> +* Can be performed on a disabled bitmap, but not a frozen one. > > Do you still have a notion of disabled bitmaps? Earlier, in '## Bitmap > Modes', you only document 'frozen' (as opposed to the default unnamed > state). > We do internally. It's not likely to come up from a user's perspective, but we do intend to disable the bitmap during e.g. migration, boot, etc. I did pull the "disabled" bit out because it's not a necessary detail yet. I'll tidy this up and reintroduce the language alongside the patch that may expose the user to witnessing a disabled bitmap. > >> + >> +## Transactions (Not yet implemented) > > I'm assuming that "[PATCH v2 00/11] block: incremental backup > transactions" is incomplete, because it forgot to clean this up as part > of adding transaction support. > Fixed in my local copy, yes. > >> + >> +5. Retry the command after fixing the underlaying problem, > > s/underlaying/underlying/ > :(