From: Chris Murphy <lists@colorremedies.com>
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, 21 Jun 2018 21:19:54 -0600 [thread overview]
Message-ID: <CAJCQCtSzsYSyCD2eEvdgpKJ8ZFShsJrV2FxKZ4bv=-S6gpx2fw@mail.gmail.com> (raw)
In-Reply-To: <20180621221911.GT19934@dastard>
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....
OK that's useful information, thanks.
What about from the other direction; is it possible to make an XFS
file system too big, on an LVM thin volume?
For example a 1TB drive, and I'm scratching my head at mkfs.xfs time
and think maaaybe one day it could end up 25TB at the top end? So I
figure do mkfs.xfs on a virtual LV of 5TB now and that gives me a 5x
growfs if I really do hit 25TB one day. But for now, it's a 5TB XFS
file system on a 1TB drive. Is there any negative performance effect
if it turns out I never end up growing this file system (it lives
forever on a 1TB drive as a 5TB virtual volume and file system)?
--
Chris Murphy
next prev parent reply other threads:[~2018-06-22 3: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 [this message]
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
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='CAJCQCtSzsYSyCD2eEvdgpKJ8ZFShsJrV2FxKZ4bv=-S6gpx2fw@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--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.