From: "Darrick J. Wong" <djwong@kernel.org>
To: cem@kernel.org, djwong@kernel.org
Cc: bodonnel@redhat.com, hch@lst.de, linux-xfs@vger.kernel.org
Subject: [GIT PULL 08/11] mkfs: scale shards on ssds
Date: Wed, 17 Apr 2024 15:09:25 -0700 [thread overview]
Message-ID: <171339161075.1911630.9987481844220519797.stg-ugh@frogsfrogsfrogs> (raw)
In-Reply-To: <20240417220440.GB11948@frogsfrogsfrogs>
Hi Carlos,
Please pull this branch with changes for xfsprogs for 6.6-rc1.
As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts. Please let me know if you
encounter any problems.
The following changes since commit 53bf0604e104bc053778495faef94b3570582aac:
mkfs: use a sensible log sector size default (2024-04-17 14:06:27 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git tags/mkfs-scale-geo-on-ssds-6.8_2024-04-17
for you to fetch changes up to c02a18733fc0a0e1b607f75e90962b3adc27c8fa:
mkfs: allow sizing internal logs for concurrency (2024-04-17 14:06:27 -0700)
----------------------------------------------------------------
mkfs: scale shards on ssds [08/20]
For a long time, the maintainers have had a gut feeling that we could
optimize performance of XFS filesystems on non-mechanical storage by
scaling the number of allocation groups to be a multiple of the CPU
count.
With modern ~2022 hardware, it is common for systems to have more than
four CPU cores and non-striped SSDs ranging in size from 256GB to 4TB.
The default mkfs geometry still defaults to 4 AGs regardless of core
count, which was settled on in the age of spinning rust.
This patchset adds a different computation for AG count and log size
that is based entirely on a desired level of concurrency. If we detect
storage that is non-rotational (or the sysadmin provides a CLI option),
then we will try to match the AG count to the CPU count to minimize AGF
contention and make the log large enough to minimize grant head
contention.
This has been running on the djcloud for months with no problems. Enjoy!
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
----------------------------------------------------------------
Darrick J. Wong (2):
mkfs: allow sizing allocation groups for concurrency
mkfs: allow sizing internal logs for concurrency
man/man8/mkfs.xfs.8.in | 46 +++++++++
mkfs/xfs_mkfs.c | 251 +++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 291 insertions(+), 6 deletions(-)
next prev parent reply other threads:[~2024-04-17 22:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 22:04 [GIT PULLBOMB] xfsprogs: catch us up to 6.8, at least Darrick J. Wong
2024-04-17 22:07 ` [GIT PULL 01/11] xfsprogs: packaging fixes for 6.7 Darrick J. Wong
2024-04-18 4:31 ` Christoph Hellwig
2024-04-22 9:56 ` Carlos Maiolino
2024-04-17 22:07 ` [GIT PULL 02/11] xfsprogs: minor " Darrick J. Wong
2024-04-17 22:08 ` [GIT PULL 03/11] xfsprogs: convert utilities to use new rt helpers Darrick J. Wong
2024-04-17 22:08 ` [GIT PULL 04/11] libxfs: sync with 6.8 Darrick J. Wong
2024-04-17 22:08 ` [GIT PULL 05/11] xfs_repair: faster btree bulkloading Darrick J. Wong
2024-04-17 22:08 ` [GIT PULL 06/11] xfsprogs: bug fixes for 6.8 Darrick J. Wong
2024-04-17 22:09 ` [GIT PULL 07/11] xfsprogs: fix log sector size detection Darrick J. Wong
2024-04-17 22:09 ` Darrick J. Wong [this message]
2024-04-17 22:09 ` [GIT PULL 09/11] xfs_scrub: scan metadata files in parallel Darrick J. Wong
2024-04-17 22:09 ` [GIT PULL 10/11] xfs_repair: rebuild inode fork mappings Darrick J. Wong
2024-04-17 22:10 ` [GIT PULL 11/11] xfs_repair: support more than 4 billion records 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=171339161075.1911630.9987481844220519797.stg-ugh@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bodonnel@redhat.com \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--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 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.