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.