linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Eric Sandeen <sandeen@sandeen.net>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	"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: Thu, 28 Jun 2018 01:23:33 +0200	[thread overview]
Message-ID: <20180627232333.GB21242@wotan.suse.de> (raw)
In-Reply-To: <20180622040221.GY19934@dastard>

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?

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:23 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 [this message]
2018-06-27 23:37                   ` Eric Sandeen
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=20180627232333.GB21242@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=sandeen@sandeen.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).