From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztff5-0003xK-HW for qemu-devel@nongnu.org; Tue, 03 Nov 2015 12:46:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ztff4-0006TA-Ji for qemu-devel@nongnu.org; Tue, 03 Nov 2015 12:46:23 -0500 References: <1445644612-12702-1-git-send-email-jsnow@redhat.com> <20151103152208.GF15414@stefanha-x1.localdomain> From: John Snow Message-ID: <5638F2E8.2010703@redhat.com> Date: Tue, 3 Nov 2015 12:46:16 -0500 MIME-Version: 1.0 In-Reply-To: <20151103152208.GF15414@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v10 00/14] block: incremental backup transactions using BlockJobTxn List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: vsementsov@virtuozzo.com, famz@redhat.com, armbru@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org On 11/03/2015 10:22 AM, Stefan Hajnoczi wrote: > On Fri, Oct 23, 2015 at 07:56:38PM -0400, John Snow wrote: >> Welcome to V10! >> >> Where'd 8 and 9 go? Private off-list missives from Fam. >> Now you, I, and everyone on qemu-devel are staring at V10. >> >> What's new in V10? >> >> I replaced the per-action "transactional-cancel" parameter with >> a per-transaction paremeter named "err-cancel" which is implemented >> as an enum in case we want to add new behaviors in the future, such >> as a "jobs only" cancel mode. >> >> For now, it's "all" or "none", and if you use it with actions that >> do not support the latent transactional cancel, you will receive >> an error for your troubles. > > I left comments on a few patches. > > The "err-cancel" and "ActionCancelMode" naming does not describe the > concept fully, since successful block jobs will also behave differently > (waiting for each other to finish before fully completing). > "blockjob-transactions" is the best name I can think of that describes > the full concept rather than focus on just cancellation. > There's two hard problems in Computer Science... I mean, cancellation certainly is the biggest change in net behavior, though we are fiddling with the timings of the completion notices. OK, so continuing on my inability to name this feature ... blockjob-transactions = { individual, grouped, jobs-only } where we'd support "individual" as the default, "grouped" is the forced cancellation mode, and jobs-only is a hypothetical future mode that adds jobs to the group, and ignoring non-jobs' inability to join the transaction. Still, it seems weird to have: transaction 'properties': {'blockjob-transactions': 'grouped'}, it feels redundant to me. How about: completion-mode = { individual, grouped } Avoids repeating "Transaction" and does not hyperfocus on cancellation. > Besides that I'm happy with the QMP interface. >