[gpfsug-discuss] restripe or not

Stijn De Weirdt stijn.deweirdt at ugent.be
Tue Nov 25 07:17:56 GMT 2014


hi zachary,

> * Your new storage -- is it the same size, shape, speed as the old storage?
yes. we created and used it as "test" filesystem on the same hardware 
when we started. now we are shrinking the test filesystem and adding the 
free disks to the production one.

> If not, then are you going to add it to the same storage pool, or an
> additional storage pool? If additional, restripe is not needed, as you
> can't / don't need to restripe across storage pools, the data will be in
> one or the other. However, you of course will need to make a policy to
> place data correctly.
sure, but in this case, they end up in teh same pool.

> Of course, if you're going to double your storage and all your new data
> will be written to the new disks, then you may be leaving quite a bit of
> capacity on the floor.
>
> * mmadddisk man page and normal balancing -- yes, we've seen this
> suggestion as well -- that is, that new data will generally fill across the
> cluster and eventually fill in the gaps. We didn't restripe on a much
> smaller storage pool and it eventually did balance out, however, it was
> also a "tier 1" where data is migrated out often. If I were doubling my
> primary storage with more of the exact same disks, I'd probably restripe.
more then half of the data on the current filesystem is more or less 
static (we expect it to stay there 2-3 year unmodified). similar data 
will be added in the near future.

>
> * Stopping a restripe -- I'm """ Pretty Sure """ you can stop a restripe
> safely with a Ctrl-C. I'm """ Pretty Sure """ we've done that a few times
> ourselves with no problem. I remember I was going to restripe something but
> the estimates were too high and so I stopped it. I'd feel fairly confident
> in doing it, but I don't want to take responsibility for your storage. :)
yeah, i've also remember cancelling a restripe and i'm pretty sure it 
ddin't cause problems (i would certainly remember the problems ;)
i'm looking for some further confirmation (or e.g. a reference to some 
docuemnt that says so. i vaguely remember sven(?) saying this on the 
lodon gpfs user day this year.

> :)  I don't think there's a need to restripe every hour or anything. If
> you're generally balanced at one point, you'd probably continue to be under
> normal operation.
i was thinking to spread the total restripe over one or 2 hour periods 
each days the coming week(s); but i'm now realising this might not be 
the best idea, because it will rebalance any new data as well, slowing 
down the bulk rebalancing.


anyway, thanks for the feedback. i'll probably let the rebalance run for 
48 hours and see how far it got by that time.

stijn

>
>
>
>
>
> On Mon, Nov 24, 2014 at 4:22 PM, Stijn De Weirdt <stijn.deweirdt at ugent.be>
> wrote:
>
>> hi all,
>>
>> we are going to expand an existing filestytem with approx 50% capacity.
>> the current filesystem is 75% full.
>>
>> we are in downtime (for more then just this reason), so we can take the IO
>> rebalance hit for a while (say max 48hours).
>>
>> my questions:
>> a. do we really need to rebalance? the mmadddisk page suggest normally
>> it's going to be ok, but i never understood that. new data will end up
>> mainly on new disks, so wrt to performance, this can't really work out, can
>> it?
>> b. can we change the priority of rebalancing somehow (fewer nodes taking
>> part in the rebalance?)
>> c. once we start the rebalance, how save is it to stop with kill or ctrl-c
>> (or can we say eg. rebalance 25% now, rest later?)
>> (and how often can we do this? eg a daily cron job to restripe at max one
>> hour per day, would this cause issue in the long term
>>
>>
>> many thanks,
>>
>> stijn
>> _______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at gpfsug.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>
>
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>



More information about the gpfsug-discuss mailing list