[PATCHSET] xfsprogs: various bug fixes for 6.19

[PATCHSET] xfsprogs: various bug fixes for 6.19

[Darrick J. Wong]

Hi all,

This is miscellaneous bugfixes.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

With a bit of luck, this should all go splendidly.
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
Commits in this patchset:
 * mkfs: set rtstart from user-specified dblocks
 * xfs_logprint: print log data to the screen in host-endian order
 * mkfs: quiet down warning about insufficient write zones
 * xfs_mdrestore: fix restoration on filesystems with 4k sectors
 * debian: don't explicitly reload systemd from postinst
---
 logprint/logprint.h       |    1 +
 debian/postinst           |    3 ---
 logprint/log_print_all.c  |    5 +++--
 logprint/logprint.c       |    5 +++++
 man/man8/xfs_logprint.8   |    4 ++++
 mdrestore/xfs_mdrestore.c |   16 +++++++++++----
 mkfs/xfs_mkfs.c           |   47 +++++++++++++++++++++++++++++++++------------
 7 files changed, 59 insertions(+), 22 deletions(-)

[PATCH 1/5] mkfs: set rtstart from user-specified dblocks

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

generic/211 fails to format the disk on a system with an internal zoned
device.  Poking through the shell scripts, it's apparently doing this:

# mkfs.xfs -d size=629145600 -r size=629145600 -b size=4096 -m metadir=1,autofsck=1,uquota,gquota,pquota, -r zoned=1 -d rtinherit=1 /dev/sdd
size 629145600 specified for data subvolume is too large, maximum is 131072 blocks

Strange -- we asked for 629M data and rt sections, the device is 20GB in
size, but it claims insufficient space in the data subvolume.

Further analysis shows that open_devices is setting rtstart to 1% of the
size of the data volume (or no less than 300M) and rounding that up to
the nearest power of two (512M).  Hence the 131072 number.

But wait, we said that we wanted a 629M data section.  Let's set rtstart
to the same value if the user didn't already provide one, instead of
using the default value.

Cc: <linux-xfs@vger.kernel.org> # v6.15.0
Fixes: 2e5a737a61d34e ("xfs_mkfs: support creating file system with zoned RT devices")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 mkfs/xfs_mkfs.c |   42 +++++++++++++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 11 deletions(-)


diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index b34407725f76df..a90160b26065b7 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -3696,6 +3696,36 @@ _("log stripe unit (%d bytes) is too large (maximum is 256KiB)\n"
 
 }
 
+static uint64_t
+calc_rtstart(
+	const struct mkfs_params	*cfg,
+	const struct libxfs_init	*xi)
+{
+	uint64_t			rt_target_size;
+	uint64_t			rtstart = 1;
+
+	if (cfg->dblocks) {
+		/*
+		 * If the user specified the size of the data device but not
+		 * the start of the internal rt device, set the internal rt
+		 * volume to start at the end of the data device.
+		 */
+		return cfg->dblocks << (cfg->blocklog - BBSHIFT);
+	}
+
+	/*
+	 * By default reserve at 1% of the total capacity (rounded up to the
+	 * next power of two) for metadata, but match the minimum we enforce
+	 * elsewhere. This matches what SMR HDDs provide.
+	 */
+	rt_target_size = max((xi->data.size + 99) / 100,
+			     BTOBB(300 * 1024 * 1024));
+
+	while (rtstart < rt_target_size)
+		rtstart <<= 1;
+	return rtstart;
+}
+
 static void
 open_devices(
 	struct mkfs_params	*cfg,
@@ -3720,17 +3750,7 @@ open_devices(
 		zt->rt.zone_capacity = zt->data.zone_capacity;
 		zt->rt.nr_zones = zt->data.nr_zones - zt->data.nr_conv_zones;
 	} else if (cfg->sb_feat.zoned && !cfg->rtstart && !xi->rt.dev) {
-		/*
-		 * By default reserve at 1% of the total capacity (rounded up to
-		 * the next power of two) for metadata, but match the minimum we
-		 * enforce elsewhere. This matches what SMR HDDs provide.
-		 */
-		uint64_t rt_target_size = max((xi->data.size + 99) / 100,
-					      BTOBB(300 * 1024 * 1024));
-
-		cfg->rtstart = 1;
-		while (cfg->rtstart < rt_target_size)
-			cfg->rtstart <<= 1;
+		cfg->rtstart = calc_rtstart(cfg, xi);
 	}
 
 	if (cfg->rtstart) {

Re: [PATCH 1/5] mkfs: set rtstart from user-specified dblocks

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 2/5] xfs_logprint: print log data to the screen in host-endian order

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Add a cli option so that users won't have to byteswap u32 values when
they're digging through broken logs on little-endian systems.  Also make
it more obvious which column is the offset and which are the byte(s).

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 logprint/logprint.h      |    1 +
 logprint/log_print_all.c |    5 +++--
 logprint/logprint.c      |    5 +++++
 man/man8/xfs_logprint.8  |    4 ++++
 4 files changed, 13 insertions(+), 2 deletions(-)


diff --git a/logprint/logprint.h b/logprint/logprint.h
index aa90068c8a2af1..2ba868a9155108 100644
--- a/logprint/logprint.h
+++ b/logprint/logprint.h
@@ -16,6 +16,7 @@ extern int	print_transactions;
 extern int	print_overwrite;
 extern int	print_no_data;
 extern int	print_no_print;
+extern int	print_host_endian;
 
 /* exports */
 extern time64_t xlog_extract_dinode_ts(const xfs_log_timestamp_t);
diff --git a/logprint/log_print_all.c b/logprint/log_print_all.c
index 0afad597bb6ce0..5a01e049b8bb50 100644
--- a/logprint/log_print_all.c
+++ b/logprint/log_print_all.c
@@ -55,8 +55,9 @@ xlog_recover_print_data(
 
 		while (j < nums) {
 			if ((j % 8) == 0)
-				printf("%2x ", j);
-			printf("%8x ", *dp);
+				printf("%2x: ", j);
+			printf("%08x ", print_host_endian ? be32_to_cpu(*dp) :
+							    *dp);
 			dp++;
 			j++;
 			if ((j % 8) == 0)
diff --git a/logprint/logprint.c b/logprint/logprint.c
index 7c69cdcc7cfacb..34df3400c8d544 100644
--- a/logprint/logprint.c
+++ b/logprint/logprint.c
@@ -24,6 +24,7 @@ int	print_buffer;
 int	print_overwrite;
 int     print_no_data;
 int     print_no_print;
+int	print_host_endian;
 static int	print_operation = OP_PRINT;
 static struct libxfs_init x;
 
@@ -37,6 +38,7 @@ Options:\n\
     -d	            dump the log in log-record format\n\
     -e	            exit when an error is found in the log\n\
     -f	            specified device is actually a file\n\
+    -h		    print hex data in host-endian order\n\
     -l <device>     filename of external log\n\
     -n	            don't try and interpret log data\n\
     -o	            print buffer data in hex\n\
@@ -171,6 +173,9 @@ main(int argc, char **argv)
 				x.log.name = optarg;
 				x.log.isfile = 1;
 				break;
+			case 'h':
+				print_host_endian = 1;
+				break;
 			case 'i':
 				print_inode++;
 				break;
diff --git a/man/man8/xfs_logprint.8 b/man/man8/xfs_logprint.8
index 16e881ee8f230d..d64af5963f1a8a 100644
--- a/man/man8/xfs_logprint.8
+++ b/man/man8/xfs_logprint.8
@@ -76,6 +76,10 @@ .SH OPTIONS
 an ordinary file with
 .BR xfs_copy (8).
 .TP
+.B \-h
+Print u32 hex dump data in host-endian order.
+The default is to print without any endian decoding.
+.TP
 .BI \-l " logdev"
 External log device. Only for those filesystems which use an external log.
 .TP

Re: [PATCH 2/5] xfs_logprint: print log data to the screen in host-endian order

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 3/5] mkfs: quiet down warning about insufficient write zones

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

xfs/067 fails with the following weird mkfs message:

 --- tests/xfs/067.out	2025-07-15 14:41:40.191273467 -0700
 +++ /run/fstests/logs/xfs/067.out.bad	2026-01-06 16:59:11.907677987 -0800
 @@ -1,4 +1,8 @@
  QA output created by 067
 +Warning: not enough zones (134/133) for backing requested rt size due to
 +over-provisioning needs, writable size will be less than (null)
 +Warning: not enough zones (134/133) for backing requested rt size due to
 +over-provisioning needs, writable size will be less than (null)

In this case, MKFS_OPTIONS is set to: "-rrtdev=/dev/sdb4 -m
metadir=1,autofsck=1,uquota,gquota,pquota -d rtinherit=1 -r zoned=1
/dev/sda4"

In other words, we didn't pass an explicit rt volume size to mkfs, so
the message is a bit bogus.  Let's skip printing the message when
the user did not provide an explicit rtsize parameter.

Cc: <linux-xfs@vger.kernel.org> # v6.18.0
Fixes: b5d372d96db1ad ("mkfs: adjust_nr_zones for zoned file system on conventional devices")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 mkfs/xfs_mkfs.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index a90160b26065b7..f539c91db251fd 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -4579,10 +4579,11 @@ adjust_nr_zones(
 				cfg->rgsize;
 
 	if (cfg->rgcount > max_zones) {
-		fprintf(stderr,
+		if (cli->rtsize)
+			fprintf(stderr,
 _("Warning: not enough zones (%lu/%u) for backing requested rt size due to\n"
   "over-provisioning needs, writable size will be less than %s\n"),
-			cfg->rgcount, max_zones, cli->rtsize);
+				cfg->rgcount, max_zones, cli->rtsize);
 		cfg->rgcount = max_zones;
 	}
 	new_rtblocks = (cfg->rgcount * cfg->rgsize);

Re: [PATCH 3/5] mkfs: quiet down warning about insufficient write zones

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 4/5] xfs_mdrestore: fix restoration on filesystems with 4k sectors

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Running xfs/129 on a disk with 4k LBAs produces the following failure:

 --- /run/fstests/bin/tests/xfs/129.out	2025-07-15 14:41:40.210489431 -0700
 +++ /run/fstests/logs/xfs/129.out.bad	2026-01-05 21:43:08.814485633 -0800
 @@ -2,3 +2,8 @@ QA output created by 129
  Create the original file blocks
  Reflink every other block
  Create metadump file, restore it and check restored fs
 +xfs_mdrestore: Invalid superblock disk address/length
 +mount: /opt: can't read superblock on /dev/loop0.
 +       dmesg(1) may have more information after failed mount system call.
 +mount /dev/loop0 /opt failed
 +(see /run/fstests/logs/xfs/129.full for details)

This is a failure to restore a v2 metadump to /dev/loop0.  Looking at
the metadump itself, the first xfs_meta_extent contains:

{
	.xme_addr = 0,
	.xme_len = 8,
}

Hrm.  This is the primary superblock on the data device, with a length
of 8x512B = 4K.  The original filesystem has this geometry:

# xfs_info /dev/sda4
meta-data=/dev/sda4              isize=512    agcount=4, agsize=2183680 blks
         =                       sectsz=4096  attr=2, projid32bit=1

In other words, a sector size of 4k because the device's LBA size is 4k.
Regrettably, the metadump validation in mdrestore assumes that the
primary superblock is only 512 bytes long, which is not correct for this
scenario.

Fix this by allowing an xme_len value of up to the maximum sector size
for xfs, which is 32k.  Also remove a redundant and confusing mask check
for the xme_addr.

Note that this error was masked (at least on little-endian platforms
that most of us test on) until recent commit 98f05de13e7815 ("mdrestore:
fix restore_v2() superblock length check") which is why I didn't spot it
earlier.

Cc: <linux-xfs@vger.kernel.org> # v6.6.0
Fixes: fa9f484b79123c ("mdrestore: Define mdrestore ops for v2 format")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 mdrestore/xfs_mdrestore.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)


diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
index b6e8a6196a795a..90908fe0ff6c2c 100644
--- a/mdrestore/xfs_mdrestore.c
+++ b/mdrestore/xfs_mdrestore.c
@@ -437,13 +437,21 @@ restore_v2(
 	if (fread(&xme, sizeof(xme), 1, md_fp) != 1)
 		fatal("error reading from metadump file\n");
 
-	if (xme.xme_addr != 0 || be32_to_cpu(xme.xme_len) != 1 ||
-	    (be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK) !=
-			XME_ADDR_DATA_DEVICE)
-		fatal("Invalid superblock disk address/length\n");
+	/*
+	 * The first block must be the primary super, which is at the start of
+	 * the data device, which is device 0.
+	 */
+	if (xme.xme_addr != 0)
+		fatal("Invalid superblock disk address 0x%llx\n",
+				be64_to_cpu(xme.xme_addr));
 
 	len = BBTOB(be32_to_cpu(xme.xme_len));
 
+	/* The primary superblock is always a single filesystem sector. */
+	if (len < BBTOB(1) || len > XFS_MAX_SECTORSIZE)
+		fatal("Invalid superblock disk length 0x%x\n",
+				be32_to_cpu(xme.xme_len));
+
 	if (fread(block_buffer, len, 1, md_fp) != 1)
 		fatal("error reading from metadump file\n");
 

Re: [PATCH 4/5] xfs_mdrestore: fix restoration on filesystems with 4k sectors

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 5/5] debian: don't explicitly reload systemd from postinst

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Now that we use dh_installsystemd, it's no longer necessary to run
systemctl daemon-reload explicitly from postinst because
dh_installsystemd will inject that into the DEBHELPER section on its
own.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 debian/postinst |    3 ---
 1 file changed, 3 deletions(-)


diff --git a/debian/postinst b/debian/postinst
index 2ad9174658ceb4..d11c8d94a3cbe4 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -8,9 +8,6 @@ case "${1}" in
 		then
 			update-initramfs -u
 		fi
-		if [ -x /bin/systemctl ]; then
-			/bin/systemctl daemon-reload 2>&1 || true
-		fi
 		;;
 
 	abort-upgrade|abort-remove|abort-deconfigure)

Re: [PATCH 5/5] debian: don't explicitly reload systemd from postinst

[Christoph Hellwig]

On Tue, Jan 20, 2026 at 09:51:51AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Now that we use dh_installsystemd, it's no longer necessary to run
> systemctl daemon-reload explicitly from postinst because
> dh_installsystemd will inject that into the DEBHELPER section on its
> own.

I take your word for it, and given that the removal is obviously correct
:)

Reviewed-by: Christoph Hellwig <hch@lst.de>