From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
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: Thu, 28 Jun 2018 12:05:04 +1000 [thread overview]
Message-ID: <20180628020504.GC2234@dastard> (raw)
In-Reply-To: <98c71f4a-94e5-00e8-46af-a4c3ca4e520b@sandeen.net>
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.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-28 2:05 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
2018-06-28 2:05 ` Dave Chinner [this message]
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=20180628020504.GC2234@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=mcgrof@kernel.org \
--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 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.