public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Zorro Lang <zlang@kernel.org>,
	fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: add a test that zoned file systems with rump RTG can't be mounted
Date: Tue, 16 Dec 2025 06:12:05 +0100	[thread overview]
Message-ID: <20251216051205.GB26237@lst.de> (raw)
In-Reply-To: <20251215193345.GM7725@frogsfrogsfrogs>

On Mon, Dec 15, 2025 at 11:33:45AM -0800, Darrick J. Wong wrote:
> > +_scratch_mkfs > /dev/null 2>&1
> > +blocks=$(_scratch_xfs_db -c 'sb 0' -c 'print rblocks' | awk '{print $3}')
> > +blocks=$((blocks - 4096))
> > +_scratch_xfs_db -x -c 'sb 0' -c "write -d rblocks $blocks" > /dev/null 2>&1
> > +_scratch_xfs_db -x -c 'sb 0' -c "write -d rextents $blocks" > /dev/null 2>&1
> 
> You could put both of the write commands in the same invocation, e.g.
> 
> _scratch_xfs_db -x \
> 	-c 'sb 0' \
> 	-c "write -d rblocks $blocks" \
> 	-c "write -d rextents $blocks" > /dev/null 2>&1
> 
> For a little bit lower runtime.

I can do that, but I doubt it really matters..

> > +if _try_scratch_mount >/dev/null 2>&1; then
> > +	# for non-zoned file systems this can succeed just fine
> > +	_require_xfs_scratch_non_zoned
> 
> The logic in this test looks fine to me, but I wonder: have you (or
> anyone else) gone to Debian 13 and noticed this:
> 
> # mount /dev/sda /mnt
> # mount /dev/sda /mnt
> # grep /mnt /proc/mounts
> /dev/sda /mnt xfs rw,relatime,inode64,logbufs=8,logbsize=32k,noquota 0 0
> /dev/sda /mnt xfs rw,relatime,inode64,logbufs=8,logbsize=32k,noquota 0 0
> 
> It looks like util-linux switched to the new fsopen mount API between
> Debian 12 and 13, and whereas the old mount(8) would fail if the fs was
> already mounted, the new one just creates two mounts, which both then
> must be unmounted.  So now I'm hunting around for unbalanced
> mount/unmount pairs in fstests. :(

The old mount API also supported that at the syscall level, but it got
disable in mount(8), so if mount now does this and previously didn't it
seems like an unintended change.


  reply	other threads:[~2025-12-16  5:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15  9:50 various tests for zone aligned RT subvolumes Christoph Hellwig
2025-12-15  9:50 ` [PATCH 1/3] xfs: add a test that zoned file systems with rump RTG can't be mounted Christoph Hellwig
2025-12-15 19:33   ` Darrick J. Wong
2025-12-16  5:12     ` Christoph Hellwig [this message]
2025-12-16 19:05       ` Darrick J. Wong
2025-12-15  9:50 ` [PATCH 2/3] xfs: test that RT growfs not aligned to zone size fails Christoph Hellwig
2025-12-15 19:28   ` Darrick J. Wong
2025-12-16  5:12     ` Christoph Hellwig
2025-12-15  9:50 ` [PATCH 3/3] xfs: add a test that mkfs round up realtime subvolume sizes to the zone size Christoph Hellwig
2025-12-15 19:25   ` Darrick J. Wong
2025-12-16  5:13     ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2025-12-18 16:10 various tests for zone aligned RT subvolumes v2 Christoph Hellwig
2025-12-18 16:10 ` [PATCH 1/3] xfs: add a test that zoned file systems with rump RTG can't be mounted Christoph Hellwig
2025-12-19  2:12   ` Darrick J. Wong
2025-12-19  5:26     ` Christoph Hellwig
2025-12-19  5:35 various tests for zone aligned RT subvolumes v3 Christoph Hellwig
2025-12-19  5:35 ` [PATCH 1/3] xfs: add a test that zoned file systems with rump RTG can't be mounted 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=20251216051205.GB26237@lst.de \
    --to=hch@lst.de \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@kernel.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