|To:||Martin Steigerwald <Martin@xxxxxxxxxxxx>|
|Subject:||Re: xfs_growfs / planned resize / performance impact|
|From:||Stefan Priebe <s.priebe@xxxxxxxxxxxx>|
|Date:||Sun, 05 Aug 2012 17:54:28 +0200|
|Cc:||xfs@xxxxxxxxxxx, Eric Sandeen <sandeen@xxxxxxxxxxx>|
|References:||<5017E426.2040709@xxxxxxxxxxxx> <501B4D7E.1000303@xxxxxxxxxxx> <501B6B04.2090002@xxxxxxxxxxxx> (sfid-20120803_140801_426027_0A33D973) <201208051303.09337.Martin@xxxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0|
Am 05.08.2012 13:03, schrieb Martin Steigerwald:
Am Freitag, 3. August 2012 schrieb Stefan Priebe - Profihost AG: 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 performance.
30 disks raid 50 via LIO iSCSI and LVM.
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.
I do not use thin provisioning as dm thin is not production ready isn't it?
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.
Oh i can easily automate the whole resizing stuff. Stefan
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: xfs_growfs / planned resize / performance impact, Martin Steigerwald|
|Next by Date:||Re: xfs_growfs / planned resize / performance impact, Stan Hoeppner|
|Previous by Thread:||Re: xfs_growfs / planned resize / performance impact, Stan Hoeppner|
|Next by Thread:||Re: xfs_growfs / planned resize / performance impact, Michael Monnerie|
|Indexes:||[Date] [Thread] [Top] [All Lists]|