Hi Tim,
Thanks for the link! It looks as if this bug wasn’t fixed until 9.7 so it very well could be what I’m hitting.
On December 18, 2020, Timothy Naple tnaple@berkcom.com wrote:
Scott,
It is hard to say because this does not specifically mention 9.6P5 but I wonder if you might be running into this bug:
https://mysupport.netapp.com/site/bugs- online/product/ONTAP/BURT/1262593
I am using FlexGroups quite a bit (mostly nfs, but some cifs) and I have not seen this sort of imbalance. I also wonder if something temporary is happening on the filesystem like some sort of large backup file being written. In theory elastic sizing would cover for it as long as autogrow is off, but I am not sure I would want to get to 99% capacity on that one member to test that theory!
Thank you, Tim
From: Scott Eno cse@hey.com Sent: Thursday, December 17, 2020 5:21 PM To: Toasters toasters@teaparty.net Subject: Runaway FlexGroup constituent
Hi,
I have a troublesome volume in a FlexGroup that continues to fill faster than the other constituents.
6.25TB 4.22TB 32% 6.25TB 4.19TB 32% 6.25TB 328.9GB 94% 6.25TB 4.24TB 32% 6.25TB 4.20TB 32% 6.25TB 4.20TB 32% 6.25TB 4.23TB 32% 6.25TB 4.24TB 32%
With autogrow disabled, from what I understand after reading Mr. Parisi's document, elastic sizing will make sure writes will happen. This FlexGroup is a CIFS share for a document management system, so it's millions of little files.
Am I safe to leave the FlexGroup like this until the other constituents catch up, or is there a need to grow the entire FlexGroup?
Cluster is 9.6P5.