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) {
next prev parent 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).