xfs_growfs / planned resize / performance impact

[Martin Steigerwald]

Am Sonntag, 5. August 2012 schrieb Stefan Priebe:
> Am 05.08.2012 um 00:43 schrieb Dave Chinner <david at fromorbit.com>:
> > On Tue, Jul 31, 2012 at 03:56:54PM +0200, 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.
> > 
> > Just use thin provisioning and make it 250GB to begin with. Thin
> > provisioning mades filsystem grow/shrink pretty much redundant....
> 
> But dm thin isn't stable isn't it? Does xfs reallocate used parts of
> the block Device before using new parts? Otherwise deleting and
> recreating files will result in full used space pretty fast.

A periodic fstrim might help if the TRIM/DISCARD is supported in all 
layers. And whether it is is a good question that depends on well where 
your data is stored and what layers in the kernel are involved in storing 
it and the kernel version of course.

> >> Is it a problem if this grow will happen in small portions (30GB =>
> >> 50GB => 75GB => 100GB => ... 300GB)?
> > 
> > Growing a filesystem by an order of magnitude is the limit of what
> > I'd suggest is sane. Growing it by two orders of magnitude
> > (espcially if you start with a 16 AG filesystem because of stripe
> > alignment) is going to cause problems with the number of AGs and
> > the subsequent freespace management scale issue....
> 
> I would start with ag=4 and end up in ag 48 in my tests.

Thats IMHO quite much for upto 500 GiB. But it still depends on what kind 
of storage this is located.

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