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 <[email protected]>
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
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
