All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	xfs list <linux-xfs@vger.kernel.org>
Subject: Re: Mounting xfs filesystem takes long time
Date: Thu, 28 Jun 2018 10:19:39 +0200	[thread overview]
Message-ID: <20180628081939.ryjsimtzqo2ig5sf@odin.usersys.redhat.com> (raw)
In-Reply-To: <20180628020504.GC2234@dastard>

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

-- 
Carlos

      reply	other threads:[~2018-06-28  8:19 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
2018-06-28  8:19                       ` Carlos Maiolino [this message]

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=20180628081939.ryjsimtzqo2ig5sf@odin.usersys.redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=sandeen@sandeen.net \
    /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.