I’m coming late to the party on this so forgive me, but I found that even using
QoS I could not even snapshot my filesets in a timely fashion, so my
rebalancing could only run at weekends with snapshotting disabled.
Richard
From: gpfsug-discuss-boun...@spectrumscale.org
On Behalf Of David
Yes the arrays are in different buildings. We want to spread the activity over
more servers if possible but recognize the extra load that rebalancing would
entail. The system is busy all the time.
I have considered using QOS when we run policy migrations but haven’t yet
because I don’t know
On Mon, 20 Aug 2018 14:02:05 -0400, "Frederick Stock" said:
> Note you have two additional NSDs in the 33 failure group than you do in
> the 23 failure group. You may want to change one of those NSDs in failure
> group 33 to be in failure group 23 so you have equal storage space in both
>
Hey Dave,
Can you say more about what you are trying to accomplish by doing the
rebalance? IME, the performance hit from running the rebalance was higher
than the performance hit from writes being directed to a subset of the
disks.
If you have any churn of the data, eventually they will
Does anyone have a good rule of thumb for iops to allow for background QOS
tasks?
-- ddj
Dave Johnson
> On Aug 20, 2018, at 2:02 PM, Frederick Stock wrote:
>
> That should do what you want. Be aware that mmrestripefs generates
> significant IO load so you should either use the QoS
That should do what you want. Be aware that mmrestripefs generates
significant IO load so you should either use the QoS feature to mitigate
its impact or run the command when the system is not very busy.
Note you have two additional NSDs in the 33 failure group than you do in
the 23 failure
