From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKSOk-0005PC-30 for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:23:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKSOa-00044P-Mj for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:22:54 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:50148 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKSOa-00043j-B5 for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:22:44 -0400 Message-ID: <52330386.8010709@kamp.de> Date: Fri, 13 Sep 2013 14:22:30 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1379067909-22984-1-git-send-email-pl@kamp.de> <1379067909-22984-6-git-send-email-pl@kamp.de> <5232EA41.3030607@redhat.com> <5232EC9C.2060301@kamp.de> <5232FAC7.7030001@redhat.com> In-Reply-To: <5232FAC7.7030001@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/12] block: add logical block provisioning information to BlockDriverInfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, stefanha@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws Am 13.09.2013 13:45, schrieb Paolo Bonzini: > Il 13/09/2013 12:44, Peter Lieven ha scritto: >> On 13.09.2013 12:34, Paolo Bonzini wrote: >>> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>>> + /* maximum number of sectors that can be discarded at once */ >>>> + int max_discard; >>>> + /* maximum number of sectors that can zeroized at once */ >>>> + int max_write_zeroes; >>> These should not be needed outside the driver. >>> >>> If you want to make them private between block.c and block/iscsi.c, you >>> can add them to BlockDriverState. >> The question is, if the discard_zeroes or discard_write_zeroes is needed >> outside the driver as well? >> >> I can put the max_* information in the block driver state. I also thought >> to add alignment and granularity information even if they are currently >> not yet used. > Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split > requests according to these parameters instead of introducing a new > function bdrv_zeroize. You don't need bdrv_zeroize I think; you can > simply use bdrv_write_zeroes. This is why I don't like this information > in BlockDriverInfo. bdrv_zeroize has one big advantage over a bdrv_write_zeroes over the whole device: it checks the block status before it sends requests. this can be a great performance benefit if a lot of blocks are already unmapped. so i would like to keep it in, but simplifiy it (see below). > > On the contrary, discard_write_zeroes is useful to "generic" clients, > and your qemu-img patch shows why. > > Discard_zeroes is somewhere in the middle. You only use it in > bdrv_get_block_status, but it is not something that should be hidden to > users of the high-level block.c API. So it is fine to leave it in > BlockDriverInfo. okay, i will leave them in and put max_discard discard_alignment max_write_zeroes write_zeroes_alignment into the BlockDriverState. I would then like to call out to all driver developers to set these values for their drivers to good values. For now I can factor out the request split logic out of iscsi_co_discard, iscsi_co_write_zeroes and bdrv_sanitize and put them in bdrv_co_discard and bdrv_co_write_zeroes. I would like to leave the misalignment logic to a later patch. What would you think are reasonable default values for max_discard and max_write_zeroes? Peter