From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxXzF-0001sc-FC for qemu-devel@nongnu.org; Wed, 27 May 2015 05:50:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxXzE-0005zt-K8 for qemu-devel@nongnu.org; Wed, 27 May 2015 05:50:57 -0400 Message-ID: <55659372.9060804@redhat.com> Date: Wed, 27 May 2015 11:50:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1432190583-10518-1-git-send-email-famz@redhat.com> <1432190583-10518-2-git-send-email-famz@redhat.com> <20150526142210.GI24077@noname.str.redhat.com> <55648220.1030206@redhat.com> <20150527090745.GA4669@noname.str.redhat.com> In-Reply-To: <20150527090745.GA4669@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Max Reitz Cc: Fam Zheng , qemu-block@nongnu.org, jcody@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Stefan Hajnoczi , amit.shah@redhat.com On 27/05/2015 11:07, Kevin Wolf wrote: > This is the first part of what's troubling me with this series, as it > makes me doubtful if op blockers are the right tool to implement what > the commit message says (block device I/O). This is "are we doing the > thing right?" > > The second part should actually come first, though: "Are we doing the > right thing?" I'm also doubtful whether blocking device I/O is even what > we should do. > > Why is device I/O special compared to block job I/O or NBD server I/O? Because block job I/O doesn't modify the source disk. For the target disk, block jobs should definitely treat themselves as device I/O and register notifiers that pause themselves on bdrv_drain. > If the answer is "because block jobs are already paused while draining" > (and probably nobody thought much about the NBD server), then chances > are that it's not the right thing. In fact, using two different > mechanisms for pausing block jobs and pausing device I/O seems > inconsistent and wrong. > > I suspect that the real solution needs to be in the block layer, though > I'm not quite sure yet what it would be like. Perhaps a function pair > like blk_stop/resume_io() that is used by bdrv_drain() callers and works > on the BlockBackend level. This is suspiciously similar to the first idea that I and Stefan had, which was a blk_pause/blk_resume API, implemented through a notifier list. Paolo