From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id CBC8480726 for ; Wed, 21 Oct 2026 15:43:37 +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 69LFgMWh021533; Wed, 21 Oct 2026 18:42:23 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69LFgMWh021533 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="tmgRSlJL" Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69LFg8eW021506 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 21 Oct 2026 18:42:08 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69LFg8eW021506 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4a019d53f46so8606955e9.3 for ; Wed, 21 Oct 2026 08:42:08 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBzWdxd2sT730anTEMJHDipPX13EQ2ngNOXHxssUiP7gw6Bchw/MPnwIOV/R09hVmOtn/AVOQA==@openvz.org X-Gm-Message-State: AFq9FYJ3CMeKDPBeUDGSnrhMrltotMvS2y3pbgw/3dh0IA8CzYPGh3gH ycRv2JZUGeTzxJrkFJPO7V/7zItiMVwmaXD2+98OCIxkpSwmuAD3cfvCuZSVwsOegsBO9Fn0/do xkEQg7fAE/Miprb4TVUSmn29AlHW6Lok0k4Yd+B5k3YDMu2YyL42pZw== X-Gm-Gg: AYBFou0qrSXfHtvbCKdkNm6Hr7KWgWo5Z7U0I85NOgzXdm2I6Mumw4+zmJcOGDOT55Q t9+VOt1v6/Q8TX2kunRy4HC0l/cKpU1TjHzMCGiHSPKAkVmVIZiEXlIUxDargVLe0R4yiZu+Isg X1Zy7wZq0ZvqD4Rukkc/avbTEYAltKB50eVohe7ua8SMRJSBGbv2WnNGIGao/DlW+lIi98QDci6 2s1Uf7BChmfsNJYAvzbSi8x4VKrzbXSAIiv05fWKkyN6Q7Ztuh4xe0CX9tpr7pNCe4ZvUT3lJ1/ OtOXMfWNbFldB54xXkmoW0vfDT9CCCr3lPH3r7LwRpXyRTqc6hAUCLdEfdTe2a+8mJ7iFpUzH0r cd/tPi82HljWsi2Ag X-Received: by 2002:a05:600c:1c1a:b0:4a1:bc6e:2f4 with SMTP id 5b1f17b1804b1-4a1fd72acf3mr51332945e9.0.1792597328184; Wed, 21 Oct 2026 08:42:08 -0700 (PDT) X-Received: by 2002:a05:600c:1c1a:b0:4a1:bc6e:2f4 with SMTP id 5b1f17b1804b1-4a1fd72acf3mr51332165e9.0.1792597327578; Wed, 21 Oct 2026 08:42:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1792597327; cv=none; d=google.com; s=arc-20260327; b=JNrKWeYF7VpfwfoTdncAPY95NvVKhFm/iojthn4KQHHYdIov7zP6R8efHI9xnyRGi4 cdnTMR7oP008eKSjgl36zS45cR27jczlXxPsV23ArL1ZMMaoFXERKVNg7BrtcmeGFv4t EMUzpFCmOvYvrb0yURoA20mKSYoqvdxfCAeBiuUC89v0uE6sp504Ym+njQjkxEGmwLWW waIJEhYFq6DvidMGo9R2hUNccwlI35hgKQX4Ja3WJk0T/Sl6UWbjC9IUM0hghp4V9jGk j2+VMrUE7gcXyqAiVdyAzLKeyHEzuxwCVnXP5qaZTdteiPMVXJEAgLocPDIcBh1vUnKd JDNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=message-id:date:references:in-reply-to:cc:to:from:subject :content-transfer-encoding:mime-version:dkim-signature; bh=jRozfGR+DnpWdK3f3B8EkySe2l/cW5SFXvhocIEGjxY=; fh=dEALvyefJBnY6nyJGHYBKeYIaK3H1xJ1Smb/xz+zJI0=; b=EV0CuPVD9qHCwhVyIqHFcDxoWFc6oACIQ4otd8/xc7lTBBZyT0eJi01Xg75VhV131T WID4xUjeSnJntzusOjipzwVrcEgVyKp4QK84yujVDhlcUq8QoljoR1TeWWzPxQdhv25g h07aJ4R90AtDeyrYxw3L0IfcwTeTv7n7EryY84wgUaXANQkYseyWiuTs/WjppH/UrRku 17LWBcRoG+zvNieXgU1bt7E0ivZZVm3pAYK+abF1SfrF+xuKJg17Z71yO8kfGytvKNgJ jQdfByg/8YTrhJ9aEmYYNtvcdAvUTqvAmhNT3aomoEH2YLv4hnKdSta9X5ZRIRNHtI3L 97Sg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=tmgRSlJL; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-48e2b4a855bsi804803f8f.317.2026.10.21.08.42.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 08:42:07 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=tmgRSlJL; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Message-Id:Date:From:Subject:Content-Type: MIME-Version; bh=jRozfGR+DnpWdK3f3B8EkySe2l/cW5SFXvhocIEGjxY=; b=tmgRSlJLJnak onSTYY/kwn1vXFR/lrUw821ACrTyN1+3UBuab3c9K56H0MrNbAvgyv8ChgLOWBl92txtVwior2OVF zYKWIX3tBhDx6rKl9PogzqMpQLec0OcjBDSSdrhSUVenuW5JihiH4KU7K5FuvDanx7bFmGnlDNI4H flSdTmuEp7seErp+SNfB+x4CZf1Ho0JaZVXbFYoY4m7amOGhvKY8AIpN2knctkJvxgKSzllcQdXXp 8qHK8ikeghDY8oIAxigEkylj1R0OeJNR55z/HD4oIIbcwe2Iqi1Mm3eGAoh4fAmcHc2KNFlwtz0lc 9FIFv1NXWNVdUUj0qQ+efQ==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1xJYOV-007X7J-0z; Wed, 21 Oct 2026 17:42:06 +0200 MIME-Version: 1.0 From: Konstantin Khorenko To: Alexander Ivanov In-Reply-To: <20261010124642.927044-4-alexander.ivanov@virtuozzo.com> References: <20261010124642.927044-1-alexander.ivanov@virtuozzo.com> <20261010124642.927044-4-alexander.ivanov@virtuozzo.com> Date: Wed, 21 Oct 2026 17:42:02 +0200 Message-Id: <179259732233.3864599.9993825844420241421.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3228; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=EOpUoCR/8wWlWxI/gQMwR3D0aDmbKOBsi8d4d3rCNQk=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBq2N1NSeqfwsh8Ep+EnBN41P9zOtzTGh00avQ9K eXP/QUZImWJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCatjdTQAKCRBRlgpH+WFc Kh+2D/9gcaTCDdHT9ibnWUk3DNtRETOaXDFMgL839L0Zxu1xwMwy/uktmhiJIGoKBhVYV4KM/FA YOzlsF3+DZWSGLcxevEMYS/xK3gfYs5RoYN5WKj6h8MBFtvwj8oj8NePD268SqYh+i+MH5AhTeU pOJJB+4DyD9qc9Bfrrts9vMwlQbq26KURgPAZ7Fw16ELZIgsSyjDDmfXviaTGpZVyWX2wyzRMJY o961H/0nyBbnxxmcdVS+VoFxImfzj9Kn51mEVU9VZGK0b98G+nDi3fJH3GSCP380BIp0NqO8jO5 wW6sf8Vdu+BNXWwnAg6VJQNW0TRwIZHi0aFTFVJaBQ25OCAnfljGW1JRKYPOhTF2JZ3Uj8mLVqx +P8Qr/EQ0/2xlReW2O3icilPtiyXqfwgXHPZ3w42N/TJbidi1NKy82sI29+pgf3yXdr+MkzkzXy 9rA6GmdWQ0Qkn6sZuzeT7URglLCYGhydlZIUSWrY61IxNL6Z15QqDy1Zi18HBvIS44foAg2zFTw Gy6QQMQg1uW0LXtRmDHWdKP11QxpbIfKtAFsNXquoazJ1Jba04uJ1RTL9lZaOvXwVd7AfROfV7L 6JS+JzJTSqdu3N3NALccufq8+xYTLHeS4KdTpgEq0Ttz4XZNyR2WHcwyVerVOlvjMSGLEWfk3/H loz087LvimDdjOQ== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v5 3/3] dm-qcow2: truncate unused tail of image on suspend 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org I'd rather not truncate the image in the kernel at all. My comments below are for the case we keep it. The scan trusts the refcounts and never checks them against L1/L2. A wrong refcount or a wrong scan start then costs data on the first suspend: stop, snapshot or compact. Without this patch such an image can still be repaired: - ploop runs "qemu-img check -r all" on umount, compact and resize; - our qemu-img (qcow2_check_extra_preallocation(), not in mainline) rebuilds the refcounts from L1/L2 and truncates the tail only if the image is clean; - qcow2_preresume() rereads the metadata, so this works on a suspended device too. This review alone found two ways the scan cuts live data, see below. I don't think they are the last ones, so I suggest we keep the truncation in userspace. > + * leave the tail of file unused. Everything at or above > + * file_preallocated_area_start is unused by construction, so the scan > + * starts below it. This must be called on suspended device after md This is not true, and the idea came from my v1 review. place_r2() links a new refblock into R1, but moves neither file_preallocated_area_start nor file_size. The refblock stays at or above the watermark if: - truncate_prealloc_safe() in allocate_cluster() fails after place_r2(); - a parallel mark_cluster_unused() lowers free_cluster_search_pos before the second pass of find_unused_cluster(). The scan then starts below the refblock and may truncate the file under it. R1 on disk points past EOF, and the next session gets -EIO on allocations in that range. In the first case the old code did nothing, so this is a regression. Please make place_r2() extend the file and raise the watermark to r2_pos + clu_size before it links the refblock into R1. The old code can cut such a refblock too, so this is a separate patch before this one. > + pos = round_down(qcow2->file_preallocated_area_start - 1, clu_size); > + while (pos >= 0) { > + if (calc_refcounters_map(qcow2, pos, &r1, &r2) < 0) > + return -EIO; After a failed relocate_refcount_table(), file_preallocated_area_start stays at r2_end, beyond reftable_max_file_size. The first pos is then outside the reftable, and calc_refcounters_map() hits WARN_ONCE(), which panics with panic_on_warn. Please start from min(file_preallocated_area_start, reftable_max_file_size). > + /* Refcounts on disk are stale after failed md writeback */ > + if (!tgt->md_writeback_error) { md_writeback_error is set for R1/R2 pages only. If an L2 write fails but the page did reach the disk, revert_l_entries_update() drops the refcount of the new cluster to zero, while L2 on disk still points to it. If the cluster is at the tail, the scan cuts it. Please skip the scan after any failed md writeback, L1/L2 included. > on remove, __dm_destroy() suspends the live table if it isn't > suspended yet __dm_destroy() only calls the presuspend and postsuspend hooks: it does not stop the queue or wait for I/O. The device is idle there only because dm_lock_for_deletion() refuses to remove an open device. Please say that in the commit message. -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel