From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ywhw4-0006LO-0R for qemu-devel@nongnu.org; Sun, 24 May 2015 22:16:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ywhvz-0005pQ-1s for qemu-devel@nongnu.org; Sun, 24 May 2015 22:16:11 -0400 Date: Mon, 25 May 2015 10:15:52 +0800 From: Fam Zheng Message-ID: <20150525021552.GC7135@ad.nay.redhat.com> References: <1432190583-10518-1-git-send-email-famz@redhat.com> <1432190583-10518-2-git-send-email-famz@redhat.com> <555D83D8.4000302@cn.fujitsu.com> <20150521073202.GA1829@ad.nay.redhat.com> <20150522045450.GB1829@ad.nay.redhat.com> <5560B00F.6090006@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5560B00F.6090006@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: Max Reitz Cc: Kevin Wolf , qemu-block@nongnu.org, jcody@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Stefan Hajnoczi , amit.shah@redhat.com, pbonzini@redhat.com On Sat, 05/23 18:51, Max Reitz wrote: > On 22.05.2015 06:54, Fam Zheng wrote: > >On Thu, 05/21 15:32, Fam Zheng wrote: > >>On Thu, 05/21 15:06, Wen Congyang wrote: > >>>On 05/21/2015 02:42 PM, Fam Zheng wrote: > >>>>It blocks device IO. > >>>> > >>>>All bdrv_op_block_all/blk_op_block_all callers are taken care of: > >>>> > >>>>- virtio_blk_data_plane_create > >>>>- virtio_scsi_hotplug > >>>> > >>>> Device creation, unblock it. > >>>> > >>>>- bdrv_set_backing_hd > >>>> > >>>> Backing hd is not used by device, so blocking is OK. > >>>> > >>>>- backup_start > >>>> > >>>> Blocking target when backup is running, unblock it. > >>>Do you forget it? > >>Oh I think the commit log is wrong: the target image is only written to by > >>block job, there cannot be a device on it, so it it's similar to > >>bdrv_set_backing_hd. > >Correction: if it's blockdev-backup, the target could have a device, in that > >sense it should be unblocked like block_job_create(). I'll fix it. > > Really? I think it makes sense not to allow I/O on a backup target. At least > I can't imagine a use case where you'd want to do that... But that doesn't > necessarily mean anything, of course. Sure that nobody other than backup job itself should write to backup target, but it's valid to read it - image fleecing aims to export it through NBD server. If you attach it back to guest, it is as valid a scenario, isn't it? So at least for image fleecing, we need to either 1) split device IO blocker to read and write and only block write on target. 2) don't add device IO blocker at all, expect the disk's end user to take the responsibility. And I'm afraid 1) will be too complicated. Fam