From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxYWx-0000sr-LK for qemu-devel@nongnu.org; Wed, 27 May 2015 06:25:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxYWw-0005DZ-PP for qemu-devel@nongnu.org; Wed, 27 May 2015 06:25:47 -0400 Date: Wed, 27 May 2015 12:10:16 +0200 From: Kevin Wolf Message-ID: <20150527101016.GB4669@noname.str.redhat.com> 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> <55659372.9060804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55659372.9060804@redhat.com> 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: Paolo Bonzini Cc: Fam Zheng , qemu-block@nongnu.org, armbru@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , amit.shah@redhat.com Am 27.05.2015 um 11:50 hat Paolo Bonzini geschrieben: > > > 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. Block jobs don't generally have a source and a target; in fact, the design didn't even consider that such jobs exist (otherwise, we wouldn't have bs->job). There are some jobs that use a BDS read-only (source for backup, mirror, commit) just like there are guest devices that use the BDS read-only (CD-ROMs). And others write to it (streaming, hard disks). This doesn't seem to be the crucial difference between both. > > 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. Any problems with it because of which Fam decided against it? Kevin