From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a0f216edca-98549d2a-a526-44b9-8593-2fab29f4ed9d-000000@eu-central-1.amazonses.com> Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazon11021142.outbound.protection.outlook.com [52.101.65.142]) by lore.virtuozzo.com (Postfix) with ESMTPS id 20EB6802A5 for ; Wed, 30 Sep 2026 11:33:07 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hFcBykP1H7wAuVL+Vj36Rx5545K1VqPsJ5meFEwnf0eHuYaKZjh7UxM3dDTFfyjaHHovCXG/hpuzYhd0eRWuJKkDAqSpkbvo1bcnAqP5JUWFanRE5ihgOcKn1JSfMR1PIsrr2Rwv8E0KZi7P4jAcwAf7nyCrQOQnvtCUDSX4NC9a90lps9xASMG1x6Kk/HOpXaPcpZb4VZnagnF4t0Ho3ESJUsqF+msmLzRU2hI4/k1a+2MUHY7QwnaphEboWjKaiQFheksG04FZFoCbeUaQPQfuB8ct1Wqy2Zl0OJB+zQqApvRICFYtg86VWUbYM50PfFUoRQEPJ2M2RpurDKvmGA== 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=JAACgYarCNxRdkI8g9NDf/cC8ACEpOSjo4mtJS3p1m4=; b=XPgKqr5Eqr90yjb1MG+ctFeBaaSvWUF9PrNjbhG5mY4F111uBPI0DUgVCOqTQF0NASPV16AbiFpI6XS0siPpoGd30Cu/YGpSc+zv4iI/zAdzwmlYSbTgvaSaBSdwk60DLmI0wUJUjlvIbtdnQnY+Mb7mHNK+3fNqjVc0TcpUDniD8TJJ2QEIaa+UFPLwIqEvJWVIWajD5MdatggEpN8nZi/EYFzyde+eQ6J16nGLNUlTr4S5/+dVdWsTPF2AQZyKMLyVNJbeg+RJbLt0gQLfWUowZmNwTj5tFAQiIuuYX0WSkWBrQykYu38Xiq7iHcKWWjKZDHYFg6JdcOK+k4hggA== 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=JAACgYarCNxRdkI8g9NDf/cC8ACEpOSjo4mtJS3p1m4=; b=Xgp8YypMZjC2l1RC3WvL7ZIPuWR7BHZuckTpjtfODMsrExXPQ31KZmbhfOCEGrmmSSoalHdRpnQC77MLTWwQViDUP1AxtfWH29JAgKxM9MDUNHqI55r+BlqnYmW6nUcEVoDz6IKG353xCSQHpPsTsc6ugbbzcAEraZOiRzA+M6E= Received: from PR3P189CA0001.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::6) by AM7PR08MB5399.eurprd08.prod.outlook.com (2603:10a6:20b:104::22) 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:33:04 +0000 Received: from MI3PEPF0000848B.eurprd02.prod.outlook.com (2603:10a6:102:52:cafe::15) by PR3P189CA0001.outlook.office365.com (2603:10a6:102:52::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.16 via Frontend Transport; Wed, 30 Sep 2026 11:33:04 +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 MI3PEPF0000848B.mail.protection.outlook.com (10.167.240.138) 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:33:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1790767984; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=HHMsr6tXzmO1i0UhWoRNlUU2sOpRcYBzd+gjUpbO38c=; b=M+G8Aq8iKN7Ji+hrLqt46PIUNf2MJl9WQ9JIaMPe83jo0h5Rj+voI0/DleZVlHm+ 9w64vnv03TRhxxT2g/nMxPuf7xZ5j/i/nKVYenysd/bCKg5YlhgtkU1Zzsxvyhd97Ai m0qlnP+51gr971sq3U2KAkrXfoy4dvLdZe7ucP6nlBeLdsPtuyYegeyiaVFYfrG/K0y hjq5tMbh8qKprq5mU708UUQ271r0KanM20CLr4lpB1/qTqrYXdfUGiQzn8SYYRmyyMY +a0rxDSGnBjGxyDVjyKyPU7PBDSTbUUhnBAiLRs7iWrRNHUYsQmWJx26Fhxzas+I4DX H0WEQSzQrQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1790767984; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=HHMsr6tXzmO1i0UhWoRNlUU2sOpRcYBzd+gjUpbO38c=; b=AwZ4q0yxz4nxw5cDK2IZ2/j5AWblKi6cs4VbebfvnRLuKZ3O8tsZ9zAgpODTlacQ phqBCPgJZyXZnKfLiNVClBcuHDTyLG4CecAFp83LBcYq8g7Nyr2yt3pIceJrUXfyt1T PVlyxcjlnmD2stzf+u5c1d/PgV4e3EXxAKTfxdV0= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.0 8/9] block/backup: pre-fill zero_bitmap for full/bitmap #VSTOR-134085 To: "Denis V. Lunev" , svt-core@virtuozzo.com Cc: den@virtuozzo.com, andrey.drobyshev@virtuozzo.com In-Reply-To: <20260930111739.3866427-9-den@openvz.org> References: <20260930111739.3866427-1-den@openvz.org> <20260930111739.3866427-9-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Sep 2026 11:33:04 +0000 Message-ID: <010701a0f216edca-98549d2a-a526-44b9-8593-2fab29f4ed9d-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: MI3PEPF0000848B:EE_|AM7PR08MB5399:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6e6f812a-20d8-434c-df3e-08df1ee697ab 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|61400799027|48200799018|376014|32142699015|10067099003|5063699009|56012099006|4143699003|6133799003|4113699003|5113699003|18002099003|16102099003|22082099003|55112099003; X-Microsoft-Antispam-Message-Info: hBJLBCCXsSvy4a6A4yLd8gpTlASOcEN0Hdez8c8wCrCvYkw8UXl3ykNSqgRB241v0U/Qn0xqSYVdzVkfiJU1hLmbQhKa/c7Z3Qr120p2QcKXnveDdF5zY2aakKQyYVhbT22pPJd6FX7CDWy47uNKQpGw/asuLF0/tqb9ZY2Fi1SDUMK/R63jKcMDB5EudTvLwJoOuwAKI/VuGNY5PCwJHC83wxmrHmy0NAmnb1xVyWQVmEy90CynMp7/w/ov9T4NVswZooELfa1tM5R1gHn5Jln3A60ZOitOYvHkdyFjBG6mIe6ZKgvvq4rp8EtBhkliQsmMTV60qOjFUpwP31252QaQwqxfnAhnHik/C0+t42VGjYXIA3NRHTqrPy1DKbRYe8LlVUEhM2T3isSnS8tc5h415jaxbrAs2BT71EQW62jNAOQvxYv93Euw9QoNerEtC5YlvAI2J9OQcYq1G+3k4EaVDsBAtMkK0byRIOZy2O6B3oA+vcMrAgxG/rakZf3mWj4XD/bWnC8RpuszfTN1gVxXuCFp37JAAyxtyHOD/MrMkM1zuPPpNPagVD6drsGyrhyVIBp18buxIJIjDtIdQay43PthLkMm0A8JtZebXPln/6qn7j7I9WIzcK3pq7xHyLeW3c+1jGlBeUi7JdpsuWzMSzf5CUp0MnqFtdOxOmLsqR7V3iXB0OKuxm46hwFNesVOjm2lU0wba5vtguK8MRtcIBZPKAZ4znyjRJI+/QzaO8jwVbhoD32vD78gEs9joNLfHsLk7MRTax+N5E8alvlztET5TvD2lVHAh80vjbedFWiZ4BLhqH4bjlsMjU8rj9Xsgqf2WAreV7DHUW3Bfg== 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)(61400799027)(48200799018)(376014)(32142699015)(10067099003)(5063699009)(56012099006)(4143699003)(6133799003)(4113699003)(5113699003)(18002099003)(16102099003)(22082099003)(55112099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tKaAQLyxM6oHZ28SRoZ78FC9egFDhqV+gqRG26kLxsxQuDyz78PpyK6Ai/8yi15/G5r3fPr/rzi0AsXRS7P0GOlY3/p5RJPUpiu3qhZEbpc8kK/ysQGm9oG60RBUgx4ulfGkwcthCM9vw5XfotHyNHE+ARvpZyh0k7RRhAMba6q7WlmYrnBuxXCB2gH3DLSbouG1StvWdNn/QLYc1rHPlcFLhZvWIiBelDqKbsRVp+NdBrpYKhEg7CKmLwEZUnV3/+OriWBXwRhNevVEhipR89RTEvgVKrWOVgvkJPwo/TORJpBogNOQ6dYZqk6240+WX0iPvYJs92/xNsmUgjwnc1vc0ykgG9kS01uS8AMDhw2tP4eGjJykLFs1Cnd/FeME38+ljZVaAAhl1SddOwLVGf4d+BDJxjlM/uZRMLswz9VDQHxH6cOtWFUvhHMSVrjh X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2026 11:33:04.5176 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e6f812a-20d8-434c-df3e-08df1ee697ab X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF0000848B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5399 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] block: block_copy_calculate_zero_bitmap() can return count 0 for= ever, hanging the scan - [Low] block/backup: commit message says full/bitmap but only sync=3Dbitma= p uses the new scan -- commit 252a85c484652c4a95f8a77f49b08e8150b81585 Author: Denis V. Lunev block/backup: pre-fill zero_bitmap for full/bitmap #VSTOR-134085 This commit adds block_copy_calculate_zero_bitmap() and folds the up-front source scan into a new backup_scan_source(). The scan now pre-fills zero_bitmap for sync=3Dbitmap as well as sync=3Dtop. sync=3Dfull stays on block_copy_reset_unallocated(), and sync=3Dnone keeps the per-task query. > block/backup: pre-fill zero_bitmap for full/bitmap #VSTOR-134085 This isn't a code bug, but the subject line and body say that both FULL and BITMAP get the new up-front scan. Two quoted portions of the commit message read this way: "Add block_copy_calculate_zero_bitmap(), driven one query at a time from backup_scan_source() ..." "FULL and BITMAP know their complete copy_bitmap before copying starts" In the code, sync=3Dfull still takes the block_copy_reset_unallocated() path, and only sync=3Dbitmap calls block_copy_calculate_zero_bitmap(). The trailing paragraph of the message says so itself: "sync=3Dfull already runs block_copy_reset_unallocated() ... so it stays on that path and only sync=3Dbitmap moves to block_copy_calculate_zero_bitmap()". That leaves the message contradicting itself. It also carries the downstream "hci-8.0:" tag. Could the subject and body be reworded to match the code? [Severity: Low] > diff --git a/block/backup.c b/block/backup.c > --- a/block/backup.c > +++ b/block/backup.c [ ... ] > +static int coroutine_fn backup_scan_source(BackupBlockJob *s) > { [ ... ] > + for (offset =3D 0; offset < s->len; offset +=3D count) { > + if (job_is_cancelled(job)) { > + return -ECANCELED; > + } > + > + job_pause_point(job); [ ... ] > + bdrv_graph_co_rdlock(); > + if (skip) { > + ret =3D block_copy_reset_unallocated(s->bcs, offset, &count); > + } else { > + block_copy_calculate_zero_bitmap(s->bcs, offset, &cached_end, > + &count); > + } > + bdrv_graph_co_rdunlock(); > diff --git a/block/block-copy.c b/block/block-copy.c > --- a/block/block-copy.c > +++ b/block/block-copy.c [ ... ] > + if (*cached_end < dirty_end) { > + int64_t clusters; > + int64_t query_offset =3D MAX(dirty_offset, *cached_end); > + int ret =3D block_copy_is_cluster_allocated(s, query_offset, &cl= usters); > + > + if (ret >=3D 0) { > + *cached_end =3D query_offset + clusters * s->cluster_size; > + } else { > + /* Best-effort: leave this area unmarked; it copies as data.= */ > + *cached_end =3D dirty_end; > + } > + } > + > + /* 0 if the query above didn't yet reach dirty_end: try again next c= all. */ > + *count =3D *cached_end >=3D dirty_end ? dirty_end - offset : 0; > +} Can block_copy_calculate_zero_bitmap() return *count =3D=3D 0 forever for sync=3Dbitmap? block_copy_is_cluster_allocated() sets *pnum =3D DIV_ROUND_UP(total_count, cluster_size). That is 0 when bdrv_co_block_status_above() returns count =3D=3D 0, for example at or beyond the source EOF. The function still returns ret >=3D 0 in that case, since it has an explicit "count =3D=3D 0" branch. If that happens, the ret >=3D 0 branch above sets *cached_end =3D query_offset + 0 * s->cluster_size; which is still below dirty_end. *count then stays 0. In backup_scan_source(), "offset +=3D count" does not advance, so the next iteration repeats the identical query. job_pause_point() and job_is_cancelled() do not yield unless the job is paused or cancelled. That would leave the scan spinning without yielding in the job's AioContext. I could not confirm that s->len can exceed the real source length, for example if the source shrinks during the job, so this may be hard to reach. The same "offset +=3D count" shape already exists in block_copy_reset_unallocated() for top/full. However, the sync=3Dbitmap path through block_copy_calculate_zero_bitmap() is new with this patch. The later patch "block/block-copy: coalesce write-zeroes tasks" does not touch this scan. Would it make sense to force progress, for example by treating clusters =3D=3D 0 like the error path (cached_end =3D dirty_end), or by clamping clusters to at least 1? [Severity: Medium] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026093011173= 9.3866427-1-den@openvz.org?part=3D8