With the advent of Clustered Data ONTAP (cDOT) and SMB 3.0, a lot of the legacy SMB issues you’d typically run into have all but been rectified in Microsoft’s update to their protocol. However, a move to Server 2012 is in order to take advantage of SMB 3.0.
A lot of IT organizations have the bulk of their compute infrastructure on Server 2008 and will continue to run on that platform for the foreseeable future. So, having fixes and addressing issues in SMB 2.1 and Data ONTAP is still a priority for NetApp.
Issue Migrating SMB 2.1 to NetApp
We recently ran into an issue with a customer facing high CPU utilization upon migrating SMB 2.1 data to NetApp. The general profile of the data was millions of tiny files with an esoteric directory structure from the application. When copying the data, robocopy would enumerate the file system and stall out, causing CPU utilization to spike to around 80%. This was definitely not normal behavior, and initially we initially referenced a NetApp knowledgebase article: KB ID: 2017913 High CIFS metadata workload causes high CPU utilization in clustered Data ONTAP.
It was a good first attempt at remedying the situation, as the initial issues all pointed that way. However, as anyone who has done any modicum of troubleshooting enterprise infrastructure knows, it’s not usually that trivial, with root cause resolution often taking multiple approaches and efforts.
Finding A Resolution: Bumping Up Maxdirsize
So, the next logical move was to look at the volume option of maxdirsize. The default maxdirsize for cDOT is 320MB. Since we were dealing with millions of tiny files and a complex directory structure, we opted to bump up the maxdirsize to 1024MB. Problem solved. More information on maxdirsize can be found in: KB ID: 3012261 What are the Data ONTAP limitations on files, directories, and subdirectories?
Working in tandem with your channel partner provides an invaluable two-prong approach to problem resolution.
As always, we also recommend placing a call into NetApp Global Support, so that they can log and assign the proper resources to your support issues. Working in tandem with your channel partner provides an invaluable two-prong approach to problem resolution.
Ultimately, the more resources you can throw in a support situation, the better—especially when there is a strong partnership and expertise at both the OEM and channel level.
Photo credit via Flickr: Matteo Castelli