From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 70AE015808D for ; Mon, 18 Apr 2022 07:16:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 62C87E09CC; Mon, 18 Apr 2022 07:15:59 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2ADE8E09CC for ; Mon, 18 Apr 2022 07:15:59 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id F0197341611 for ; Mon, 18 Apr 2022 07:15:57 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id BD2A43B3 for ; Mon, 18 Apr 2022 07:15:55 +0000 (UTC) From: "Sam James" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Sam James" Message-ID: <1650266138.e800d7e6f70c02bf2b2844fef2e1f47c4e835daa.sam@gentoo> Subject: [gentoo-commits] repo/gentoo:master commit in: sys-fs/btrfs-progs/files/ X-VCS-Repository: repo/gentoo X-VCS-Files: sys-fs/btrfs-progs/files/5.15-filesystem-usage-chunks.patch sys-fs/btrfs-progs/files/5.15-filesystem-usage-data.patch X-VCS-Directories: sys-fs/btrfs-progs/files/ X-VCS-Committer: sam X-VCS-Committer-Name: Sam James X-VCS-Revision: e800d7e6f70c02bf2b2844fef2e1f47c4e835daa X-VCS-Branch: master Date: Mon, 18 Apr 2022 07:15:55 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 20a563be-3706-44dd-9375-3428f8d62017 X-Archives-Hash: 66df664bac5965f5c8c627f9886efb31 commit: e800d7e6f70c02bf2b2844fef2e1f47c4e835daa Author: Michael Mair-Keimberger levelnine at> AuthorDate: Mon Apr 18 07:06:23 2022 +0000 Commit: Sam James gentoo org> CommitDate: Mon Apr 18 07:15:38 2022 +0000 URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e800d7e6 sys-fs/btrfs-progs: remove unused patches Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Michael Mair-Keimberger levelnine.at> Closes: https://github.com/gentoo/gentoo/pull/25079 Signed-off-by: Sam James gentoo.org> .../files/5.15-filesystem-usage-chunks.patch | 94 ---------------------- .../files/5.15-filesystem-usage-data.patch | 37 --------- 2 files changed, 131 deletions(-) diff --git a/sys-fs/btrfs-progs/files/5.15-filesystem-usage-chunks.patch b/sys-fs/btrfs-progs/files/5.15-filesystem-usage-chunks.patch deleted file mode 100644 index be58afc8712c..000000000000 --- a/sys-fs/btrfs-progs/files/5.15-filesystem-usage-chunks.patch +++ /dev/null @@ -1,94 +0,0 @@ -From: Nikolay Borisov -To: linux-btrfs@vger.kernel.org -Cc: Nikolay Borisov -Subject: [PATCH] Fix calculation of chunk size for RAID1/DUP profiles -Date: Tue, 16 Nov 2021 16:02:06 +0200 -Message-Id: <20211116140206.291252-1-nborisov@suse.com> -List-ID: - -Current formula calculates the stripe size, however that's not what we want -in the case of RAID1/DUP profiles. In those cases since chunkc are mirrored -across devices we want the full size of the chunk. Without this patch the -'btrfs fi usage' output from an fs which is using RAID1 is: - - - - Data,RAID1: Size:2.00GiB, Used:1.00GiB (50.03%) - /dev/vdc 1.00GiB - /dev/vdf 1.00GiB - - Metadata,RAID1: Size:256.00MiB, Used:1.34MiB (0.52%) - /dev/vdc 128.00MiB - /dev/vdf 128.00MiB - - System,RAID1: Size:8.00MiB, Used:16.00KiB (0.20%) - /dev/vdc 4.00MiB - /dev/vdf 4.00MiB - - Unallocated: - /dev/vdc 8.87GiB - /dev/vdf 8.87GiB - - -So a 2 gigabyte RAID1 chunk actually will take up 4 gigabytes on the actual disks -2 each. In this case this is being miscalculated as taking up 1gb on each device. - -This also leads to erroneously calculated unallocated space. The correct output -in this case is: - - - - Data,RAID1: Size:2.00GiB, Used:1.00GiB (50.03%) - /dev/vdc 2.00GiB - /dev/vdf 2.00GiB - - Metadata,RAID1: Size:256.00MiB, Used:1.34MiB (0.52%) - /dev/vdc 256.00MiB - /dev/vdf 256.00MiB - - System,RAID1: Size:8.00MiB, Used:16.00KiB (0.20%) - /dev/vdc 8.00MiB - /dev/vdf 8.00MiB - - Unallocated: - /dev/vdc 7.74GiB - /dev/vdf 7.74GiB - - -Fix it by only utilising the chunk formula for profiles which are not RAID1/DUP. - -Signed-off-by: Nikolay Borisov ---- - cmds/filesystem-usage.c | 14 ++++++++++---- - 1 file changed, 10 insertions(+), 4 deletions(-) - -diff --git a/cmds/filesystem-usage.c b/cmds/filesystem-usage.c -index 6195f633da44..5f2289a9b40d 100644 ---- a/cmds/filesystem-usage.c -+++ b/cmds/filesystem-usage.c -@@ -805,11 +805,17 @@ int load_chunk_and_device_info(int fd, struct chunk_info **chunkinfo, - */ - static u64 calc_chunk_size(struct chunk_info *ci) - { -- u32 div; -+ u32 div = 1; - -- /* No parity + sub_stripes, so order of "-" and "/" does not matter */ -- div = (ci->num_stripes - btrfs_bg_type_to_nparity(ci->type)) / -- btrfs_bg_type_to_sub_stripes(ci->type); -+ /* -+ * The formula doesn't work for RAID1/DUP types, we should just return the -+ * chunk size -+ */ -+ if (!(ci->type & (BTRFS_BLOCK_GROUP_RAID1_MASK|BTRFS_BLOCK_GROUP_DUP))) { -+ /* No parity + sub_stripes, so order of "-" and "/" does not matter */ -+ div = (ci->num_stripes - btrfs_bg_type_to_nparity(ci->type)) / -+ btrfs_bg_type_to_sub_stripes(ci->type); -+ } - - return ci->size / div; - } --- -2.17.1 - - diff --git a/sys-fs/btrfs-progs/files/5.15-filesystem-usage-data.patch b/sys-fs/btrfs-progs/files/5.15-filesystem-usage-data.patch deleted file mode 100644 index f3b43d5c594d..000000000000 --- a/sys-fs/btrfs-progs/files/5.15-filesystem-usage-data.patch +++ /dev/null @@ -1,37 +0,0 @@ -From 2f3950c8304fec2aed9bf11b52d073683b137330 Mon Sep 17 00:00:00 2001 -From: Nikolay Borisov -Date: Mon, 15 Nov 2021 11:15:42 +0200 -Subject: [PATCH] btrfs-progs: fi usage: don't reset ratio to 1 if we don't - have RAID56 profile - -Commit 80714610f36e ("btrfs-progs: use raid table for ncopies") -slightly broke how raid ratio are being calculated since the resulting -code would always reset ratio to be 1 in case we didn't have RAID56 -profile. The correct behavior is to simply set it to 0 if we have RAID56 -as the calculation is different in this case and leave it intact -otherwise. - -This bug manifests by doing all size-related calculation for 'btrfs -filesystem usage' command as if all block groups are of type SINGLE. Fix -this by only resetting ratio 0 in case of RAID56. - -Issue: #422 -Signed-off-by: Nikolay Borisov -Signed-off-by: David Sterba ---- - cmds/filesystem-usage.c | 2 -- - 1 file changed, 2 deletions(-) - -diff --git a/cmds/filesystem-usage.c b/cmds/filesystem-usage.c -index e22efe3a4..bac0f0fd5 100644 ---- a/cmds/filesystem-usage.c -+++ b/cmds/filesystem-usage.c -@@ -508,8 +508,6 @@ static int print_filesystem_usage_overall(int fd, struct chunk_info *chunkinfo, - */ - if (flags & BTRFS_BLOCK_GROUP_RAID56_MASK) - ratio = 0; -- else -- ratio = 1; - - if (ratio > max_data_ratio) - max_data_ratio = ratio;