From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: xfs_growfs / planned resize / performance impact
Date: Tue, 31 Jul 2012 12:27:20 -0500 [thread overview]
Message-ID: <50181578.1090104@hardwarefreak.com> (raw)
In-Reply-To: <5017E426.2040709@profihost.ag>
On 7/31/2012 8:56 AM, Stefan Priebe - Profihost AG wrote:
> Hello list,
>
> i'm planning to create a couple of VMs with just 30GB of space while
> using xfs as the main filesystem.
>
> Now i alreay know that some of the VMs will grow up to 250GB while
> resizing the block device and using xfs_growfs.
If you already know they *will* need 250GB, make them 250GB now. This
is common sense.
> Should i take care of that and format these disks with special parameters?
Take care of what? Preemptively avoid what?
> I've discovered that a 500GB volume has agcount=4 and 64000 blocks of
> internal log - while a 300GB volume resized to 500GB has agcount 7 ad
> only 40960 blocks of internal log.
4 AGs is the default when an XFS is created unless the device is over
4TB. When you grow XFS, new AGs must be created in the new space. This
is because once an AG is "laid down" it doesn't move and its size never
changes. Any time you grow and XFS you get more AGs. This is by design.
> Is it a problem if this grow will happen in small portions (30GB => 50GB
> => 75GB => 100GB => ... 300GB)?
It 'could' be a problem. But there's no way for us to know that
without, drum roll please, you guessed it-- knowing your workload and
the characteristics of the underlying storage.
Wild ass guess? These are virtual machines with relatively tiny
storage. Performance isn't critical or you'd not attempt this in the
first place. So, I'd guess no, it won't be a problem.
If on the other hand you need high performance to these filesystems,
then you need to provide details of the storage device and the workloads
and we'll discuss it further.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-07-31 17:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 13:56 xfs_growfs / planned resize / performance impact Stefan Priebe - Profihost AG
2012-07-31 17:27 ` Stan Hoeppner [this message]
2012-08-03 4:03 ` Eric Sandeen
2012-08-03 6:09 ` Stefan Priebe - Profihost AG
2012-08-03 13:46 ` Eric Sandeen
2012-08-05 11:03 ` Martin Steigerwald
2012-08-05 12:34 ` Stan Hoeppner
2012-08-05 13:49 ` Martin Steigerwald
2012-08-05 20:26 ` Stan Hoeppner
2012-08-05 15:54 ` Stefan Priebe
2012-08-06 11:42 ` Michael Monnerie
2012-08-04 22:43 ` Dave Chinner
2012-08-05 5:46 ` Stefan Priebe
2012-08-05 11:06 ` Martin Steigerwald
2012-08-05 11:35 ` Andy Bennett
2012-08-05 20:57 ` Dave Chinner
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=50181578.1090104@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/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