From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a0f2143ac3-3fa0c1b0-7316-4aff-8e1f-f09bb323a349-000000@eu-central-1.amazonses.com> Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023076.outbound.protection.outlook.com [40.107.162.76]) by lore.virtuozzo.com (Postfix) with ESMTPS id 294308017D for ; Wed, 30 Sep 2026 11:30:10 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KvbRHeu/0syoEBgnX+vAQ9PlJGH46iKR2HdOX1HKPOmOiECMpxvFMIrvpCnPcqfg1f8SiB4D73ZVrwvbbQ6vVeHjRSOkraAW9M8HCjP3uDA+kFrOzGFG38mhBHN0Wf+BqaVo++s4zBlXn/2CxsEjedisipFLl9zKvjOtB98UoQH3QY7NTbNbUMGmnmL5QijfqNRRfW1PTRkq68jmnDNNnDcICpsrULRaSlikoh6ilOkaLJB8vUqumkxN+LJgBUeYd6k+ZvrGE53Eq/7zDkAOsZPnn54S22tXbjQpRa2Bj9UxTvORoH8WsyTJA06u+zckvrVvbdMaBIomicHaojHdsw== 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=c5FB67LS7R4opk8mvXH1q6vtCUswfRofdj9aFosPHcs=; b=hBzraxZm+XxIj+Ctq8rJwx/PyJp/zM4I9O+3mfr8oPmLWdrUDdNEfQCqeGT53mzpSKylRN2fBwv1hp0mNuoiLaPWZ8BDDEtyLgxUg1sDKWSebeG6EUEb0+O7zv1JQrX1P+Va89kkNcJ7f6v7RaH5h0qsN0+PKsBGpmASVymzrOZeiXNHrCy+n4MJe1Qsg8ZxNdLaXdUsHZRCMouG+r8NpXsojleeHE/+yNGGztO3UniZwH4dez6thHMwve2goOuREUXsKJOAHOytwJwwMdC+r99V8jTenZxM/FUSf1WjwpcSanwTX0lmtwIWp00VnLrdOPUeTwhqM5pDRu3290vr6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) 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=c5FB67LS7R4opk8mvXH1q6vtCUswfRofdj9aFosPHcs=; b=X1goo3YR/JWqL87cC83UKjUuhQACov3ZfiOg3TSGCim4ECCwzPScsnEQ86ncALDfUXTcyYGO+jX4ozIcUCektMLYHFUSvwr9UFPaMZCziZy/gp4W9Ak4QSK0CncO8nEzd2tN20/QkBWx9flqPO/YVa4ACE36HvYRnLetXVFXzLM= Received: from PAZP264CA0085.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fa::8) by DB9PR08MB8266.eurprd08.prod.outlook.com (2603:10a6:10:3c6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.9; Wed, 30 Sep 2026 11:30:08 +0000 Received: from ZR1PEPF0000E461.eurprd04.prod.outlook.com (2603:10a6:102:1fa:cafe::4d) by PAZP264CA0085.outlook.office365.com (2603:10a6:102:1fa::8) 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:30:07 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) 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.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by ZR1PEPF0000E461.mail.protection.outlook.com (10.167.241.59) 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:30:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1790767807; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=xb3rKyGMWLrfSOCuDi55zsPpNiSPVZinBaDQxACIetY=; b=yBPh71aFM8+CTtkcEmbvi2tBtLdN9mtz2/P9h7IQDP8rF4CfKQgQGBlNLafLhVkt TYey+xDklEd2gmaQuexLgQpovca+oExy/vpcbc9QygJCw3N3qWd0fHX5+hOfuYivkQL fjEGmHL9mYS9+v2cEXJ4RS/MRI1vSbRB3rFQslSDyCMzQSYE877NaAgrxRDsrU9jVv+ hP3AdwtAGg2tiaksDBKt9ysKasIwtrrMowmMEKOfNHcm9SMaACjao6JKDtg/o0SvWTY Th8mvBewpDNB0yc7s/zbv/vSfgMrhxKNiHjLXqyPLXVYZMBIIEvOGmbzNGA/UBANhO8 WWEmoIubDg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1790767807; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=xb3rKyGMWLrfSOCuDi55zsPpNiSPVZinBaDQxACIetY=; b=kISIdoXFeNqIOGEqO1AzpGGvcWmPkiqRn9SqXwAjB2a3SPaKcZ2f6yvWLCTjkWcy qpGdi8HT45eMHrwUXUgpNVz00yWZQ55XVf8XX0w5aR2uBQGlsyz/QHm15jJ7ecGRK5S PgV6+Cw13lDn69gWJYq5KdUo6prHWlxZ75wS39Zc= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.0 7/9] block/block-copy: track known-zero source clusters #VSTOR-134085 To: svt-core@virtuozzo.com, "Denis V. Lunev" Cc: den@virtuozzo.com, andrey.drobyshev@virtuozzo.com In-Reply-To: <20260930111739.3866427-8-den@openvz.org> References: <20260930111739.3866427-1-den@openvz.org> <20260930111739.3866427-8-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Sep 2026 11:30:07 +0000 Message-ID: <010701a0f2143ac3-3fa0c1b0-7316-4aff-8e1f-f09bb323a349-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.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: ZR1PEPF0000E461:EE_|DB9PR08MB8266:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 53267ff0-2342-44b1-f735-08df1ee62e3b 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|9140799003|32142699015|48200799018|376014|61400799027|18002099003|22082099003|16102099003|55112099003|4143699003|10067099003|5063699009|56012099006|5023799004|5113699003|4113699003|6133799003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?T1lwUkk4V0wwVjNJT25HUmFGdlYrbWFoYlNmQkx4Q2NjYUdtbTZyQ0dqenpo?= =?utf-8?B?SjRPNmZJblp2cUF6RGVuTDd4QVFtMzNtY2o1aURxbFdkSTY1b05xd1cvZGJr?= =?utf-8?B?OFdaK2E0Uys1eFVYS3owMk8rbXpUOUpzNjhucUdab1VWdU82bjcwdGFNdU4v?= =?utf-8?B?QTBVa3FtdEhLMHZERGdjTTU0NmNLK2pKd1RyN2N5Q3ppUnYwNkRyUysvVGlD?= =?utf-8?B?dXJ1K3djNUNLSXljN2VDclREcUFEVkx6OFpsWEtwb2RqUjdZcjdYRmY2Q2Rp?= =?utf-8?B?ckpxcE5hUWloc3A2aFJqZ25iMExWZEs2cmVQWDNyUVJ4OWhsQjZ1ZjdkNW1J?= =?utf-8?B?OW9BVXFtTGd3QVVkVzN2ekhPcTRaZWF1M3lkaCs4SXR2dXlTbEdWb3VjV2hx?= =?utf-8?B?R2JVNHR6V0haQjJWNndiZVpqK082NkYrblhENlB6S0RFYTd5SlJqTE5FRitq?= =?utf-8?B?L1ZYeVh0SVZWd2JmTjFtZWJ2WFNTVVdyLys1cWxmY3Uzc01xUlV0bS9JNTVB?= =?utf-8?B?ZEJkN0dRMFhFUlV0TU5xVVNkWWZhdkk2dVpIZzE5ZnRtcjI4MkEwS01pTml5?= =?utf-8?B?ZGdMUEc5d003bURkM0MvR21HaStNMWthb2JXaENVMzQ5K05DQm4xMUF3VElK?= =?utf-8?B?VXdDRjdzZmp3OTJPbDBhdmVkNlhBSFpJTWIwbTF0eVdMYlU2c1kvSENINlhG?= =?utf-8?B?ME5pUW1RUnBaRklTV2Npc0lyRVc4ZHI4clg3enZwaC9PaEtzMkx3MzFraVcw?= =?utf-8?B?c0RDS1BJN1lSQ2RkNTA2SUFBRTM3T0FUUXc3RmJWMkNPNUhDWW9LZHlEc09L?= =?utf-8?B?RHlMaXpidWNuY3RkUmdXeEdSWjlDUDZtVHdjMHJUMFo1TmtoNEhRMG1pdHEw?= =?utf-8?B?dWNBNUx1RVRjdXdRUHJyYTNjV3VaanVMdEx1Y0k0bGtoaDE1QzVrTXp5K3ZL?= =?utf-8?B?RzFaYjJFVVZKRVk4MjVpRHI0SzcvcWFFUkFKNEtZcGk2ODJUUHVQbkpneHU2?= =?utf-8?B?U00yOS9lNEY1WGVRL3MzcThwdDNqb1B0VWhNb1RieE9rMm5LSzhvS1ZYN3BY?= =?utf-8?B?VWVMQi8yYTJRNFVVV3VQSHFsMHplZDQyMXlUVXpKd1Fpajl0dWtCUlZxaXky?= =?utf-8?B?TEdyYWdhLzFDbG1zQkpMb1RYVWtDQ2NlbEFVNjBPMlZwcFF4ZUxFSjZ2dVFp?= =?utf-8?B?cmJMVzE4M2ttSDlRbktMaytzZVQ0eC92TXRhNlFrNnQ5ZzBIUlc4QlNCUk53?= =?utf-8?B?VE00Vm4xMjNCcnhHN1djdFFYUlQyZVNNZlpwb2xrc29lWEFzQT09?= X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(9140799003)(32142699015)(48200799018)(376014)(61400799027)(18002099003)(22082099003)(16102099003)(55112099003)(4143699003)(10067099003)(5063699009)(56012099006)(5023799004)(5113699003)(4113699003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: SFfIDCDntmRTRpZ2b/m3y/hBnqqysQf1r+Ie//Kj6JrylXDg1Ne4oLFGDMUJm++wON35REm/I9io07aT7ycjRsMrMoxuUWwPO/lbk5gRykX8gDnlejLu1602NAr7z6jRIjE5u7qfvgLSKemBfnj35plL7pGJe/zWtLCX3wx+NrMeF0tlViy07da/9pD2wDhV2/9pCVgT7O9EORXKFGa0xaPmDb27JmfCcWGv8RaL5PXedAH9XkBl5yV0b/Q3gjJs+wTItbSJ8M2QHPkh8/IZvluy5XQdecnTwBEu3qmezO7yM1twCNo1n32HaAJLwebx5FSzR7VV5yRV8X/4Q6aj4HBvT9i9zkcPug+zQ1oz7132UuRtbCZNGSS2EQ5oW0ZykmiqahOln3p+I4mAFH6p56y+9C/4m6qWwkWb+RH+uo17aJVjKoV+Vz6oIPVY7sSB X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2026 11:30:07.6272 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 53267ff0-2342-44b1-f735-08df1ee62e3b X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: ZR1PEPF0000E461.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8266 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Low] block-copy: ctz32() on 64-bit cluster_size gives wrong zero_bitmap = granularity - [Low] block-copy: unaligned EOF tail cluster never marked zero in zero_bi= tmap - [Low] block-copy: skip_unallocated doc stale; early return relies on impl= icit complete-scan invariant -- commit 00cb83b3deb7d878b4202ae80e855cacc98ffc19 Author: Denis V. Lunev block/block-copy: track known-zero source clusters #VSTOR-134085 This patch caches the source's zero-ness in a new zero_bitmap, filled by the block_copy_reset_unallocated() scan. The bitmap is published through zero_bitmap_valid once the scan is done. After that, block_copy_task_create() picks the copy method from the bitmap and ends each task where the answer changes. > diff --git a/block/block-copy.c b/block/block-copy.c > --- a/block/block-copy.c > +++ b/block/block-copy.c [ ... ] > @@ -688,50 +722,79 @@ int block_copy_block_status(BlockCopyState *s, int6= 4_t offset, int64_t bytes, > return ret; > } > =20 > +/* Only the scan allocates, and it runs before zero_bitmap_valid. */ > +static HBitmap *block_copy_zero_bitmap(BlockCopyState *s) > +{ > + if (!s->zero_bitmap) { > + s->zero_bitmap =3D hbitmap_alloc(s->len, ctz32(s->cluster_size)); [Severity: Low] Is ctz32() the right helper here? s->cluster_size is an int64_t, and block_copy_state_new() accepts any power-of-two min_cluster_size up to INT64_MAX. For a cluster_size of 2^33 or more, the low 32 bits are zero. In that case ctz32() returns 32, so hbitmap_alloc() gets granularity 32. The zero_bitmap then describes different cluster boundaries than copy_bitmap. Those boundaries would feed hbitmap_get() and hbitmap_next_zero() in block_copy_task_create(). Would ctz64() be more appropriate? This only matters for a very large x-perf min-cluster-size, so it may be a niche case. > + } > + > + return s->zero_bitmap; > +} > + > +static void block_copy_mark_zero_prefix(BlockCopyState *s, int64_t offse= t, > + int64_t zero_count) > +{ > + int64_t zero_bytes =3D QEMU_ALIGN_DOWN(zero_count, s->cluster_size); > + > + if (zero_bytes > 0) { > + hbitmap_set(block_copy_zero_bitmap(s), offset, zero_bytes); > + } > +} [Severity: Low] When s->len is not a multiple of cluster_size and the tail reads as zero, QEMU_ALIGN_DOWN(zero_count, s->cluster_size) drops the tail cluster. Is that intended? The old per-task path went through block_copy_block_status(). It aligned the final chunk up to a full cluster and could return BDRV_BLOCK_ZERO for it. Once zero_bitmap_valid is set, block_copy_set_task_method() returns early and never re-queries. The tail is then read and written as data instead of using COPY_WRITE_ZEROES. This is only a missed optimization of one cluster-sized copy per job. [ ... ] > @@ -791,6 +854,12 @@ block_copy_set_task_method(BlockCopyState *s, BlockC= opyTask *task) > int ret; > int64_t status_bytes; > =20 > + /* block_copy_task_create() already decided, from zero_bitmap. */ > + if (qatomic_load_acquire(&s->zero_bitmap_valid)) { > + return true; > + } [Severity: Low] This isn't a bug, but the early return skips the skip_unallocated check and the block_copy_task_shrink() call. That is correct only because backup_run() sets the flag after the full scan. The scan has already cleared every unallocated cluster from copy_bitmap. The comment on BlockCopyState.skip_unallocated still says: * In this case, block_copy() will query the source's allocation status, * skip unallocated regions, clear them in the copy_bitmap, and invoke * block_copy_reset_unallocated() every time it does. That comment was not updated for the zero_bitmap short-circuit. Should the complete-scan requirement be documented on block_copy_set_zero_bitmap_valid(), or asserted? Otherwise a later caller could publish the flag without a full scan. Unallocated clusters would then be copied silently. > + > + /* CBW filter could call this early. */ > ret =3D block_copy_block_status(s, task->req.offset, task->req.bytes, > &status_bytes); --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026093011173= 9.3866427-1-den@openvz.org?part=3D7