All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	Dave Chinner <david@fromorbit.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	"swadmin - levigo.de" <swadmin@levigo.de>,
	xfs list <linux-xfs@vger.kernel.org>
Subject: Re: Mounting xfs filesystem takes long time
Date: Wed, 27 Jun 2018 18:37:31 -0500	[thread overview]
Message-ID: <98c71f4a-94e5-00e8-46af-a4c3ca4e520b@sandeen.net> (raw)
In-Reply-To: <20180627232333.GB21242@wotan.suse.de>



On 6/27/18 6:23 PM, Luis R. Rodriguez wrote:
> On Fri, Jun 22, 2018 at 02:02:21PM +1000, Dave Chinner wrote:
>> On Thu, Jun 21, 2018 at 09:19:54PM -0600, Chris Murphy wrote:
>>> On Thu, Jun 21, 2018 at 4:19 PM, Dave Chinner <david@fromorbit.com> wrote:
>>>
>>>> The mkfs ratios are about as optimal as we can get for the
>>>> information we have about the storage - growing by
>>>> 10x (i.e.  increaseing the number of AGs by 10x) puts us at the
>>>> outside edge of the acceptible filesystem performance and longevity
>>>> charcteristics. Growing by 100x puts us way outside the window,
>>>> and examples like this where we are taking about growing by 10000x
>>>> is just way beyond anything the static AG layout architecture was
>>>> ever intended to support....
> 
> I don't  have time to test this but I can probably do so after my vacation
> (now). Would it be best to just codify this eventually instead of having
> this as tribal knowledge?

Honestly, if we wanted something like this I think it'd be based on terminal
AG count, not growfs multiplier for a specific instance.

Otherwise 100 consecutive 4x growfs's would yield the same problems without
tripping any of these tests.

-Eric

> diff --git a/growfs/xfs_growfs.c b/growfs/xfs_growfs.c
> index 8ec445afb74b..14f4b6dce08f 100644
> --- a/growfs/xfs_growfs.c
> +++ b/growfs/xfs_growfs.c
> @@ -75,6 +75,9 @@ main(int argc, char **argv)
>  	fs_path_t		*fs;	/* mount point information */
>  	libxfs_init_t		xi;	/* libxfs structure */
>  	char			rpath[PATH_MAX];
> +	int			fflag;	/* -f flag */
> +	long long		dsize_max_suggested; /* max suggested size */
> +	long long		dsize_max_arch; /* max design over flow */
>  
>  	progname = basename(argv[0]);
>  	setlocale(LC_ALL, "");
> @@ -93,6 +96,8 @@ main(int argc, char **argv)
>  		case 'd':
>  			dflag = 1;
>  			break;
> +		case 'f':
> +			fflag = 1;
>  		case 'e':
>  			esize = atol(optarg);
>  			rflag = 1;
> @@ -249,6 +254,24 @@ main(int argc, char **argv)
>  	if (dflag | mflag | aflag) {
>  		xfs_growfs_data_t	in;
>  
> +		/*
> +		 * Growing the filesyste by 10x increases the AG size by 10 as
> +		 * well, and this puts us outside edge of the acceptible
> +		 * filesystem performance and longevity charcteristics.
> +		 *
> +		 * Growing by 100x puts us way outside the window...
> +		 *
> +		 * Growing by 10000x is just way beyond anything the static AG
> +		 * layout architecture was ever intended to support, so unless
> +		 * you use -f, we won't allow in between 10x-1000x.
> +		 */
> +		dsize_max_suggested = ddsize * 10 / (geo.blocksize / BBSIZE);
> +		if (dsize_max_suggested < ddsize)
> +			dsize_max_suggested = ULLONG_MAX;
> +		dsize_max_arch = ddsize * 1000 / (geo.blocksize / BBSIZE);
> +		if (dsize_max_arch < ddsize)
> +			dsize_max_arch = ULLONG_MAX;
> +
>  		if (!mflag)
>  			maxpct = geo.imaxpct;
>  		if (!dflag && !aflag)	/* Only mflag, no data size change */
> @@ -261,6 +284,26 @@ main(int argc, char **argv)
>  				(long long)dsize,
>  				(long long)(ddsize/(geo.blocksize/BBSIZE)));
>  			error = 1;
> +		} else if (!fflag &&
> +			   dsize > dsize_max_arch) {
> +			fprintf(stderr, _(
> +				"data size %lld beyond what XFS recomends for "
> +				"this fs, max should be %lld but if used you "
> +				"will suffer. Max suggested is %lld or use "
> +				"-f to override.\n"),
> +				(long long)dsize,
> +				dsize_max_arch,
> +				dsize_max_suggested);
> +			error = 1;
> +		} else if (!fflag &&
> +			   dsize > dsize_max_suggested) {
> +			fprintf(stderr, _(
> +				"data size %lld beyond what XFS recomends for "
> +				"this fs, max suggested is %lld or use "
> +				"-f to override.\n"),
> +				(long long)dsize,
> +				dsize_max_suggested);
> +			error = 1;
>  		}
>  
>  		if (!error && dsize < geo.datablocks) {
> 

  reply	other threads:[~2018-06-27 23:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 12:27 Mounting xfs filesystem takes long time swadmin - levigo.de
2018-06-19 16:00 ` Emmanuel Florac
2018-06-19 16:18 ` Darrick J. Wong
2018-06-19 19:21   ` Eric Sandeen
2018-06-21 19:15     ` Luis R. Rodriguez
2018-06-21 19:19       ` Eric Sandeen
2018-06-21 21:50         ` Chris Murphy
2018-06-21 22:19           ` Dave Chinner
2018-06-22  3:19             ` Chris Murphy
2018-06-22  4:02               ` Dave Chinner
2018-06-27 23:23                 ` Luis R. Rodriguez
2018-06-27 23:37                   ` Eric Sandeen [this message]
2018-06-28  2:05                     ` Dave Chinner
2018-06-28  8:19                       ` Carlos Maiolino

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=98c71f4a-94e5-00e8-46af-a4c3ca4e520b@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=mcgrof@kernel.org \
    --cc=swadmin@levigo.de \
    /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.