Legacy Product Discussions

Aggregate commitment

bob_lansley

I have a question regarding aggregate commitment

I'm in the process of increasing a volumes at the destination end of cascaded volume snapmirrors from 1.5 to 2.5Tb. I’m increasing the volume size on the destination using FilerView (on the basis that command line doesn’t seem to like 2.5t (?) as a size) which then dutifully reports Total Capacity as being 2.5Tb

However, df doesn’t show the increased volume size and more importantly (well to me at least) it doesn’t show the extra 1Tb as being used from the aggregate. My understanding is that as soon as the source volume size is increased and a snapmirror update comes down the line it’ll all sort itself out.

What confuses me is that in the meantime it appears to be possible to use what should be “committed” aggregate space which cause big trouble in the future

e.g.

I have 1.75Tb in my aggregate and my volume size is 1.5Tb

I add 1Tb to the volume so it’s total capacity is now 2.5Tb (aggregate should now be 0.75Tb)

df –hA still shows 1.75Tb in my aggregate

I could now create another 1Tb volume leaving only 750Gb in the aggregate

Presumably bad things would then happen when the snapmirror update kicks in?

Due to the nature of multiple destination points around my company it may be some time until everyone is ready for the source to expand (in case you’re wondering why I don’t just increase the source right away)

Is my understanding correct or is there some way to prevent this from happening?

1 REPLY 1

Aggregate commitment

radek_kubka

Hi,

I would actually use thin provisioning for destination volumes (volume guarantee set to none).

Of course you can then overcommit even more, but this is just another consideration for planning.

Also, even with overcommitment, you will be fine as long as there isn't more actual data than space within aggregate - which can be easily checked with df -A.

Regards,

Radek

Earn Rewards for Your Review!
GPI Review Banner
All Community Forums
Public