CIFS share space issue

[MSaleem]

NetApp C30 storage system with two nodes. Two aggregates have been created as per best practices, each with approximately 99.3 TB of usable capacity.

• Aggregate 1 hosts a CIFS/SMB FlexVol that is currently utilizing around 80 TB out of 99.3 TB.

• Aggregate 2 hosts an iSCSI volume that is utilizing approximately 10 TB out of 99.3 TB, leaving significant free capacity available.

The CIFS share is accessed by users via the mapped network path:
\\192.168.30.101\dxb_data\Data

All user data resides within a single qtree (without quotas), and the volume junction path is /DXB_DATA, Storage efficency is enable 

Due to capacity growth on Aggregate 1, I would like to utilize aggregate free capacity for existing CIFS shares.

The key requirement is to ensure that end users can continue accessing the HR folder using the existing mapped drive path, with no disruption to service and no changes required on the client side.

[dbenadib]

Hi, 

We created a while ago FlexGroup volumes that can be spanned across multiple aggregate. Now, you can convert a CIFS share from regular FlexVol to FlexGroup non disruptively.

I've just made a quick test in our Lab running aggressive file creation during the conversion and it did not fail nor freeze. 

FlexVol to FlexGroup conversion will allow data constituent addition that will allow volume expension beyond aggregate boundaries. A good practice is also to perform a rebalance after the data consituent addition to balance space consumption over the data constituent.

HTH

David 

[MSaleem1]

Thanks for the update

Please find the comments from the NetApp Support

 When not to convert a FlexVol volume:

Converting a FlexVol volume to a FlexGroup volume might not always be the best option. If you require

FlexVol features that are not available in FlexGroup volumes, then you should hold off. For example,

NetApp SnapLock® and SnapMirror Synchronous are not currently supported for FlexGroup volumes, so

if you need them, you should stay with FlexVol volumes.

Also, if you have a FlexVol volume that is already very large (80–100TB) and already very full (80–90%),

you should copy the data rather than convert, because the converted FlexGroup volume has a very large,

very full member volume. This might create performance issues and does not fully resolve your capacity

issues, particularly if that dataset contains files that grow over time.

Recommendation and Next Steps:

Our strong recommendation is to avoid converting the existing FlexVol to a FlexGroup. Instead, we advise migrating the data to a newly created FlexGroup using tools such as XCP or robocopy. This allows ONTAP to distribute files optimally across constituents, preventing post-conversion imbalance and ensuring better long-term performance and scalability.

[dbenadib]

I do agree that this is not the ideal solution (Converting) but will you have enough capacity to handle a robocopy/XCP migration ? Plus note that cutover to new volume will be disruptive (short)...
In my comment, I've also mentioned that a rebalance should be run to align space consumption across Data Constituent.

Regarding the lack of features for FlexGroup, are you falling into FG's limits (Snaplock, ARP, Snapmirror Sync)?