[{"id":1771877,"web_url":"http://patchwork.ozlabs.org/comment/1771877/","msgid":"<20170920095711.GA4058@lemon.lan>","list_archive_url":null,"date":"2017-09-20T09:57:11","subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","submitter":{"id":24872,"url":"http://patchwork.ozlabs.org/api/people/24872/","name":"Fam Zheng","email":"famz@redhat.com"},"content":"On Thu, 09/14 09:40, Eric Blake wrote:\n> We are gradually moving away from sector-based interfaces, towards\n> byte-based. Update the file protocol driver accordingly. In mapping\n> mode, note that the entire file is reported as allocated, so we can\n> take a shortcut and skip lseek().\n> \n> Signed-off-by: Eric Blake \n> \n> ---\n> v2: tweak comment, add mapping support\n> ---\n> block/file-posix.c | 57 ++++++++++++++++++++++++++++++------------------------\n> 1 file changed, 32 insertions(+), 25 deletions(-)\n> \n> diff --git a/block/file-posix.c b/block/file-posix.c\n> index 72ecfbb0e0..6813059867 100644\n> --- a/block/file-posix.c\n> +++ b/block/file-posix.c\n> @@ -2107,24 +2107,25 @@ static int find_allocation(BlockDriverState *bs, off_t start,\n> }\n> \n> /*\n> - * Returns the allocation status of the specified sectors.\n> + * Returns the allocation status of the specified offset.\n> *\n> - * If 'sector_num' is beyond the end of the disk image the return value is 0\n> + * If 'offset' is beyond the end of the disk image the return value is 0\n> * and 'pnum' is set to 0.\n> *\n> - * 'pnum' is set to the number of sectors (including and immediately following\n> - * the specified sector) that are known to be in the same\n> + * 'pnum' is set to the number of bytes (including and immediately following\n> + * the specified offset) that are known to be in the same\n> * allocated/unallocated state.\n> *\n> - * 'nb_sectors' is the max value 'pnum' should be set to. If nb_sectors goes\n> + * 'bytes' is the max value 'pnum' should be set to. If bytes goes\n> * beyond the end of the disk image it will be clamped.\n> */\n> -static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,\n> - int64_t sector_num,\n> - int nb_sectors, int *pnum,\n> - BlockDriverState **file)\n> +static int64_t coroutine_fn raw_co_block_status(BlockDriverState *bs,\n> + bool mapping,\n> + int64_t offset,\n> + int64_t bytes, int64_t *pnum,\n> + BlockDriverState **file)\n> {\n> - off_t start, data = 0, hole = 0;\n> + off_t data = 0, hole = 0;\n> int64_t total_size;\n> int ret;\n> \n> @@ -2133,39 +2134,45 @@ static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,\n> return ret;\n> }\n> \n> - start = sector_num * BDRV_SECTOR_SIZE;\n> total_size = bdrv_getlength(bs);\n> if (total_size < 0) {\n> return total_size;\n> - } else if (start >= total_size) {\n> + } else if (offset >= total_size) {\n> *pnum = 0;\n> return 0;\n> - } else if (start + nb_sectors * BDRV_SECTOR_SIZE > total_size) {\n> - nb_sectors = DIV_ROUND_UP(total_size - start, BDRV_SECTOR_SIZE);\n> + } else if (offset + bytes > total_size) {\n> + bytes = total_size - offset;\n> }\n> \n> - ret = find_allocation(bs, start, &data, &hole);\n> + if (!mapping) {\n> + *pnum = bytes;\n> + *file = bs;\n> + return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID |\n> + (offset & BDRV_BLOCK_OFFSET_MASK);\n> + }\n\nI may be missing something, because the last time I tried to understand the\nrationale behind \"mapping\" was already some time ago: shouldn't we still\ndistinguish hole and data? What will omitting BDRV_BLOCK_ZERO help?\n\nFam\n\n> +\n> + ret = find_allocation(bs, offset, &data, &hole);\n> if (ret == -ENXIO) {\n> /* Trailing hole */\n> - *pnum = nb_sectors;\n> + *pnum = bytes;\n> ret = BDRV_BLOCK_ZERO;\n> } else if (ret < 0) {\n> /* No info available, so pretend there are no holes */\n> - *pnum = nb_sectors;\n> + *pnum = bytes;\n> ret = BDRV_BLOCK_DATA;\n> - } else if (data == start) {\n> - /* On a data extent, compute sectors to the end of the extent,\n> + } else if (data == offset) {\n> + /* On a data extent, compute bytes to the end of the extent,\n> * possibly including a partial sector at EOF. */\n> - *pnum = MIN(nb_sectors, DIV_ROUND_UP(hole - start, BDRV_SECTOR_SIZE));\n> + *pnum = MIN(bytes, hole - offset);\n> ret = BDRV_BLOCK_DATA;\n> } else {\n> - /* On a hole, compute sectors to the beginning of the next extent. */\n> - assert(hole == start);\n> - *pnum = MIN(nb_sectors, (data - start) / BDRV_SECTOR_SIZE);\n> + /* On a hole, compute bytes to the beginning of the next extent. */\n> + assert(hole == offset);\n> + *pnum = MIN(bytes, data - offset);\n> ret = BDRV_BLOCK_ZERO;\n> }\n> *file = bs;\n> - return ret | BDRV_BLOCK_OFFSET_VALID | start;\n> + return ret | BDRV_BLOCK_OFFSET_VALID | (offset & BDRV_BLOCK_OFFSET_MASK);\n> }\n> \n> static coroutine_fn BlockAIOCB *raw_aio_pdiscard(BlockDriverState *bs,\n> @@ -2259,7 +2266,7 @@ BlockDriver bdrv_file = {\n> .bdrv_close = raw_close,\n> .bdrv_create = raw_create,\n> .bdrv_has_zero_init = bdrv_has_zero_init_1,\n> - .bdrv_co_get_block_status = raw_co_get_block_status,\n> + .bdrv_co_block_status = raw_co_block_status,\n> .bdrv_co_pwrite_zeroes = raw_co_pwrite_zeroes,\n> \n> .bdrv_co_preadv = raw_co_preadv,\n> -- \n> 2.13.5\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=famz@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy1SM5RLcz9s7f\n\tfor ;\n\tWed, 20 Sep 2017 23:54:11 +1000 (AEST)","from localhost ([::1]:48222 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dufS5-0008Vs-Io\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 09:54:09 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:39645)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duf7Z-00088I-86\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:33:01 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duf7X-0007xl-RI\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:32:57 -0400","from mx1.redhat.com ([209.132.183.28]:63078)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duf7S-0007tC-PS; Wed, 20 Sep 2017 09:32:51 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 8BE23C0587C1;\n\tWed, 20 Sep 2017 09:57:13 +0000 (UTC)","from localhost (ovpn-12-90.pek2.redhat.com [10.72.12.90])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id C8EDA5C670;\n\tWed, 20 Sep 2017 09:57:12 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8BE23C0587C1","Date":"Wed, 20 Sep 2017 17:57:11 +0800","From":"Fam Zheng ","To":"Eric Blake ","Message-ID":"<20170920095711.GA4058@lemon.lan>","References":"<20170914144032.14945-1-eblake@redhat.com>\n\t<20170914144032.14945-4-eblake@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170914144032.14945-4-eblake@redhat.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.32]);\n\tWed, 20 Sep 2017 09:57:13 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771945,"web_url":"http://patchwork.ozlabs.org/comment/1771945/","msgid":"<0c239541-da93-33d0-1c0e-88e29de89e2c@redhat.com>","list_archive_url":null,"date":"2017-09-20T13:47:40","subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/20/2017 04:57 AM, Fam Zheng wrote:\n> On Thu, 09/14 09:40, Eric Blake wrote:\n>> We are gradually moving away from sector-based interfaces, towards\n>> byte-based. Update the file protocol driver accordingly. In mapping\n>> mode, note that the entire file is reported as allocated, so we can\n>> take a shortcut and skip lseek().\n>>\n>> Signed-off-by: Eric Blake \n>>\n\n>>\n>> - ret = find_allocation(bs, start, &data, &hole);\n>> + if (!mapping) {\n>> + *pnum = bytes;\n>> + *file = bs;\n>> + return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID |\n>> + (offset & BDRV_BLOCK_OFFSET_MASK);\n>> + }\n> \n> I may be missing something, because the last time I tried to understand the\n> rationale behind \"mapping\" was already some time ago: shouldn't we still\n> distinguish hole and data? What will omitting BDRV_BLOCK_ZERO help?\n\nHmm, the commit message is slightly off (in part, because I switched the\nsense of the bool flag between series revisions, but did not properly\nupdate the commit text to match). In mapping mode, we want to return as\nmuch information as possible (the client is something like 'qemu-img\nmap'), including where the holes lie. But when we are NOT in mapping\nmode, we care more about learning which portions of the file are\ndescribed in the current layer of the backing chain, rather than\ndelegating to another layer, regardless of whether the read will see\ndata or zeroes. By the time we are at the POSIX file protocol layer, we\nknow that every byte in the file system/block device has a 1:1 mapping\nto the bytes that the guest will read (we do not delegate to any backing\nfile), so we can simply report the entire remainder of the file as\nallocated without worrying about holes.\n\nHere's where the mapping flag was added and semantics documented (in\nseries 3; whereas the current email is series 4):\nhttps://lists.gnu.org/archive/html/qemu-devel/2017-09/msg03542.html\n\nSo what I really need to do is fix the commit message to read:\n\nIn mapping mode, we must report as much information as possible about\nwhere holes can be found; but when we don't care about mapping, the user\nis more interested in how much of the guest view will come from the\ncurrent layer rather than delegating to some other BDS, and we can take\nthe shortcut that all of the remainder of the file fits that\ndescription, and therefore take a shortcut and skip lseek() for a larger\n*pnum result.\n\n(the same comment probably applies to several other patches in the series)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=eblake@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy2kh55b1z9s4q\n\tfor ;\n\tThu, 21 Sep 2017 00:51:40 +1000 (AEST)","from localhost ([::1]:48607 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dugLi-0003Lu-QT\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 10:51:38 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:47889)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dufM4-0003yP-Qn\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:47:58 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dufM3-0002BI-Jp\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:47:56 -0400","from mx1.redhat.com ([209.132.183.28]:44444)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dufLx-00028I-Am; Wed, 20 Sep 2017 09:47:49 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 57500C0546F0;\n\tWed, 20 Sep 2017 13:47:48 +0000 (UTC)","from [10.10.124.97] (ovpn-124-97.rdu2.redhat.com [10.10.124.97])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 296A960BE6;\n\tWed, 20 Sep 2017 13:47:41 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 57500C0546F0","To":"Fam Zheng ","References":"<20170914144032.14945-1-eblake@redhat.com>\n\t<20170914144032.14945-4-eblake@redhat.com>\n\t<20170920095711.GA4058@lemon.lan>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"<0c239541-da93-33d0-1c0e-88e29de89e2c@redhat.com>","Date":"Wed, 20 Sep 2017 08:47:40 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170920095711.GA4058@lemon.lan>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"vSTdDWMLQ4VUTJHdIiRpk9IcPmKB0vMAl\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.32]);\n\tWed, 20 Sep 2017 13:47:48 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773281,"web_url":"http://patchwork.ozlabs.org/comment/1773281/","msgid":"<20170922055459.GG1397@lemon.lan>","list_archive_url":null,"date":"2017-09-22T05:54:59","subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","submitter":{"id":24872,"url":"http://patchwork.ozlabs.org/api/people/24872/","name":"Fam Zheng","email":"famz@redhat.com"},"content":"On Wed, 09/20 08:47, Eric Blake wrote:\n> On 09/20/2017 04:57 AM, Fam Zheng wrote:\n> > On Thu, 09/14 09:40, Eric Blake wrote:\n> >> We are gradually moving away from sector-based interfaces, towards\n> >> byte-based. Update the file protocol driver accordingly. In mapping\n> >> mode, note that the entire file is reported as allocated, so we can\n> >> take a shortcut and skip lseek().\n> >>\n> >> Signed-off-by: Eric Blake \n> >>\n> \n> >>\n> >> - ret = find_allocation(bs, start, &data, &hole);\n> >> + if (!mapping) {\n> >> + *pnum = bytes;\n> >> + *file = bs;\n> >> + return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID |\n> >> + (offset & BDRV_BLOCK_OFFSET_MASK);\n> >> + }\n> > \n> > I may be missing something, because the last time I tried to understand the\n> > rationale behind \"mapping\" was already some time ago: shouldn't we still\n> > distinguish hole and data? What will omitting BDRV_BLOCK_ZERO help?\n> \n> Hmm, the commit message is slightly off (in part, because I switched the\n> sense of the bool flag between series revisions, but did not properly\n> update the commit text to match). In mapping mode, we want to return as\n> much information as possible (the client is something like 'qemu-img\n> map'), including where the holes lie. But when we are NOT in mapping\n> mode, we care more about learning which portions of the file are\n> described in the current layer of the backing chain, rather than\n> delegating to another layer, regardless of whether the read will see\n> data or zeroes. By the time we are at the POSIX file protocol layer, we\n> know that every byte in the file system/block device has a 1:1 mapping\n> to the bytes that the guest will read (we do not delegate to any backing\n> file), so we can simply report the entire remainder of the file as\n> allocated without worrying about holes.\n\nThanks, it would be good if this explanation can be added to the comment of\n\"mapping\" parameter, so it's easy to understand the actual intention in the\nfuture.\n\n> \n> Here's where the mapping flag was added and semantics documented (in\n> series 3; whereas the current email is series 4):\n> https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg03542.html\n> \n> So what I really need to do is fix the commit message to read:\n> \n> In mapping mode, we must report as much information as possible about\n> where holes can be found; but when we don't care about mapping, the user\n> is more interested in how much of the guest view will come from the\n> current layer rather than delegating to some other BDS, and we can take\n> the shortcut that all of the remainder of the file fits that\n> description, and therefore take a shortcut and skip lseek() for a larger\n> *pnum result.\n> \n> (the same comment probably applies to several other patches in the series)\n> \n\nFam","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=famz@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz2lH0ztnz9s9Y\n\tfor ;\n\tFri, 22 Sep 2017 15:55:39 +1000 (AEST)","from localhost ([::1]:56768 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvGw5-0000Yr-AM\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 01:55:37 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:45277)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvGvf-0000US-Bt\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 01:55:12 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvGve-0007b4-8C\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 01:55:11 -0400","from mx1.redhat.com ([209.132.183.28]:37880)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvGvZ-0007V6-7a; Fri, 22 Sep 2017 01:55:05 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 379C4A0C4F;\n\tFri, 22 Sep 2017 05:55:04 +0000 (UTC)","from localhost (ovpn-12-122.pek2.redhat.com [10.72.12.122])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 51509600CD;\n\tFri, 22 Sep 2017 05:55:01 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 379C4A0C4F","Date":"Fri, 22 Sep 2017 13:54:59 +0800","From":"Fam Zheng ","To":"Eric Blake ","Message-ID":"<20170922055459.GG1397@lemon.lan>","References":"<20170914144032.14945-1-eblake@redhat.com>\n\t<20170914144032.14945-4-eblake@redhat.com>\n\t<20170920095711.GA4058@lemon.lan>\n\t<0c239541-da93-33d0-1c0e-88e29de89e2c@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<0c239541-da93-33d0-1c0e-88e29de89e2c@redhat.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tFri, 22 Sep 2017 05:55:04 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to\n\t.bdrv_co_block_status()","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]