A common customer challenge is running out of space in a data volume. Sometimes you need to order additional on-prem or cloud storage. You then grow the volume, delete Snapshot copies and/or delete or tier cold data to gain useable space. Often the space remediation is automated with “Volume Autosize” and “Snapshot Autodelete”. However, what do you do when the volume is at maximum capacity? For example, a NetApp FlexVol has a maximum size of 100TB and there is no way to grow that volume beyond that size.
A preferred solution is migrate or convert to FlexGroups which support 20PB+ space under a single mount point. Another option is to junction path, or stitch together multiple FlexVols in the namespace. The junction path method takes more work to maintain and is less flexible than a FlexGroup, but it has a good use case as a “band-aid” to alleviate space constraints while migrating to FlexGroups. The example below will show you how to use junction paths to free up space, while you implement FlexGroups. You can also junction FlexGroups, but most often we mount a FlexGroup under “/” for one large NAS bucket.
The easy button is the ONTAP feature to convert FlexVols in-place to FlexGroups non-disruptively. However, when a FlexVol is near full at 100TB, that volume is not a good candidate for conversion and should be migrated using a host method, XCP, robocopy, rsync or your other favorite host migration tool. To explain, with a 100TB FlexVol, you would need to add additional 100TB member volumes after conversion in order to grow the FlexGroup, and the balance would be uneven leaving the first constituent near full. A better use case for conversion is if you have a 10TB FlexVol at 60% utilization, you can convert in-place, then add multiple 10TB member volumes after conversion.
When implementing the junction-path “band-aid”, the user does not see any change in the path to their files, and the nfs exports and smb share paths do not change. There is a short downtime window, but only for the specific user migrated in the example below. This makes host-based migration from FlexVols to FlexGroups easier, since you can continually move data into junction pathed volumes to alleviate space, without any change for users or migration hosts.
You have a 100TB Flexible volume named “Users” with multiple users. The volume is mounted to the junction path /Users and users have directories in the volume.
Now the challenge and remediation scenario… You are at 95% capacity on this 100TB FlexVol, and have an XCP job running to migrate /Users to a FlexGroup named /Users_new, but meanwhile you need to alleviate space in /Users. You see that user5 is taking 20TB of space and see that you can migrate user5 to a new volume, then junction that volume under the same /Users/user5 path.
Create a new volume “user5” junction pathed to /Users/user5_new and the new path will show up under the cifs share. Note that you likely will want to use the same snapshot policy as the Users volume to keep the same retention. Also note the arrow on the folder indicates a linked path, but the user and all processes do not see a difference from a directory.
volume create -volume user5 -aggregate aggr1 -size 25T -space-guarantee none -junction-path /Users/user5_new
Copy the user data from user5 to user5_new, then cutover and rename user5_new. In this example, we will rename user5 to user5_old, but you would need to delete user5_old to reclaim space, and also note that you also need to wait for Snapshot copies to rotate out to free the deleted space. The user has a new volume for expansion and other users still have some free space available in /Users. You can repeat this process for other users while you migrate to FlexGroups.
Rename user5 to user5_old after copying the user data
Unmount and mount the new “user5” volume so it appears the same as it did when it was a directory in the Users volume.
volume unmount -volume user5 -vserver Users
volume mount -volume user5 -junction-path /Users/user5 -active true -vserver Users
You have applied a band-aid to free space, provide new space for expansion, all without changing the XCP job that is copying /Users out to a new FlexGroup that you will cutover to for easier growth later.