All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Whitney <enwlinux@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, Eric Whitney <enwlinux@gmail.com>
Subject: [PATCH] e2fsprogs: modify dumpe2fs to report free block ranges for bigalloc
Date: Fri, 21 Jul 2023 14:55:06 -0400	[thread overview]
Message-ID: <20230721185506.1020225-1-enwlinux@gmail.com> (raw)

dumpe2fs has never been modified to correctly report block ranges
corresponding to free clusters in block allocation bitmaps from bigalloc
file systems.  Rather than reporting block ranges covering all the
blocks in free clusters found in a block bitmap, it either reports just
the first block number in a cluster for a single free cluster, or a
range beginning with the first block number in the first cluster in a
series of free clusters, and ending with the first block number in the
last cluster in that series.

This behavior causes xfstest shared/298 to fail when run on a bigalloc
file system with a 1k block size.  The test uses dumpe2fs to collect
a list of the blocks freed when files are deleted from a file system.
When the test deletes a file containing blocks located after the first
block in the last cluster in a series of clusters, dumpe2fs does not
report those blocks as free per the test's expectations.

Modify dumpe2fs to report full block ranges for free clusters.  At the
same time, fix a small bug causing unnecessary !in_use() retests while
iterating over a block bitmap.

Signed-off-by: Eric Whitney <enwlinux@gmail.com>
---
 misc/dumpe2fs.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/misc/dumpe2fs.c b/misc/dumpe2fs.c
index 7c080ed9..d2d57fb0 100644
--- a/misc/dumpe2fs.c
+++ b/misc/dumpe2fs.c
@@ -84,8 +84,7 @@ static void print_free(unsigned long group, char * bitmap,
 		       unsigned long num, unsigned long offset, int ratio)
 {
 	int p = 0;
-	unsigned long i;
-	unsigned long j;
+	unsigned long i, j;
 
 	offset /= ratio;
 	offset += group * num;
@@ -95,13 +94,14 @@ static void print_free(unsigned long group, char * bitmap,
 			if (p)
 				printf (", ");
 			print_number((i + offset) * ratio);
-			for (j = i; j < num && !in_use (bitmap, j); j++)
+			for (j = i + 1; j < num && !in_use(bitmap, j); j++)
 				;
-			if (--j != i) {
+			if (j != i + 1 || ratio > 1) {
 				fputc('-', stdout);
-				print_number((j + offset) * ratio);
-				i = j;
+				print_number(((j - 1 + offset) * ratio) +
+					     ratio - 1);
 			}
+			i = j;
 			p = 1;
 		}
 }
-- 
2.30.2


             reply	other threads:[~2023-07-21 18:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21 18:55 Eric Whitney [this message]
2023-08-17 14:47 ` [PATCH] e2fsprogs: modify dumpe2fs to report free block ranges for bigalloc Theodore Ts'o

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=20230721185506.1020225-1-enwlinux@gmail.com \
    --to=enwlinux@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.