From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id C15B380E7E for ; Mon, 9 Nov 2026 12:43:13 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A9CfrXE031767; Mon, 9 Nov 2026 15:41:54 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A9CfrXE031767 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="fsFIW78T" Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A9CfooV031763 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Mon, 9 Nov 2026 15:41:51 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A9CfooV031763 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-8aa185840bdso665509b3a.3 for ; Mon, 09 Nov 2026 04:41:51 -0800 (PST) X-Gm-Message-State: APuU4Z/MEjDNHnHbLCNfd3fK3tFEqqpz2CqEadKEIFZ/iKlRHt/wc6n2 Osi2oiJnD+0FVXbAdACJ6jef9bziktbGoWyRPqBxBnDjq4aEzwAB9SgD1aJZYX2tz1TAy23kiNQ 20mU4oI0Jzbwa/nPhP+viOq4J06rBBYMr/evj0YPLv3R6zhA5Zteyuw== X-Gm-Gg: AYBFou2kfT6DDizgtySVm0hvgrrVyU8JfAmXN6YqmdNGkA2+cC7fXPsvuhZ1oHDr+fo wJvBn2y0HYsch8Rc4rCyvdUIvLV0XiWKrUYf7OiWg5jwT5Pe2sXM42h1OCldPSsgzlDIp+l95IG eQhDMfuujQ/yujkiZ2p3bw5F6jZlrQQuW2Rj2/W35/78J+s5GlDcboqAC6q4cu7qa0NeRV0/7Qh 8Qv5d2QOXIKhODauHMs42wRG+6zR4UD5w5csETS87YZy0YDFMMY+5IsshHbHWNaYYUEx/O34gVa 6vakDvxmUJQ8hrVQXLAWeyhRYgV9BUsspYrFThDfgQbuAf1p6q9cIg6rWOOzLCIHeD59RGDVp9H aFaIR7O7Y48o/1jCgqDmm0PAa5fVUjUFij7ZuOnTWhDft+o4oJ+mihy4AiVwnsL2z2wmXOjMr0G YxKl4KTRQKLiX1b1WnTa8C7sb5wXXX2dKx X-Received: by 2002:a05:6a00:339a:b0:882:bba:8791 with SMTP id d2e1a72fcca58-8b66d67f699mr3224289b3a.34.1794228109976; Mon, 09 Nov 2026 04:41:49 -0800 (PST) X-Received: by 2002:a05:6a00:339a:b0:882:bba:8791 with SMTP id d2e1a72fcca58-8b66d67f699mr3224268b3a.34.1794228109391; Mon, 09 Nov 2026 04:41:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1794228109; cv=pass; d=google.com; s=arc-20260327; b=AXuoZpOaJ+Ow5wzB4Et0W6MZfwEngiqOC5xw+5aQcj+Quw/cN7aScLyLNfaosK9th3 YHwbhTRxcNoapFRae08pnjkI4baYAz8lbjaOBa0utga2r/Y8QrjSprqmOK1TYk/shsIw L4OdtxNpcagFw2NpwHpy3SG8vGQawcQMhCR1iP6y4QtyJxyVCOLyFdBjaDalpUSaDG5l WySSdkay7xv6NP4u+ZfDWOqnUSjYz30jk4LAkL7RWpCI/0FZ9sQU7tTltxrJUeQD5CHs 0PYy/ZDE2y/lYQRyeSY+amKOKYJhuRERwB0tD/Rncds593N6R5Ki9tbwi2XirNDvpfUk R7dA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:date :message-id:dkim-signature; bh=pZyYS8bCsMw0l7a1j3VRZ8p1qvLHL9J2Bf9LzAD6V3c=; fh=IlzoM7xapMIT9vjIu8V1YxnmOSGAT8hvLuDm+hjUGIo=; b=B3aNX5Gz6M2C5qU+4iBsZBA8HGXESU7Hwg/sV6yIyBPYh5rpKUaqC6PqrIgJyX32PL izkdy5XqeXMMigftvcIv8wWaeXBpYQdNAaeSWrKRy0VjrR/SxgZ3EZCG9FanUGSlE5is 6ZiPv5ZT3drONJKf4CvG7WsZn1xn8Cpx+7WKA1cZUozU0QR10szl3+Q9bCJ6FYScZDcH 6okh4PQrXzXJNdAfq6uSBAb1d0BKuzvk7t2UQZ4OCefO0DmEtPcROfC+z93I8uZNEaHf tyj3zak2Jv4RGL2xUq0UIz8n2bJ1hzgV5gVrczf3HMfPgGy/nfJqB7GtVrCMeGuTM0zc j8kA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=fsFIW78T; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) smtp.mailfrom=alexander.ivanov@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazlp170120005.outbound.protection.outlook.com. [2a01:111:f403:c200::5]) by mx.google.com with ESMTPS id d2e1a72fcca58-8b645541d38si7468239b3a.10.2026.11.09.04.41.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2026 04:41:49 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) client-ip=2a01:111:f403:c200::5; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=fsFIW78T; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) smtp.mailfrom=alexander.ivanov@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=B9GLYAXpPMKTrHr1nAxoAFJRFAq7NY1HXUEuEFj3qmZuao9nk1rZYo7sgOOPXPWcs10rG+5b7v2YXRkEUaCKUnY6rC+pZhDB/2x73fV/xt5NmbSm2TdHakrA2A+rtpguiU3VnOEP/Myzq1gpkS7pioAXtFsaMY+q9QeGBlOdv4C+g63W0NQ72QRsTC4Z04aq2VPp89p2xb5EMER0zprRcjB/x0Im/B4n3UKxP72AAEUc3DEk9WKjPZAhteo8/v0PqPjfb6qkT3cPHp5VXeL9kA76ofLeYPIwD4xTSDaHBAZ4T2cMxQd0TKzljOQD/DxSzvPtygFL9KddxpH1Uap8cw== 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=pZyYS8bCsMw0l7a1j3VRZ8p1qvLHL9J2Bf9LzAD6V3c=; b=HoW7+Z4E0qZ8ckZaR9w9Jk8w0FPebqjgVm/xePaPWMLaaSubKhOe5IToIXbbCyScFgs110R0jNgJfaA9ae7qBfNzSL0ulTtlKX+SpW/3QIFWvO1zNC/Ij5bK0N8Hc1IlMs4Rr6UjZUEt4r8HqA/s9k4M1/79bYFDNE2LLyb+W9CISwTergB7oegJ6vzvkbDRCF4bC6bVnp97nO42F2sXgPa/BMu2YZh4KXgTT97Zyvu+9g4gntCQpNZBZZQEhNxqLx5Kx8Zb0mkM4GGhYoUAWM5RrEX9GWsPt5skVBrFw0onpnAHd9aMfDTJW/frCN8eZOjbtRUBCLGmBhUWtnLb5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pZyYS8bCsMw0l7a1j3VRZ8p1qvLHL9J2Bf9LzAD6V3c=; b=fsFIW78TSLyvbdNNX5Z34SzbjZUlhWxUNz+8wQHC8sCJ7zKopLnut5Sd/spXGKYqT8zD3alax0IMdJbPfdQFEv3U4/jq38PQjed70nyF0Ej9GtHp3TX3+DG8zOaXlh4SrozTOUezzfQYVK2hym/Cgwo452rAbUb/2/b6Q6fKlb7gPl0PsIRBrMi960wXjgt2HA4a7xN/ckEdYO6fchuh1EmKNMGrDhMQaG7X4ZBkyR+UC/r5hWRZtIZzMMbBeJmBm/pn8qs/XvNZU8tFGlrJPB56Duu1jTjzGUY6bODEuA5ja0zwfw/PBIGvmsG/ufMH0gMYHlLdDQB3eKDK0qzKhQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) by DU0PR08MB9557.eurprd08.prod.outlook.com (2603:10a6:10:44e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.592.12; Mon, 9 Nov 2026 12:41:41 +0000 Received: from VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a]) by VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a%6]) with mapi id 15.21.0592.009; Mon, 9 Nov 2026 12:41:40 +0000 Message-ID: <97aa103b-e95d-4260-a8cc-7a4a5a412c2e@virtuozzo.com> Date: Mon, 9 Nov 2026 13:41:39 +0100 User-Agent: Mozilla Thunderbird To: no-reply@sashiko.virtuozzo.com, andrey.zhadchenko@virtuozzo.com References: <20261109115856.1362416-1-alexander.ivanov@virtuozzo.com> <20261109115856.1362416-9-alexander.ivanov@virtuozzo.com> <010701a1c03661c8-22228282-1788-45d9-9c3a-368d7f98b904-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a1c03661c8-22228282-1788-45d9-9c3a-368d7f98b904-000000@eu-central-1.amazonses.com> X-ClientProxiedBy: FR4P281CA0169.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b7::15) To VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10743:EE_|DU0PR08MB9557:EE_ X-MS-Office365-Filtering-Correlation-Id: 3478ffb2-b27f-4390-3927-08df3e5ecd71 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|376014|23010399003|1800799024|5023799004|4143699003|56012099006|261021121427099003|261022075727099003|261022105027099003|261022115727099003|261009223027099003|261026140227099003|261026121527099003|261028144727099003|261102123227099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: sG4iVGskPG3aEd+sex/Lq8rYkBdjfIYbOGTLjLojlN5XdrnmylmaAVofs5Li2+A9c09fEhPN5E/oqDV8Yv6O8rAL66nAnTa8QbndvwyuLryQ5l5pbCj//ZzT0DJH2R9IJOrmvnIkucLighvlAHGHyCYbjELzmBVd2Ts0Yl9RRRNQopUdjh/H44VwA4ygRUOLTeD6vXQ3Gq5r6MX21yZFxBdzOpVZ8kydY7/OEKCBUDs/OY3NDmTAiN5R/sv7rzzr/RCvID7cUQxoIuiXp0uhRqS/SMozTMo0RpDoHSYyITYvpHRkUlVPJtEXV4t4bx5gU9MmvORNza7os/0FquswL2ijqbHl1o4l8gllSWCoVKqswUCRKRbDQpJDwKES7SXCFZpPlpTmvybM9LUBTjZbyk5fP+ZOnpY7nZLSAfRSolOLYedvJJkZYTAhgrPsMOF+qCiHkrc1KNR+LWO9yC3MRdjzp4KuLuGzympJCUUqNrKqOfKjsIjkPpRBepg4YOeEe8+lXTVr9vscu2WkTnl7V/4KIvx+ZRyV8D6A3D7Lw4SZ0C1d6Puua/gVHHE52cqW5QBje3rg2A2WmjogQYJBrSrP6xEzx3hSmfin+idSj/op0IVKrotoG2olMTK8XypTklh9LRWmuWfC+WqKE9SY08sncTWRhyjkyLElBC52xvU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI0PR08MB10743.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(5023799004)(4143699003)(56012099006)(261021121427099003)(261022075727099003)(261022105027099003)(261022115727099003)(261009223027099003)(261026140227099003)(261026121527099003)(261028144727099003)(261102123227099003)(10067099003)(18002099003)(22082099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U04ySnNkbUpxN2FVd25vMU9ud1d4ZXkzR0gwL1MxR0dmVzhRUHhKaWJrYWJi?= =?utf-8?B?NU81ZFpwMXZncEI0L3c3TEhBTmRwRmtGYjhQdk1GcUI1ZFIxWVFZN05Za05q?= =?utf-8?B?QW9mSThyNUN4cG1PQVV3V0xaZ0hIQjNHelo2eXRIallJZ1MxTVpsd2M2bnpO?= =?utf-8?B?NDRzdkFZRy83RXQ3OWNiNGl1ZnVtL0tOOXFnVmZaMGdJNGdNeUJRQ3BTQ0dZ?= =?utf-8?B?bUEzQ2RZZlpGL1JwdXpYVkx1bzNORldKTTlXT3FJQ3hPS3FaTVh6TkgxczNl?= =?utf-8?B?OWxEYlhqZFUzWmdCM2d4YlNBclNQYnpIU3pUZGdCS3pKTmZpRzB6YWh0WnpG?= =?utf-8?B?dVpLMTJqR0c1cE5vTlNtRHFEcUNkd1p1SFhRY0FIMm95M0JqQ0llSnowSFNT?= =?utf-8?B?WWZFY3RKWkJrdXdQYjNBZHFFcFNMczdyTTB3QTdxUUJ4dDRKSmU2Y1Q5enF3?= =?utf-8?B?Yk1YVVhMZnRHOTFqUzVDOHNVLzJ4amJpR3kzWlZJeGM4bFRwRWNweU9zMDdZ?= =?utf-8?B?QjNsN29jR1FvM0VDVVV1QWNqQmoyQ0FONnVaaFZjSklxd0FacUlaMk5jbFpM?= =?utf-8?B?eFFLb2ZZQ1huY0FmODFHYkEzendKYk5zWGpqbmpuZkwvMEJRYXFNNlNPNHFp?= =?utf-8?B?TWhkTnlmamF6RlZUY2p0OE11TFQxeFVnOTBuZVpiREN4OGhBaFpWMDVFbTlr?= =?utf-8?B?TjVHRGJpSmowTCtYcWV1VzN5cUR1bWNTSmVpUXpPK0orUmwydHdZOENRVlhB?= =?utf-8?B?clVUVzR2d3VhdnpaclBodVFCTUFPUFNGcEdPSC9nMDZLWmVtbEdyR3FWVkF0?= =?utf-8?B?QjZkY2hxam1OdmJIYWVaTGFmaDlnNElzNUJzaEFla1FhV2NmN29YOFdGREFw?= =?utf-8?B?eHpNRXJvNTM5a2tySytJZzZZaDZEU29pSzRKbVBiejdGV3IwQVB3NGhvSUpS?= =?utf-8?B?bTFhU2JTWVdhTmtmbDlKcUdzKzlmK2U5ekFieFZzTHV2bWxmRjZHTEt2RUEr?= =?utf-8?B?WEtqK1V3ZlBzeFJFMTlLVG55ZXYvQ0tVUjFsY2RJT3V6QjlQRXFRTEIweXQv?= =?utf-8?B?c0YwSHZvelU3MWVqbTJjclE5K05EeDdNYkNKbk13K1UwTUloenk5b1RKQWQy?= =?utf-8?B?QkZRSWl0eEpuYmNSSnlMYUE0ZnlFZVBSZkhFaUFsYTE4NnFuR0J4b2JzU1RL?= =?utf-8?B?ZTFYdGxmN25VTWJJK0h5OFJ0UWZHMXQ5UTR4RTFLdXFhYzQ0Z1YxOURKa3gw?= =?utf-8?B?MU5KQVBaZitmaXFyWkgwRCtpTVVFVGVNSXQ0SjhSYmtEV2xCaWJkRHdPdUtL?= =?utf-8?B?ZUpqWERLNUtlTi9NaUUrM2NmWE90VHNNdUE0dkxYaUdZc3A5UlF5L3dUbUZn?= =?utf-8?B?ZzlCcVQzU3VmU1Z1MWRDaG1UU3JCTzBxdEo1OG5ZWHJrWGV0ZkpiN201c2E3?= =?utf-8?B?ajFMMDV4dnluK1ZqQVJEZWhQY0dQQStSVHg2QnM0S1RZbGZxa2ZoWDhZMVN1?= =?utf-8?B?bHRrSjhaazhxdm8rVTR6MVltRnVsdlpwWnU4ZEE1OVpxenlSSHpMSHJvT21L?= =?utf-8?B?eEl5dWs4RXNUdUJNNWpaWXNRRzF1VFl3L2lQa3V6NmdFUitTY2VtelY4emNW?= =?utf-8?B?NnNMK2pSN04vT1lWZzdvUjdoY29HdnRNYUcrSzIxUGVyNHUwdkp3Ri8xZUli?= =?utf-8?B?YmJOOHlldDgrVE8xT3p4a3NiQitaT3VZNnl3YlhWZERaZzhBR2tCK3Z1UjVX?= =?utf-8?B?cEtlTG1QVkxpbFc0ZkhSUzAxRTdmNEpBZWRqTXB2cSttQVd3Yi81cE5OdG5R?= =?utf-8?B?dDhFd1ovcUFzOGlIZVFNSEx3Snl6TmtmZVNCQWo3MlByZHdyRzJLMkNsVnd3?= =?utf-8?B?M3VxQWpreEhYK3RiMHQvQ1JEeit1OTBmVVdRRVVwckt3ZTlmYVVMc3A1OUVE?= =?utf-8?B?MUFESWlnNUk3STlIeDhvTitzdDd1d2lKb3h3ajg4eWgvN2h6dHYybFROM3Yx?= =?utf-8?B?ZGFmdUNlZnhGaGpjYjRGb3lPVytGZjRBeUtpQ2Vzaitxcld1akJjY2VWNXNN?= =?utf-8?B?NHVkTU5ta2Y3bUtjTzFlUFliSTZkc3lZb2dQc2lBSjM5bC9CK3JxMGJFWmVC?= =?utf-8?B?VEZxU1ZHY3E2RGtRc0pDL25KZm9TR1c0UnBtTFZTcjd0ZTNVMkNZV2xBQVpE?= =?utf-8?B?TXF3Z2ZpS3lZREc1MXVYQ0NaREJhQ29Jeldudy8vWW4yTW9XTVhUak1OanhD?= =?utf-8?B?V1Z6UmZYYkd1Z0NFbzIzUkhrTFkvUFRZZmI5SStMRlNsNExENjBXS29WK0pv?= =?utf-8?B?SHkwajNVSXFpcEhzVGx5ekZtbnNHcXM4cTBxUzNOM2RGbld1L0kwSzZ0Vy9Y?= =?utf-8?Q?jQghcK2unWHWEYmg=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3478ffb2-b27f-4390-3927-08df3e5ecd71 X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10743.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2026 12:41:40.6982 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HW5XDAMGcKEQTyEAldjOfmJH6NKBOPqtZQ5cUAImuZi2B4LFpsBwdJpuWQK620Pvy8aGqm/VNAGZFPxLIILTecp4G0nS6lcY3iZ35Mw5DA4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9557 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v10 08/10] dm-qcow2: leak clusters allocated for a failed L1/L2 writeback X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org >> static void revert_l_entries_update(struct qcow2 *qcow2, struct wb_desc *wbd) >> { >> + struct page *pe_page = wbd->pe_page; >> + u64 old; >> + int i; >> >> lockdep_assert_held(&qcow2->md_pages_lock); >> for_each_set_bit(i, wbd->changed_indexes, LX_INDEXES_PER_PAGE) { >> /* Here we restore prealloced and compressed clu mappings */ >> + old = pe_page ? get_u64_from_be_page(pe_page, i) : 0; >> + set_u64_to_be_page(wbd->md->page, i, old); >> } >> } > [Severity: Medium] > Does this leave the newly allocated clusters permanently allocated for the > lifetime of the running instance? > > The data cluster from LU_WANTS_ALLOC and the new L2-table cluster from an > L1 update are allocated in prepare_l_entry_update(), and > mark_cluster_used() sets their refcount to 1. > > If the md page writeback then fails, complete_wbd() calls > revert_l_entries_update(), which now only restores the in-memory entry > from pe_page, or to 0. Nothing calls mark_cluster_unused() for these > clusters any more, and no other path frees them. > > The guest can retry the failed write, and that retry allocates a new > cluster because the old one is still marked used. With a persistently > failing backing device, would each retry consume one more cluster until > the image or the refcount table is exhausted? > > Nothing counts or reclaims these clusters, and no QC_ERR message is > logged, so the operator is not told that a check is needed. Would it make > sense to log when a cluster is intentionally leaked here? > > The comment above complete_wbd() that says "clusters allocations > reverted" also looks stale now. The leak is intentional. The failed write may have partially reached the disk, so L1/L2 on disk may point to the allocated cluster. Freeing it lets the allocator hand it to another offset, and two guest offsets then share it, which corrupts the image. A leaked cluster is harmless, and check reclaims it. The retry concern is mostly theoretical. Refcounts reach the disk before L1/L2 does, so on a persistently failing device the R2 writeback is expected to fail first. That sets MD_WRITEBACK_ERROR and the image needs check anyway. A leak needs the R2 and data writes to succeed while the L2 write fails, e.g. a transient ENOSPC on an L2 overwrite. Such a write is retried no more often than the ENOSPC timeout. The refcount table is not exhausted either: it is relocated and the file grows. A message is not added: the image stays consistent, and space is the only thing lost. The stale comment above complete_wbd() is fixed, thanks. > >> @@ -1415,6 +1381,8 @@ static void complete_wbd(struct qcow2 *qcow2, struct wb_desc *wbd) >> &wait_list, &end_list); >> spin_unlock_irqrestore(&qcow2->md_pages_lock, flags); >> >> + list_for_each_entry(qio, &end_list, link) >> + qio->ext->cleanup_mask &= ~FREE_ALLOCATED_CLU; >> qcow2_dispatch_qios(qcow2, NULL, &wait_list); >> end_qios(&end_list, errno_to_blk_status(wbd->ret)); > Clearing FREE_ALLOCATED_CLU here makes handle_cleanup_mask() skip its > mark_cluster_unused() call for COW qios on the failed end_list. > > That removes the only remaining path that would free the COW-allocated > cluster. Is this loop always safe, given that qio->ext is dereferenced > for every qio on end_list? Can any qio on dependent_list have a NULL ext? > > The commit message also says: > > "Keep the refcount of these clusters instead. If L1/L2 on disk points to > such a cluster, the image stays consistent; otherwise the cluster is > leaked, which check repairs by freeing it. So the image needs no check > and resume needs no refusal." > > Is this accurate? The message itself says a leaked cluster is repaired by > check, so the statement that the image needs no check appears to > contradict it. Could the message be reworded to say that the image stays > consistent but may need a check to reclaim leaked clusters? A leak needs the data write to succeed while the L2 overwrite fails, e.g. with a transient ENOSPC. With the disk full, the data write fails first and the cluster is freed as before. The image stays consistent; only space is lost, so no message is added. > diff --git a/drivers/md/dm-qcow2-target.c b/drivers/md/dm-qcow2-target.c > > [ ... ] > >> /* >> * We need second iteration, since revert_l_entries_update() >> * may start timer again after failed wb. >> */ >> for (i = 0; i < 2; i++) { > [Severity: Low] > This isn't a bug, but is this comment in qcow2_flush_deferred_activity() > now stale? > > It says revert_l_entries_update() may start the slow-writeback timer again > after a failed writeback. That relied on revert_l_entries_update() calling > mark_cluster_unused(), which dirtied R2 pages and re-armed slow_wb_timer. > This patch removes that call, so revert_l_entries_update() only rewrites > L1/L2 entries in the page. > > Timer restarts can still come from other end_qios()/qio_endio() cleanup > paths. Could the comment be rewritten to describe the current reason for > the second iteration? Rewrote the comment. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel