public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
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;


             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