From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Cc: john.g.garry@oracle.com
Subject: [PATCH 0/5] xfs: allocation alignment for forced alignment
Date: Wed, 3 Apr 2024 10:28:39 +1100 [thread overview]
Message-ID: <20240402233006.1210262-1-david@fromorbit.com> (raw)
This patchset prepares the allocator infrastructure for extent size
hint alignment to guarantee alignment of extents rather than just be
a hint.
Extent alignment is currently driven by multiple variables that come
from different sources and are applied at different times. Stripe
alignment currently defines the extent start alignment, whilst
extent size hints only affect the extent length and not the start
alignment. There are also assumptions about alignment of allocation
parameters (such as the maximum length of the allocation) and if
these aren't followed the extent size hints don't actually trim
extents properly.
This patch set aims to unify alignment entirely via args->alignment
and args->prod/args->mod. Alignment at both ends of the extent
should always occur when the free space selected allows for start
alignment of an extent that is at least args->minlen in length.
Hence we need to modify args->alignment setup to take into account
extent size hints in addition to stripe alignment, and we need to
ensure that extent length is always aligned to extent size hints,
even if it means we cannot do a args->maxlen allocation.
This means that only when we completely fail to find aligned free
space to allocate from will extent size hints no longer be start
aligned. They will continue to be tail aligned up until we run out
of contiguous free space extents large enough to hold an extent the
size of a hint. Hence there is no real change of behaviour for
extent size hints; they will simply prefer aligned allocations
first, then naturally fall back to the current unaligned hint sized
allocation strategy.
Unifying the allocation alignment stratgies simplifies the code,
too. It means that the only time we don't align allocation is when
trying to do contiguous allocation when extending the file (which
should already be aligned if alignment is required!) or when there
are no alignment constraints to begin with. As a result, we can
simplify the allocation failure fallback strategies and make the
code easier to understand and follow.
Finally, we introduce a stub for force aligned allocation and add
the logic fail the allocation if aligned allocation cannot be done.
This has run through fstests for some time here without inducing new
failures or causing any obvious near-ENOSPC performance regressions.
next reply other threads:[~2024-04-02 23:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 23:28 Dave Chinner [this message]
2024-04-02 23:28 ` [PATCH 1/5] xfs: only allow minlen allocations when near ENOSPC Dave Chinner
2024-04-03 16:31 ` John Garry
2024-04-03 23:15 ` Dave Chinner
2024-04-04 13:54 ` John Garry
2024-04-02 23:28 ` [PATCH 2/5] xfs: always tail align maxlen allocations Dave Chinner
2024-04-02 23:28 ` [PATCH 3/5] xfs: simplify extent allocation alignment Dave Chinner
2024-04-02 23:28 ` [PATCH 4/5] xfs: make EOF allocation simpler Dave Chinner
2024-04-02 23:28 ` [PATCH 5/5] xfs: introduce forced allocation alignment Dave Chinner
2024-04-10 12:44 ` [PATCH 0/5] xfs: allocation alignment for forced alignment John Garry
2024-04-16 0:38 ` Dave Chinner
2024-04-16 6:51 ` John Garry
2024-04-29 14:06 ` John Garry
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=20240402233006.1210262-1-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=john.g.garry@oracle.com \
--cc=linux-xfs@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).