From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a0f2182956-3678f203-5ee4-483f-96ab-e5b6b1128101-000000@eu-central-1.amazonses.com> Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11020114.outbound.protection.outlook.com [52.101.69.114]) by lore.virtuozzo.com (Postfix) with ESMTPS id 813688017D for ; Wed, 30 Sep 2026 11:34:29 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pOcprmo5VxWH/iQAgm7PxlaWpRi9hSjqzLoxgxRDftcVUVY7uXzj79w+BLhEfHpjtQ33Zs5FyTdJ8l6+Y8yzAsWQM/4yKNGCe1MKL28v6TQSQxnpmiMk7PvdpHUIpfNP/p4S8UOqFWEu2dsp9rlksydwuaf8ebBvcuX79UMskzaQonGd2HedmwF/YFyLuTcd+1diGjVGHDQ4cUXJmQcQWBw4HfR8xUSiwDeDYguTpOO6dML7LwZfDr0htzcuOC2fzcRx8+wTowBnxc5M4NyAHCxhbBE611TrZ7qk+oxgJJYxdxh5GGSWb73aps35FpPd/h0IotvVhRRy96twu/KVew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yCnaRMlffYjRMnlpY+D6sJLA9zBT3QeCv1zw7puDE94=; b=NMh5tEcV4JUDSqh+j/mLZ3xwHdrsF0WZTpOXqhOSw+/MPOzdG21ILPdmEBOIvxUIl3Tc3RXYAqWXlHMv24MsTbNUk5TZo3aElWGdR+TX0IqW1eV2q1kuKzsOMeT+w8rx07BZTIA+/VVznu4lADRSjB0NRfef5tBXKljx/Sry8i+GscrY/TAJcch/RJHsFzEF4fhruTwOzz7Gl1Oq1L+BmC9TVLYwUgugmWh4fm6vaDWKneOLXmkDjvU19jWN9IE3iyehAffF67ITWgOYyZLjwU52nuGPMjdsu6I7XtAGyXX5lXPwqZ8Kv0C8xi888XkYWy3xwGfMHwIhhmUvrxEJVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.6) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yCnaRMlffYjRMnlpY+D6sJLA9zBT3QeCv1zw7puDE94=; b=fcSZNfSKiePXrSL+YZWX3XyjKNh9BQvJOxvRmGM+Ck6PP/oEm8FXgweAULQ9KzxVa5OGNIi9RPQKBNlQjSno8JJZPntqFXDCUuSg/GaHNYxYlbb26XXXdssShNfnWrgvGE2C28pqGcwQr2eBb0e5oDtwl727YUAFzXCrh11fNwk= Received: from DB8PR06CA0066.eurprd06.prod.outlook.com (2603:10a6:10:120::40) by ZR6PR08MB235482.eurprd08.prod.outlook.com (2603:10a6:910:e7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Wed, 30 Sep 2026 11:34:26 +0000 Received: from MA3PEPF0000040A.eurprd04.prod.outlook.com (2603:10a6:10:120:cafe::52) by DB8PR06CA0066.outlook.office365.com (2603:10a6:10:120::40) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.15 via Frontend Transport; Wed, 30 Sep 2026 11:34:25 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.6) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.6 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.6; helo=b224-6.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-6.smtp-out.eu-central-1.amazonses.com (69.169.224.6) by MA3PEPF0000040A.mail.protection.outlook.com (10.167.241.155) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Wed, 30 Sep 2026 11:34:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1790768065; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=kw/YrMD/8i6NYPRbInrKrsVp/l6YIfjcHPlvoncI19g=; b=BrYfaoq1icK7nQjWa4MpXLbHcomO1rNRPJQMx0uYzXs/kPYCCN3C5MGY6SkY8/cE 0pFY5Zue92/k7h0OEV3JSY6xPZBFx48Gq2Jndz/0yvShFy+GDD+Hjgt7Ny+3M/27pcH gQdWvjqVjWavMcXLZMcZvQKNAzRZ5g8yd+YacSFZ6L9qHLAi5vLcYcSQuM2Eu/6hhTA 3HpsbE1kLZ+/LmLzvLlDx6Ejb2QtDKnAGGVBZOqDUcsYs1QQnioFC/KaV/0YFJnR4Wo CiVO3NhgdY7AclK1SVT7q9EHkkIN3yshnyLQ+jVgRJcfjKhp/p2oL9PqZHyW5te1kAE h+RiyCIXlw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1790768065; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=kw/YrMD/8i6NYPRbInrKrsVp/l6YIfjcHPlvoncI19g=; b=Gh2MyqRBd2Hpn75/3o5GF8AN3KkOJFYMAAnrCbW/p3+4fkgU5xGDvyg9yO11YnEX 4i1V6Kj0yIJrqSsUuDWxi1unZLuCLof88VoACP6ySkTImZctoA/4gwLptPsHZ1q63m4 O692MMLNMfvRAHql786arfiEegdZK6RMnLuMtZXo= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.0 9/9] block/block-copy: coalesce write-zeroes tasks #VSTOR-134085 To: "Denis V. Lunev" , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com, den@virtuozzo.com In-Reply-To: <20260930111739.3866427-10-den@openvz.org> References: <20260930111739.3866427-1-den@openvz.org> <20260930111739.3866427-10-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Sep 2026 11:34:24 +0000 Message-ID: <010701a0f2182956-3678f203-5ee4-483f-96ab-e5b6b1128101-000000@eu-central-1.amazonses.com> Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.09.30-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MA3PEPF0000040A:EE_|ZR6PR08MB235482:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e3dfa45f-6ee7-4d6e-f107-08df1ee6c7ea X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|48200799018|32142699015|9140799003|61400799027|13003099007|18002099003|16102099003|22082099003|55112099003|5113699003|4113699003|10067099003|4143699003|5063699009|56012099006; X-Microsoft-Antispam-Message-Info: AOpPhAHP1llMWUXui9y7+0+VRAKajEnrp8OaHK8T3EANj7l+ErW5fO2mcx3xslWXq1pp9FLoHp0Yj/J9f3TmT47/Vf8aVPsdMX9vUlpmoWt8PiTaWtsfYyBwWq91qn/q7CdEwg+IaOt/JPm9Rw7biLRyDWMYO2XqpReu6uyBmW7R5ahxXFYsQSw0n2fHF2i/4S3tQUkpp4QXNT8CyB19gv5lpBhcauRB+b/7XMAe77zPAwXzcV2lCDwJ9aUsj2qtcjzTDO1HeWKMcv16+4XFnpBDCRVSaazGV/NKL59AG07c6E0Qjr+HQ0jDc1hn1R431C2R6+axQD7OTQ5ohH2V2zcnnMVqYeJ8/UBhUBjCHPOOUQC9zL+EzzN6Y2kpOTMDZRj+RBJaI6AEwjjXWEeAD0j3VSwPITm9tfWBS1YA+gRTlJ6SWqou1zv+2dBvWK8vYlbTYYkgp92JQh5UZUbIliJ4G8NzEOtyED0ra2C/wRDtwZIqw8H8Z+u6QdGs3TNBKiIrfkl8ZIPfZKF8Mvu6sXx6BrT0AH4jvZnhqnwdLsDOSz09FB5OK9KG6vpPidMJ6qfkICJzXucct0n+GjpwbQ4AuIYh8ely/k8bGBKhdrIhFpzcF5/wHOQWmXDvxWDY7Uk9WcHr2FWWuoFyA3gumVX4lzgrTYjcpEtPvtJjlcOazYNRYASlDVsrLY45tjkv451fcsTYnhFl/Ip6xaUTWavJ/Ng/HxuheNiRbxxtH9vfzqs5WU1DfJaL/51b4m9lsgPBUYL6EP2d9zLbP+isVWZYWMJvfS5yt8sAD3Dv+nlP+XslP2eAoQkg2h9extHK/Ug6euF3zOIr3k9xuSVx5FI5K+uxN+6S0zIuNDMYsTE= X-Forefront-Antispam-Report: CIP:69.169.224.6;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-6.smtp-out.eu-central-1.amazonses.com;PTR:b224-6.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(376014)(48200799018)(32142699015)(9140799003)(61400799027)(13003099007)(18002099003)(16102099003)(22082099003)(55112099003)(5113699003)(4113699003)(10067099003)(4143699003)(5063699009)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ck/tEhg0QFf9H2Hn+y37TR659+jEwnH+Nd/XPFkT1LKypuZQ2k+7aJIa7qpuzxJftj0w7xZYHf94y6Cf8IY2vUtmPxlEtz5uivzLzh9vR2kvt3N5Ly5XGtyCdTGY2Z3rHFzFBrVqHhtfYIRHZrk9gN/OG2RHB/NoRsb82Cw5JGteU35yOn87CkMj8MEhvCmZALjLRlkyN8quwJaD6gHLPON34mmstnRvXf9m/KaRRHGhMr5YlufEjMXddExKRbiY02YgCrjDDKEtJdngiy1FqDV1amMFrp3taar0d8TPT4t9SsPlHBUzxzbIT/HUyI3GZbHZeHh9/arcLKFAtlnQEsYtOduVWGIoBxysyENutuj2RfJGYl8nS8hiYiG1DcBYaeoSEVFOD5WLcTgLD3624H46gGwrxp63PUFAHQJRZ/7Vs0wM/ZU1gkUhlt2tUcSQ X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2026 11:34:25.4350 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e3dfa45f-6ee7-4d6e-f107-08df1ee6c7ea X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MA3PEPF0000040A.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR08MB235482 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] block-copy: widened write-zeroes task blocks overlapping writers= and rate limit for ~2 GiB - [Low] block-copy: write_zeroes_fail trace reports advanced offset in chun= ked fallback -- commit f1b3fcf0ac0c96a51feac391dbd24c727baced51 Author: Denis V. Lunev block/block-copy: coalesce write-zeroes tasks #VSTOR-134085 This patch lets a write-zeroes task in block-copy grow to about BDRV_REQUEST_MAX_BYTES instead of being capped at block_copy_chunk_size(). It adds block_copy_widen_zero_area() and a new block_copy_write_zeroes(). The new function first asks the target for BDRV_REQ_NO_FALLBACK and falls back to chunked writes on -ENOTSUP. The patch also caps the chunk size in qemu-iotests 056. > diff --git a/block/block-copy.c b/block/block-copy.c > --- a/block/block-copy.c > +++ b/block/block-copy.c [ ... ] > +static int64_t block_copy_widen_zero_area(BlockCopyState *s, > + BlockCopyCallState *call_state, > + int64_t offset, int64_t search= _end, > + int64_t bytes) > +{ > + int64_t aligned =3D QEMU_ALIGN_DOWN(BDRV_REQUEST_MAX_BYTES, > + s->cluster_size); > + int64_t zero_chunk =3D MIN_NON_ZERO(MAX(aligned, s->cluster_size), > + call_state->max_chunk); [Severity: Medium] Can one widened task now hold its BlockReq for too long? With this limit, block_copy_task_create() can register a single BlockReq of up to about 2 GiB through reqlist_init_req(). A copy-before-write guest write that overlaps the range waits in reqlist_wait_one() until one bdrv_co_pwrite_zeroes() of that whole size completes. The job rate limit only charges a task after it has run. Pause and cancel also take effect only between tasks, so they wait for the whole request too. The only mitigation left is the existing max-chunk option. The commit message admits this effect for test 056, but the limit is changed for all users. Is there a reason not to bound the task size by something smaller by default? [ ... ] > +static int coroutine_fn GRAPH_RDLOCK > +block_copy_write_zeroes(BlockCopyState *s, int64_t offset, int64_t bytes, > + bool *error_is_read) > +{ > + BdrvRequestFlags flags =3D s->write_flags & ~BDRV_REQ_WRITE_COMPRESS= ED; > + int64_t chunk; > + int ret =3D 0; > + > + if (qatomic_read(&s->zero_widen)) { > + ret =3D bdrv_co_pwrite_zeroes(s->target, offset, bytes, > + flags | BDRV_REQ_NO_FALLBACK); > + if (ret !=3D -ENOTSUP) { > + goto out; > + } [Severity: Medium] Is this a problem for slow targets? The first request covers the whole widened range in one call. If the target refuses the fast path, for example file-posix on a failing fallocate, the range is then rewritten in chunks by the while loop below. Overlapping writers stay blocked on the task's BlockReq during both passes. NO_FALLBACK is also only optimistic, as the commit message says, so slow zeroing paths such as a block device or a network filesystem can still be reached. [ ... ] > + offset +=3D n; > + bytes -=3D n; > + } > + > +out: > + if (ret < 0) { > + trace_block_copy_write_zeroes_fail(s, offset, ret); [Severity: Low] This isn't a bug, but the offset passed to trace_block_copy_write_zeroes_fa= il() differs between paths. In the chunked fallback loop, offset is advanced by n after each successful chunk. If a later chunk fails, the trace reports the advanced offset. If the NO_FALLBACK request fails, it reports the task start. The old code always reported the task offset. Would it be better to report the same value on both paths, for example by using a separate variable for the loop position? [ ... ] > diff --git a/tests/qemu-iotests/056 b/tests/qemu-iotests/056 > --- a/tests/qemu-iotests/056 > +++ b/tests/qemu-iotests/056 [ ... ] > @@ -117,7 +117,8 @@ class TestCopyBeforeWrite(iotests.QMPTestCase): > self.vm.pause_drive("drive0") > self.vm.cmd('drive-backup', device=3D'drive0', > sync=3D'full', target=3Dtarget_img, > - format=3D"file", speed=3D1) > + format=3D"file", speed=3D1, > + x_perf=3D{'max-chunk': 65536}) [Severity: Medium] The test has to cap the chunk size by hand to keep the job rate-limited. Does this show that the throttling behavior changed for real users, with the workaround applied only in the test? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026093011173= 9.3866427-1-den@openvz.org?part=3D9