[Top] [All Lists]

Re: xfs_growfs / planned resize / performance impact

To: xfs@xxxxxxxxxxx
Subject: Re: xfs_growfs / planned resize / performance impact
From: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Sun, 5 Aug 2012 13:03:09 +0200
Cc: "Stefan Priebe - Profihost AG" <s.priebe@xxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>
In-reply-to: <501B6B04.2090002@xxxxxxxxxxxx>
References: <5017E426.2040709@xxxxxxxxxxxx> <501B4D7E.1000303@xxxxxxxxxxx> <501B6B04.2090002@xxxxxxxxxxxx> (sfid-20120803_140801_426027_0A33D973)
User-agent: KMail/1.13.7 (Linux/3.5.0-tp520; KDE/4.8.4; x86_64; ; )
Am Freitag, 3. August 2012 schrieb Stefan Priebe - Profihost AG:
> Am 03.08.2012 06:03, schrieb Eric Sandeen:
> > On 7/31/12 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.
> >> 
> >> Should i take care of that and format these disks with special
> >> parameters?
> >> 
> >> 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.
> >> 
> >> Is it a problem if this grow will happen in small portions (30GB =>
> >> 50GB => 75GB => 100GB => ... 300GB)?
> > 
> > This incremental part doesn't matter a bit.  The first mkfs will
> > choose the AG count & size according to defaults;
> > 
>  > further growth after this will add new (possibly partial) AGs of
>  > that
> pre-chosen size.
> OK thanks for your reply. But does this influence performance? Should i
> perhaps start creating the 30GB with agcount 1 so that while raising
> the disk i don't end up with such a high agcount value? Does it make
> sense to create a bigger internal log from he beginning?

Well the default was 16 AGs for volumes < 2 TiB AFAIR. And it has been 
reduced to 4 for as I remember exactly performance reasons. Too many AGs 
on a single device can incur too much parallelity. Thats at least is what 
I have understood back then.

But then you didn´t describe where those VM disks are located. If that 
location has many spindles it might not matter at all or even improve 

Anyway, I do not see much sense to make them 30 GiB when they can grow to 
500 GiB – at least provided that you use thin provisioning. Cause 
xfs_growfs and resizing the image will likely be a manual step while thin 
provisioning goes automatically and only needs to be monitored.

That manual step makes sense tough if you want to guarentee all the space 
thats visibly in df output is really physically available, without 
providing for x times 500 GiB initially.

As you see much guesswork in here, cause the data you provided was not 
enough for any clear recommendation.

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

<Prev in Thread] Current Thread [Next in Thread>