From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8nCe-0003ke-49 for qemu-devel@nongnu.org; Tue, 04 Sep 2012 03:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8nCY-0003VE-52 for qemu-devel@nongnu.org; Tue, 04 Sep 2012 03:05:40 -0400 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:40471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8nCX-0003Uu-FJ for qemu-devel@nongnu.org; Tue, 04 Sep 2012 03:05:34 -0400 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 4 Sep 2012 12:35:29 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q8475QwZ31326442 for ; Tue, 4 Sep 2012 12:35:27 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q8475P6E004592 for ; Tue, 4 Sep 2012 17:05:26 +1000 Message-ID: <5045A82D.2010200@linux.vnet.ibm.com> Date: Tue, 04 Sep 2012 15:05:17 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1346663926-20188-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1346663926-20188-2-git-send-email-xiawenc@linux.vnet.ibm.com> <5044B720.5080205@redhat.com> <5044B912.7020405@redhat.com> In-Reply-To: <5044B912.7020405@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/6] libqblock APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, stefanha@gmail.com, aliguori@us.ibm.com, Eric Blake , qemu-devel@nongnu.org 于 2012-9-3 22:05, Paolo Bonzini 写道: > Il 03/09/2012 15:56, Eric Blake ha scritto: >> Exactly how does the *pnum argument work? This interface looks like it >> isn't fully thought out yet. Either I want to know if a chunk of >> sectors is allocated (I supply start and length of sectors to check), >> regardless of how many sectors beyond that point are also allocated >> (pnum makes no sense); > > pnum makes sense if the [start, start+length) range includes both > allocated and unallocated sectors. > >> or I want to know how many sectors are allocated >> from a given point (I supply start, and the function returns length, so >> nb_sectors makes no sense). > About using byte offset instead of sector, I think sector is better, because the allocation status is based on sector, all bytes data in a sector would have the same status. > This operation could be O(number of blocks in disk) worst case, so it > makes sense to provide nb_sectors as an upper bound. nb_sectors is > typically dictated by the size of your buffer. > > That said, QEMU's internal bdrv_is_allocated function does have one not > entirely appealing property: the block at start + *pnum might have the > same state as the block at start + *pnum - 1, even if *pnum < length. > We may want to work around this in libqblock, but we could also simply > document it. > > Paolo > int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors,int *pnum) will the issue happen when nb_sectors > *pnum? if so it seems a bug, because caller is asking a range of sectors's allocation status, and *pnum did not reflect the real status. >> Either way, I think you are supplying too >> many parameters for how I envision checking for allocated sectors. > yes, it is a bit confusing, how about: int qb_check_allocate_status(struct QBroker *broker, struct QBlockState *qbs, offset sector_start, size_t sector_number, size_t *pnum, int *status) user input sector_start and sector_number to ask check it in this range, following parameter receive the status, return indicate exception. > -- Best Regards Wenchao Xia