From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz3ck-0000uy-6I for qemu-devel@nongnu.org; Tue, 16 Jul 2013 07:40:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz3ch-0004xe-J3 for qemu-devel@nongnu.org; Tue, 16 Jul 2013 07:40:54 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:47835 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Uz3ch-0004xS-8C for qemu-devel@nongnu.org; Tue, 16 Jul 2013 07:40:51 -0400 Message-ID: <51E53137.3020202@kamp.de> Date: Tue, 16 Jul 2013 13:40:39 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1373885375-13601-1-git-send-email-pl@kamp.de> <51E526B3.9070203@redhat.com> <51E52BF8.1000005@kamp.de> <51E52E28.5060701@redhat.com> In-Reply-To: <51E52E28.5060701@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] qemu-img: conditionally discard target on convert List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com On 16.07.2013 13:27, Paolo Bonzini wrote: > Il 16/07/2013 13:18, Peter Lieven ha scritto: >>> Looks good. Perhaps, as a followup, you can use max_unmap (which I'd >>> rename to max_discard) in bdrv_co_discard to support splitting the >>> request. You could also export the discard alignment in BlockDriverInfo. >> I already did this in my previous series for iscsi. >> But I can also add a follow >> up if in the future another driver specifies max_discard. I will drop it >> from iscsi again then. > In general, I prefer to have things in the block layer if there is a > chance of them becoming generic. I guess in this case the chance is > relatively small. > > On the other hand, if you add any smartness such as handling alignment > (see http://lkml.org/lkml/2012/7/5/342) please do take the occasion to > move it out of block/iscsi.c. I will do as a follow up and split the requests and align them properly if I get the info from bdrv_get_info. > >> Before this patch here is merged, we need the other series "[PATCHv3 >> 00/10] iscsi/qemu-img/block-migration enhancements" >> otherwise patch 2/4 will not apply. Maybe you can put it together again >> or I will do a v4 with all patches together. > Perhaps. Both might also conflict with my get_block_status patches. > I'm going to send an updated version today. Ugh, it's already 1:30 PM. :( If the perhaps means I should sent a v4 it would be good to know in which order the patches will be merged ;-) If you want to merge them please also include "[PATCHv3] block-migration: efficiently encode zero blocks". The conflict with your block status patches can't be large. upstream/master has no iscsi_co_is_allocated yet, so there should be no trouble. If you find no objections merging "[PATCHv3 00/10] iscsi/qemu-img/block-migration enhancements" first would be nice. Patch 06/10 and 10/10 are important fixes. Thanks Peter