From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org, allison.henderson@oracle.com
Subject: Re: [PATCH 3/5] mkfs: increase the minimum log size to 64MB when possible
Date: Fri, 25 Mar 2022 15:08:00 -0700 [thread overview]
Message-ID: <20220325220800.GV8224@magnolia> (raw)
In-Reply-To: <bdb3d82d-23f7-8f52-299f-5913c79fde93@sandeen.net>
On Fri, Mar 25, 2022 at 07:48:08AM -1000, Eric Sandeen wrote:
> Darrick, it bugged me a bit that the way this patch worked was to go through
> one set of calculations to sort out a log size, then throw in a new heuristic
> or two to change that result. And TBH the 7/8 bit seems very ad hoc when
> we already had the prior 95% heuristic.
>
> While I know that most of this goes away by the last patch, I'm considering
> deferring patches 4 & 5 for the next release because of the impact on
> fstests, so would like to land somewhere clean by patch 3.
>
> What do you think of this patch as a replacement for this patch 3/5? It's a
> bit clearer to me, and results in (almost) the same net results as your patch,
> with minor differences around 512MB filesystems due to the removal of the
> 7/8 limit.
>
> Depending on what you think, I can tweak your commit log as needed, leave
> your authorship, and add a:
>
> [sandeen: consolidate heuristics into something a bit more clear]
>
> or something like that... or, claim authorship (and all ensuing bugs) ;)
Man, my email is slow today!
This looks ok to me, though at this point you've basically reauthored
the whole thing. You might as well own it and add:
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
>
> Thanks,
> -Eric
>
> diff --git a/include/xfs_multidisk.h b/include/xfs_multidisk.h
> index a16a9fe2..ef4443b0 100644
> --- a/include/xfs_multidisk.h
> +++ b/include/xfs_multidisk.h
> @@ -17,8 +17,6 @@
> #define XFS_MIN_INODE_PERBLOCK 2 /* min inodes per block */
> #define XFS_DFL_IMAXIMUM_PCT 25 /* max % of space for inodes */
> #define XFS_MIN_REC_DIRSIZE 12 /* 4096 byte dirblocks (V2) */
> -#define XFS_DFL_LOG_FACTOR 5 /* default log size, factor */
> - /* with max trans reservation */
> #define XFS_MAX_INODE_SIG_BITS 32 /* most significant bits in an
> * inode number that we'll
> * accept w/o warnings
> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> index ad776492..cf1d64a2 100644
> --- a/mkfs/xfs_mkfs.c
> +++ b/mkfs/xfs_mkfs.c
> @@ -18,6 +18,14 @@
> #define GIGABYTES(count, blog) ((uint64_t)(count) << (30 - (blog)))
> #define MEGABYTES(count, blog) ((uint64_t)(count) << (20 - (blog)))
>
> +/*
> + * Realistically, the log should never be smaller than 64MB. Studies by the
> + * kernel maintainer in early 2022 have shown a dramatic reduction in long tail
> + * latency of the xlog grant head waitqueue when running a heavy metadata
> + * update workload when the log size is at least 64MB.
> + */
> +#define XFS_MIN_REALISTIC_LOG_BLOCKS(blog) (MEGABYTES(64, (blog)))
> +
> /*
> * Use this macro before we have superblock and mount structure to
> * convert from basic blocks to filesystem blocks.
> @@ -3297,7 +3305,7 @@ calculate_log_size(
> struct xfs_mount *mp)
> {
> struct xfs_sb *sbp = &mp->m_sb;
> - int min_logblocks;
> + int min_logblocks; /* absolute minimum */
> struct xfs_mount mount;
>
> /* we need a temporary mount to calculate the minimum log size. */
> @@ -3339,29 +3347,19 @@ _("external log device size %lld blocks too small, must be at least %lld blocks\
>
> /* internal log - if no size specified, calculate automatically */
> if (!cfg->logblocks) {
> - if (cfg->dblocks < GIGABYTES(1, cfg->blocklog)) {
> - /* tiny filesystems get minimum sized logs. */
> - cfg->logblocks = min_logblocks;
> - } else if (cfg->dblocks < GIGABYTES(16, cfg->blocklog)) {
> + /* Use a 2048:1 fs:log ratio for most filesystems */
> + cfg->logblocks = (cfg->dblocks << cfg->blocklog) / 2048;
> + cfg->logblocks = cfg->logblocks >> cfg->blocklog;
>
> - /*
> - * For small filesystems, we want to use the
> - * XFS_MIN_LOG_BYTES for filesystems smaller than 16G if
> - * at all possible, ramping up to 128MB at 256GB.
> - */
> - cfg->logblocks = min(XFS_MIN_LOG_BYTES >> cfg->blocklog,
> - min_logblocks * XFS_DFL_LOG_FACTOR);
> - } else {
> - /*
> - * With a 2GB max log size, default to maximum size
> - * at 4TB. This keeps the same ratio from the older
> - * max log size of 128M at 256GB fs size. IOWs,
> - * the ratio of fs size to log size is 2048:1.
> - */
> - cfg->logblocks = (cfg->dblocks << cfg->blocklog) / 2048;
> - cfg->logblocks = cfg->logblocks >> cfg->blocklog;
> - }
> + /* But don't go below a reasonable size */
> + cfg->logblocks = max(cfg->logblocks,
> + XFS_MIN_REALISTIC_LOG_BLOCKS(cfg->blocklog));
> +
> + /* And for a tiny filesystem, use the absolute minimum size */
> + if (cfg->dblocks < MEGABYTES(512, cfg->blocklog))
> + cfg->logblocks = min_logblocks;
>
> + /* Enforce min/max limits */
> clamp_internal_log_size(cfg, mp, min_logblocks);
>
> validate_log_size(cfg->logblocks, cfg->blocklog, min_logblocks);
>
>
next prev parent reply other threads:[~2022-03-25 22:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 23:23 [PATCHSET 0/5] xfsprogs: stop allowing tiny filesystems Darrick J. Wong
2022-03-15 23:23 ` [PATCH 1/5] mkfs: hoist the internal log size clamp code Darrick J. Wong
2022-03-16 18:18 ` Eric Sandeen
2022-03-15 23:23 ` [PATCH 2/5] mkfs: don't let internal logs consume more than 95% of an AG Darrick J. Wong
2022-03-16 18:50 ` Eric Sandeen
2022-03-31 5:21 ` Eric Sandeen
2022-03-31 16:20 ` Darrick J. Wong
2022-03-15 23:23 ` [PATCH 3/5] mkfs: increase the minimum log size to 64MB when possible Darrick J. Wong
2022-03-16 19:27 ` Eric Sandeen
2022-03-25 17:48 ` Eric Sandeen
2022-03-25 22:08 ` Darrick J. Wong [this message]
2022-03-15 23:23 ` [PATCH 4/5] mkfs: stop allowing tiny filesystems Darrick J. Wong
2022-03-15 23:23 ` [PATCH 5/5] mkfs: simplify the default log size ratio computation 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=20220325220800.GV8224@magnolia \
--to=djwong@kernel.org \
--cc=allison.henderson@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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.