From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: John Garry <john.g.garry@oracle.com>,
chandan.babu@oracle.com, dchinner@redhat.com, hch@lst.de,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, catherine.hoang@oracle.com,
martin.petersen@oracle.com
Subject: Re: [PATCH v3 03/14] xfs: simplify extent allocation alignment
Date: Wed, 7 Aug 2024 09:52:06 +1000 [thread overview]
Message-ID: <ZrK3JlJIV5j4h44F@dread.disaster.area> (raw)
In-Reply-To: <20240806185651.GG623936@frogsfrogsfrogs>
On Tue, Aug 06, 2024 at 11:56:51AM -0700, Darrick J. Wong wrote:
> On Thu, Aug 01, 2024 at 04:30:46PM +0000, John Garry wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > We currently align extent allocation to stripe unit or stripe width.
> > That is specified by an external parameter to the allocation code,
> > which then manipulates the xfs_alloc_args alignment configuration in
> > interesting ways.
> >
> > The args->alignment field specifies extent start alignment, but
> > because we may be attempting non-aligned allocation first there are
> > also slop variables that allow for those allocation attempts to
> > account for aligned allocation if they fail.
> >
> > This gets much more complex as we introduce forced allocation
> > alignment, where extent size hints are used to generate the extent
> > start alignment. extent size hints currently only affect extent
> > lengths (via args->prod and args->mod) and so with this change we
> > will have two different start alignment conditions.
> >
> > Avoid this complexity by always using args->alignment to indicate
> > extent start alignment, and always using args->prod/mod to indicate
> > extent length adjustment.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > [jpg: fixup alignslop references in xfs_trace.h and xfs_ialloc.c]
> > Signed-off-by: John Garry <john.g.garry@oracle.com>
>
> Going back to the 6/21 posting[1], what were the answers to the
> questions I posted? Did I correctly figure out what alignslop refers
> to?
Hard to say.
alignslop is basically an temporary accounting mechanism used to
prevent filesystem shutdowns when the AG is near ENOSPC and exact
BNO allocation is attempted and fails because there isn't an exact
free space available. This exact bno allocation attempt can dirty
the AGFL, and before we dirty the transaction *we must guarantee the
allocation will succeed*. If the allocation fails after we've
started modifying metadata (for whatever reason) we will cancel a
dirty transaction and shut down the filesystem.
Hence the first allocation done from the xfs_bmap_btalloc() context
needs to account for every block the specific allocation and all the
failure fallback attempts *may require* before it starts modifying
metadata. The contiguous exact bno allocation case isn't an aligned
allocation, but it will be followed by an aligned allocation attempt
if it fails and so it must take into account the space requirements
of aligned allocation even though it is not an aligned allocation
itself.
args->alignslop allows xfs_alloc_space_available() to take this
space requirement into account for any allocation that has lesser
alignment requirements than any subsequent allocation attempt that
may follow if this specific allocation attempt fails.
IOWs, args->alignslop is similar to args->minleft and args->total in
purpose, but it only affects the accounting for this specific
allocation attempt rather than defining the amount of space
that needs to remain available at the successful completion of this
allocation for future allocations within this transaction context.
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-08-06 23:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 16:30 [PATCH v3 00/14] forcealign for xfs John Garry
2024-08-01 16:30 ` [PATCH v3 01/14] xfs: only allow minlen allocations when near ENOSPC John Garry
2024-08-06 18:51 ` Darrick J. Wong
2024-08-07 0:26 ` Dave Chinner
2024-08-01 16:30 ` [PATCH v3 02/14] xfs: always tail align maxlen allocations John Garry
2024-08-13 15:01 ` John Garry
2024-08-01 16:30 ` [PATCH v3 03/14] xfs: simplify extent allocation alignment John Garry
2024-08-06 18:56 ` Darrick J. Wong
2024-08-06 23:52 ` Dave Chinner [this message]
2024-08-07 0:23 ` Darrick J. Wong
2024-08-07 0:34 ` Dave Chinner
2024-08-01 16:30 ` [PATCH v3 04/14] xfs: make EOF allocation simpler John Garry
2024-08-06 18:58 ` Darrick J. Wong
2024-08-07 0:00 ` Dave Chinner
2024-08-07 0:24 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 05/14] xfs: introduce forced allocation alignment John Garry
2024-08-01 16:30 ` [PATCH v3 06/14] xfs: align args->minlen for " John Garry
2024-08-01 16:30 ` [PATCH v3 07/14] xfs: Introduce FORCEALIGN inode flag John Garry
2024-08-06 19:02 ` Darrick J. Wong
2024-08-07 11:42 ` John Garry
2024-08-07 14:40 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 08/14] xfs: Update xfs_inode_alloc_unitsize() for forcealign John Garry
2024-08-06 19:02 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 09/14] xfs: Update xfs_setattr_size() " John Garry
2024-08-06 19:03 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 10/14] xfs: Do not free EOF blocks " John Garry
2024-08-06 19:24 ` Darrick J. Wong
2024-08-07 12:33 ` John Garry
2024-08-07 15:12 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 11/14] xfs: Only free full extents " John Garry
2024-08-06 19:27 ` Darrick J. Wong
2024-08-07 0:08 ` Dave Chinner
2024-08-07 13:06 ` John Garry
2024-08-01 16:30 ` [PATCH v3 12/14] xfs: Unmap blocks according to forcealign John Garry
2024-08-06 20:14 ` Darrick J. Wong
2024-08-07 13:40 ` John Garry
2024-08-07 16:19 ` Darrick J. Wong
2024-08-01 16:30 ` [PATCH v3 13/14] xfs: Don't revert allocated offset for forcealign John Garry
2024-08-01 16:30 ` [PATCH v3 14/14] xfs: Enable file data forcealign feature John Garry
2024-08-06 19:43 ` Darrick J. Wong
2024-08-07 13:50 ` John Garry
2024-08-07 15:17 ` Darrick J. Wong
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=ZrK3JlJIV5j4h44F@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/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