Re: [PATCH 19/17] mkfs: increase default log size for new (aka bigtime) filesystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 28, 2022 at 03:44:29PM -0600, Eric Sandeen wrote:
> 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?

I wrote it this way to leave the formatting behavior unchanged on older
filesystems, figuring that you'd be wary of anything that could generate
bug reports about old fs formats, e.g. "Why does my cloud deployment
image generator report that the minified filesystem size went up when I
went from X to X+1?"

So now that I've guessed incorrectly, I guess I'll go change this to do
it unconditionally.  Or drop the whole thing entirely.  I don't know.
I'm too burned out to be able to think reasonably anymore.

Frankly, I don't have the time to prove beyond a reasonable doubt that
this the problem is exactly as stated, that the code change is exactly
the correct fix, that no other fix is more appropriate, and that there
are no other possible explanations for the slowness being complained
aobut.  I really just wanted to do this one little thing that we've all
basically agreed is the right thing.

Instead I'll just leave things as they are, and consider whether there
even is a future for me working on XFS.

--D

> 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)) {
> > 



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux