From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYIoy-0002eJ-WA for qemu-devel@nongnu.org; Thu, 10 Apr 2014 13:31:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYIos-0005lM-R5 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 13:31:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYIos-0005lA-Im for qemu-devel@nongnu.org; Thu, 10 Apr 2014 13:31:22 -0400 Message-ID: <5346D55E.9070303@redhat.com> Date: Thu, 10 Apr 2014 19:31:10 +0200 From: Max Reitz MIME-Version: 1.0 References: <1394232956-27852-1-git-send-email-mreitz@redhat.com> <1394232956-27852-8-git-send-email-mreitz@redhat.com> <5343F65B.4000609@redhat.com> <526ACCFF-5A7F-49A3-AC2A-71A39782C834@kamp.de> In-Reply-To: <526ACCFF-5A7F-49A3-AC2A-71A39782C834@kamp.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 07/12] block/json: Add bdrv_co_get_block_status() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , =?windows-1252?Q?Beno=EEt_Canet?= , qemu-devel@nongnu.org, Stefan Hajnoczi On 08.04.2014 22:53, Peter Lieven wrote: > Am 08.04.2014 um 15:15 schrieb Max Reitz : > >> On 07.03.2014 23:55, Max Reitz wrote: >>> Implement this function in the same way as raw_bsd does: Acknowledge >>> that this is a passthrough driver (always return BDRV_BLOCK_OFFSET_VA= LID >>> and BDRV_BLOCK_DATA and derive the offset directly from the sector >>> index) and add BDRV_BLOCK_RAW to the returned value. >>> >>> Signed-off-by: Max Reitz >>> --- >>> block/json.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >> Ping =96 Beno=EEt is unsure of BDRV_BLOCK_RAW, therefore he elected no= t to give a reviewed-by for this patch. >> >> The commit introducing BDRV_BLOCK_RAW (92bc50a5ad7fbc9a0bd17240eaea502= 7a100ca79) is signed-off-by Peter, reviewed-by Eric and signed-off-by Kev= in (as the committer, I suppose). Could anyone of you comment on this pat= ch? The question is whether to use BDRV_BLOCK_RAW or a recursive call to = bdrv_get_block_status() here. I mean, I could just replace the BDRV_BLOCK= _RAW by a recursive call to bdrv_get_block_status() and Beno=EEt would pr= obably approve, but obviously that would be cheating. > Sorry, I missed Benoits earlier email. I have not fully looked through = the block/json patch set, but as far as I understand its a filter that ca= n be on top of any format/protocol combination. > Therefore the only right solution can be to pass the bdrv_co_get_block_= status call to the underlying format driver. > > As for the BDRV_BLOCK_RAW flag we introduced this for the special case = of the raw format which guarantees a linear mapping of the whole drive to= the underlaying protocol e.g. > file, iscsi, host_device, nfs=85 Therefore we can derive the file offse= t from the sector. The allocation status has to be queried from the proto= col driver. In fact in the raw format > case it would also work to pass the call to bs->file, but this would re= sult in 2 calls to bs->file->drv->bdrv_get_block_status for unallocated b= locks. Remember that bdrv_get_block_status > can be an expensive call e.g. in the iSCSI case. This is why I made com= mit 92bc50a5. > > Peter Thank you very much. I'll send a v3 without BDRV_BLOCK_RAW then. Max