Mounting xfs filesystem takes long time
diff mbox

Message ID 20180627232333.GB21242@wotan.suse.de
State New
Headers show

Commit Message

Luis Chamberlain June 27, 2018, 11:23 p.m. UTC
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?

--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Eric Sandeen June 27, 2018, 11:37 p.m. UTC | #1
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) {
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner June 28, 2018, 2:05 a.m. UTC | #2
On Wed, Jun 27, 2018 at 06:37:31PM -0500, Eric Sandeen wrote:
> 
> 
> 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.

IMO, this belongs in the admin documentation (e.g. the growfs man
page), not the code. The people writing apps and automated
deployment scripts that grow filesystems need to know about this,
not the end users who simply use these pre-canned
apps/environments...

Cheers,

Dave.
Carlos Maiolino June 28, 2018, 8:19 a.m. UTC | #3
On Thu, Jun 28, 2018 at 12:05:04PM +1000, Dave Chinner wrote:
> On Wed, Jun 27, 2018 at 06:37:31PM -0500, Eric Sandeen wrote:
> > 
> > 
> > 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.
> 

Agreed. The biggest issue here is the amount of AGs, not the filesystem size
directly, which, for this to work in a reliable way, we'd need to store the
'original' AG count from when the FS was created, otherwise, as Eric stated,
nothing prevents somebody to use growfs several times, instead of growing the FS
in a single time.

Although, this makes me wonder if we somehow couldn't make it a bit more
flexible in the future, but I think that's where Dave's subvolume work comes in?


> IMO, this belongs in the admin documentation (e.g. the growfs man
> page), not the code. The people writing apps and automated
> deployment scripts that grow filesystems need to know about this,
> not the end users who simply use these pre-canned
> apps/environments...
> 

+1, most people who will look into the code already know this, users of grow FS
doesn't, so this belongs to the man page IMHO.

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

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