All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: zlang@redhat.com, fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/7] generic/427: try to ensure there's some free space before we do the aio test
Date: Tue, 12 Aug 2025 23:14:52 -0700	[thread overview]
Message-ID: <20250813061452.GC7981@frogsfrogsfrogs> (raw)
In-Reply-To: <aJwfiw9radbDZq-p@infradead.org>

On Tue, Aug 12, 2025 at 10:15:55PM -0700, Christoph Hellwig wrote:
> On Tue, Aug 12, 2025 at 11:54:59AM -0700, Darrick J. Wong wrote:
> > On Wed, Jul 30, 2025 at 07:18:48AM -0700, Christoph Hellwig wrote:
> > > On Tue, Jul 29, 2025 at 01:08:46PM -0700, Darrick J. Wong wrote:
> > > > The pwrite failure comes from the aio-dio-eof-race.c program because the
> > > > filesystem ran out of space.  There are no speculative posteof
> > > > preallocations on a zoned filesystem, so let's skip this test on those
> > > > setups.
> > > 
> > > Did it run out of space because it is overwriting and we need a new
> > > allocation (I've not actually seen this fail in my zoned testing,
> > > that's why I'm asking)?  If so it really should be using the new
> > > _require_inplace_writes Filipe just sent to the list.
> > 
> > I took a deeper look into what's going on here, and I think the
> > intermittent ENOSPC failures are caused by:
> > 
> > 1. First we write to every byte in the 256M zoned rt device so that
> >    0x55 gets written to the disk.
> > 2. Then we delete the huge file we created.
> > 3. The zoned garbage collector doesn't run.
> > 4. aio-dio-eof-race starts up and initiates an aiodio at pos 0.
> > 5. xfs_file_dio_write_zoned calls xfs_zoned_write_space_reserve
> > 6. xfs_zoned_space_reserve tries to decrement 64k from XC_FREE_RTEXTENTS
> >    but gets ENOSPC.
> > 7. We didn't pass XFS_ZR_GREEDY, so we error out.
> > 
> > If I make the test sleep until I see zonegc do some work before starting
> > aio-dio-eof-race, the problem goes away.  I'm not sure what the proper
> > solution is, but maybe it's adding a wake_up to the gc process and
> > waiting for it?
> 
> Isn't the problem here that zonegc only even sees the freed block
> after inodegc did run?  i.e. after 2 the inode hasn't been truncated
> yet, and thus the blocks haven't been marked as free.

Yeah... for the other ENOSPC-on-write paths, we kick inodegc, so maybe
xfs_zoned_space_reserve (or its caller, more likely) ought to do that
too?

--D

  reply	other threads:[~2025-08-13  6:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-29 20:08 [PATCHSET 1/3] fstests: fixes for atomic writes tests Darrick J. Wong
2025-07-29 20:08 ` [PATCH 2/7] generic/427: try to ensure there's some free space before we do the aio test Darrick J. Wong
2025-07-30 14:18   ` Christoph Hellwig
2025-08-12 18:54     ` Darrick J. Wong
2025-08-13  5:15       ` Christoph Hellwig
2025-08-13  6:14         ` Darrick J. Wong [this message]
2025-08-13  6:24           ` Christoph Hellwig
2025-08-14 22:16             ` Darrick J. Wong
2025-08-18  4:37               ` Christoph Hellwig
2025-07-29 20:09 ` [PATCH 3/7] generic/767: require fallocate support Darrick J. Wong
2025-07-30 14:19   ` Christoph Hellwig
2025-08-04  7:38   ` John Garry
2025-07-29 20:09 ` [PATCH 4/7] generic/767: only test the hardware atomic write unit Darrick J. Wong
2025-07-30 14:19   ` Christoph Hellwig
2025-08-04  7:41   ` John Garry
2025-07-29 20:09 ` [PATCH 5/7] generic/767: allow on any atomic writes filesystem Darrick J. Wong
2025-08-01 18:56   ` Zorro Lang
2025-08-04  7:50   ` John Garry
2025-07-29 20:09 ` [PATCH 6/7] xfs/838: actually force usage of the realtime device Darrick J. Wong
2025-07-30 14:19   ` Christoph Hellwig
2025-08-04  8:02   ` John Garry
2025-07-29 20:10 ` [PATCH 7/7] common: fix _require_xfs_io_command pwrite -A for various blocksizes Darrick J. Wong
2025-08-01 18:53   ` Zorro Lang
2025-08-27 18:04     ` Darrick J. Wong
2025-08-04  8:07   ` John Garry
2025-08-01  6:19 ` [PATCHSET 1/3] fstests: fixes for atomic writes tests Zorro Lang

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=20250813061452.GC7981@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.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.