From: "Sam James" <sam@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] repo/gentoo:master commit in: sys-fs/btrfs-progs/files/
Date: Mon, 18 Apr 2022 07:15:55 +0000 (UTC) [thread overview]
Message-ID: <1650266138.e800d7e6f70c02bf2b2844fef2e1f47c4e835daa.sam@gentoo> (raw)
commit: e800d7e6f70c02bf2b2844fef2e1f47c4e835daa
Author: Michael Mair-Keimberger <mmk <AT> levelnine <DOT> at>
AuthorDate: Mon Apr 18 07:06:23 2022 +0000
Commit: Sam James <sam <AT> gentoo <DOT> 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 <mmk <AT> levelnine.at>
Closes: https://github.com/gentoo/gentoo/pull/25079
Signed-off-by: Sam James <sam <AT> 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 <nborisov@suse.com>
-To: linux-btrfs@vger.kernel.org
-Cc: Nikolay Borisov <nborisov@suse.com>
-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: <linux-btrfs.vger.kernel.org>
-
-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:
-
- <snip>
-
- 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:
-
- <snip>
-
- 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 <nborisov@suse.com>
----
- 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 <nborisov@suse.com>
-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 <nborisov@suse.com>
-Signed-off-by: David Sterba <dsterba@suse.com>
----
- 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;
next reply other threads:[~2022-04-18 7:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 7:15 Sam James [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-20 20:20 [gentoo-commits] repo/gentoo:master commit in: sys-fs/btrfs-progs/files/ Ulrich Müller
2022-07-18 21:41 Conrad Kostecki
2017-02-11 20:16 David Seifert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1650266138.e800d7e6f70c02bf2b2844fef2e1f47c4e835daa.sam@gentoo \
--to=sam@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox