FSLogix profile container fails to load from EMC Isilon storage share

Question

We are in the process of implementing FSLogix for basic profile and O365 management, with profile VHDX files being stored on an EMC Isilon storage share. After configuring the necessary GPO settings for VHDLocations and other core configurations, and setting the proper permissions on the file share folders, we proceeded to test and pilot within a Citrix non-persistent VDI environment with an initial storage quota of 300GB for the pilot. This worked perfectly, and our pilot users rave about how much they love it. So after running the pilot successfully for several weeks, we proceeded to the planning phase for a full rollout, which included some estimated capacity planning for profile storage. A request was made to have our storage quota increased to 5TB to support the anticipated profile needs. The storage change was made and we quickly began receiving reports from the pilot users that they were seeing delays logging into their virtual desktops and their profiles appeared void of any previous settings or data. After further investigation, we discovered that FSLogix was failing to create new (or access existing) VHDX profile containers, causing Windows to load a generic local profile. There was virtually no information in the Windows event logs other than disk failures with no real error information to investigate. The only meaningful error was found under the FSLogix event log which showed the following (storage share path intentionally changed): VirtualDiskAPI::CreateFormattedDisk failed to create vhd(x): \servername\sharename\Profiles\testuser_SID\Profile_testuser.VHDX (The parameter is incorrect.) We've only been able to find one reference to this error, which vaguely pointed to an issue with the Isilon, but when we reached out to our storage team, they didn't see anything wrong with the share on their end. Then, while troubleshooting, the share quota was dropped back down to the original 300GB size, and everything immediately returned to a working state. Further testing revealed that the issue was occurring as soon as the share was increased to 3TB or above. Setting the size at 2.99TB allows everything to function normally. Thus far, EMC has not found any fault with the storage share, noting that our org has several other shares with sizes upwards of 15-20TB. In the same manner, Microsoft engineers have not found any issues on the FSLogix side, especially since it works when the storage size is dropped below the apparent 3TB limit, without any changes to the FSLogix config. I should also note that when the issue is occurring, other read/write operations to the storage share seem to function normally. It only appears to affect the VHDX files for FSLogix. So we are at a loss on what direction to take and looking for any thoughts or advice that may point us in the right direction.