On 2/25/22 8:54 PM, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@xxxxxxxxxx>
...
> Hence we increase the ratio by 16x because there doesn't seem to be much
> improvement beyond that, and we don't want the log to grow /too/ large.
> This change does not affect filesystems larger than 4TB, nor does it
> affect formatting to older formats.
>
> Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> ---
> mkfs/xfs_mkfs.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> index 96682f9a..7178d798 100644
> --- a/mkfs/xfs_mkfs.c
> +++ b/mkfs/xfs_mkfs.c
> @@ -3308,7 +3308,17 @@ _("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)) {
> + if (cfg->sb_feat.bigtime) {
I'm not very keen on conditioning this on bigtime; it seems very ad-hoc and
unexpected. Future maintainers will look at this and wonder why bigtime is
in any way related to log size...
If we make this change, why not just make it regardless of other features?
Is there some other risk to doing so?
Thanks,
-Eric
> + /*
> + * Starting with bigtime, everybody gets a 256:1 ratio
> + * of fs size to log size unless they say otherwise.
> + * Larger logs reduce contention for log grant space,
> + * which is now a problem with the advent of small
> + * non-rotational storage devices.
> + */
> + cfg->logblocks = (cfg->dblocks << cfg->blocklog) / 256;
> + cfg->logblocks = cfg->logblocks >> cfg->blocklog;
> + } else 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)) {
>
