All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: Re: mkfs.xfs "concurrency" change concerns
Date: Mon, 15 Jun 2026 07:19:22 -0700	[thread overview]
Message-ID: <ajAJ6lXJWcko4epj@infradead.org> (raw)
In-Reply-To: <84c8a5e5-938d-4745-996d-4237009c9cc5@sandeen.net>

On Thu, Oct 09, 2025 at 03:13:47PM -0500, Eric Sandeen wrote:
> Hey all -
> 
> this got long, so tl;dr:
> 
> 1) concurrency geometry breaks some xfstests for me
> 2) concurrency behavior is not consistent w/ loopback vs. imagefile
> 3) concurrency defaults to the mkfs machine not the mount machine
> 
> In detail:
> 
> So, I realize I'm late to the game here and didn't review the patches
> before they went in, but it looks like the "concurrency" mkfs.xfs
> arguments and defaults are breaking several xfstests.
> 
> 4738ff0 mkfs: allow sizing realtime allocation groups for concurrency
> c02a1873 mkfs: allow sizing internal logs for concurrency
> 9338bc8b mkfs: allow sizing allocation groups for concurrency
> 
> Specifically, xfs/078, xfs/216, and xfs/217 are failing for us
> on various machines with between 8 and 128 CPUS, due to the
> fundamental change in geometry that results from the new
> concurrency behavior, which makes any consistent golden
> output that involves geometry details quite difficult.

Did anything ever come out of this?  We're hitting errors in exactly
those tests in the zoned XFS CI (which also tests regular XFS).
Shin'ichiro recently spent some time tracking these down, which
finally made me remember this thread.


  parent reply	other threads:[~2026-06-15 14:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-09 20:13 mkfs.xfs "concurrency" change concerns Eric Sandeen
2025-10-10  5:17 ` Christoph Hellwig
2025-10-10 19:17 ` Darrick J. Wong
2025-10-10 19:34   ` Darrick J. Wong
2025-10-10 20:47   ` Eric Sandeen
2025-10-14  2:32     ` Darrick J. Wong
2025-10-14 15:36       ` Eric Sandeen
2025-10-17 22:46         ` Darrick J. Wong
2025-10-18 15:01           ` Eric Sandeen
2026-06-15 14:19 ` Christoph Hellwig [this message]
2026-06-15 15:24   ` Eric Sandeen
2026-06-15 15:40   ` Darrick J. Wong
2026-06-16  5:24     ` Christoph Hellwig

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=ajAJ6lXJWcko4epj@infradead.org \
    --to=hch@infradead.org \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=shinichiro.kawasaki@wdc.com \
    /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.