From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL7fV-0003a3-E4 for qemu-devel@nongnu.org; Thu, 07 Jul 2016 07:40:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL7fR-0005sY-8Y for qemu-devel@nongnu.org; Thu, 07 Jul 2016 07:40:32 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:54905 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL7fQ-0005sP-VW for qemu-devel@nongnu.org; Thu, 07 Jul 2016 07:40:29 -0400 References: <1467284899-22575-1-git-send-email-pl@kamp.de> <0bdc5c9b-e565-d63d-c82c-acee433c036d@redhat.com> From: Peter Lieven Message-ID: <577E3FAA.3010606@kamp.de> Date: Thu, 7 Jul 2016 13:40:26 +0200 MIME-Version: 1.0 In-Reply-To: <0bdc5c9b-e565-d63d-c82c-acee433c036d@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block/iscsi: precache the allocation status of a target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, kwolf@redhat.com, mreitz@redhat.com, ronniesahlberg@gmail.com, famz@redhat.com Am 30.06.2016 um 17:59 schrieb Paolo Bonzini: > > On 30/06/2016 13:08, Peter Lieven wrote: >> this fills up the allocationmap at iscsi_open. This helps >> to reduce the number of get_block_status requests during runtime >> significantly. >> >> Signed-off-by: Peter Lieven >> --- >> block/iscsi.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/block/iscsi.c b/block/iscsi.c >> index 0cdcedb..04fb0a3 100644 >> --- a/block/iscsi.c >> +++ b/block/iscsi.c >> @@ -1774,6 +1774,22 @@ static int iscsi_open(BlockDriverState *bs, QDict *options, int flags, >> iscsilun->block_size) >> BDRV_SECTOR_BITS; >> if (iscsilun->lbprz) { >> ret = iscsi_allocmap_init(iscsilun, bs->open_flags); >> + if (ret == 0) { >> + unsigned int max_reqs = 64; >> + int64_t sector_num = 0; >> + while (max_reqs-- && sector_num < bs->total_sectors) { >> + int n; >> + BlockDriverState *file; >> + ret = bdrv_get_block_status(bs, sector_num, >> + BDRV_REQUEST_MAX_SECTORS, >> + &n, &file); >> + if (ret < 0) { >> + break; >> + } >> + sector_num += n; >> + ret = 0; >> + } >> + } >> } >> } >> >> > This can take a long time and the disks may not even be ever used. I > don't think it's a good idea. Sure, the target might stay unused, but why do you suspect its slow? Peter