Hi Denis -
Widelinks are certainly one way to do this, and essentially the only way in 7-mode. If in cDot, creating a second volume with a mount point is much simpler and accomplishes the same result. You could still do widelinks in cDot, but it's way more trouble than it's worth.
Obvious first question is are you in 7-mode or cDot?
Second question is whether there is one (or maybe two) directories (folders) that form natural points to break up the current volume. If you have a wide flat structure, splitting with widelinks is not easy or fun. However if you have a narrow structure at the top of the directory hierarchy, it is simpler.
For example, let's say volume "vol1" is shared as "DATA" from CIFS name "NTAP". So you have stuff like "\\NTAP\DATA\Folder01", "\\NTAP\DATA\Folder02", etc. If you have 100 folders at this top level, not so easy to split. But if you only have say three folders at the top, and you want to split off one of them into a separate volume, that isn't hard to setup.
A CIFS widelink is a jump from a point in one CIFS presented file system to a point in another CIFS presented file system not in the same underlying volume - hence the "wide" part of the link. In fact, both can be on different servers, including onto a jump from a NetApp device onto a non-NetApp device. For all intents, it's a manual DFS like redirection from within one file system to another (just not integrated into AD like DFS).
The underlying mechanism can get confusing. Widelinks are triggered through a symbolic link in the underlying WAFL file system. Recall that under the covers WAFL is a filesystem with essentially POSIX semantics - in other words UNIX like. POSIX file systems support linked files. A hard link directory entry is literally a multiple pointer to the same physical media on the same physical volume. A symbolic link, which is what we care about, is a reference to another filesystem location. This is a natural device in an NFS world. Data Ontap does some special stuff to simulate the effects for CIFS.
When you enable widelinks on a CIFS share, anytime any traversal through that share hits a symbolic link in the WAFL filesystem, DoT will lookup the target of the symbolic link in a translation table. Remember that the "real" target of the symbloic link has POSIX (UNIX style) syntax. The translation table pairs a POSIX style target with a UNC name of a CIFS target. DoT sends a CIFS redirection to the requesting client that contains the UNC from the translation table. The client then connects to the UNC transparently and happily keeps processing along - exactly the way DFS works. The redirection isn't necessarily exposed to the client, depending on the tools they are using, and in general the client will cache the branch point and just know for subsequent accesses where the branch occurred to speed subsequent accesses (something to remember if you change the targets while users are in them - again just like DFS updates).
In a pure CIFS world the hard part is creating the symbolic link on the WAFL file system. NFS protocol users have semantics to do this directly - CIFS users do not. Fortunately there some utilities to call the ZAPI functions directly to create that link.
For a variety of reasons I have created this type of hierarchy before - typically around consolidating multiple instances of a large application data archive into a central data center from branch locations in 7-mode setups. It works well for most all situations, but you will want to test as every now and again an application pops up that cares about the redirection. These are usually easy to spot, as the applications would also generally have issues in a DFS environment.
Other downsides come into play when managing security and anything else that does full filesystem traversal - some applications by default don't follow redirected links. You want to keep really good docuemntation on what is where as you start any planning on this.
The general steps I would follow to split a directory are:
1. Choose a folder that represents is the top of a hierarchy I want to split out. You can split on any folder in the tree - there is no limitation to be at a qtree boundary
2. Create a volume to contain the split data and establish a CIFS share on that volume.
3. Copy the data from the current location to the new location - robocopy in the generic case - to seed the new location. users aren't using the new location yet.
4. Verify data accessibility and security on the new share location.
5. Choose a "target identifier" for the symbolic link you will create. A symbolic link in the POSIX sense doesn't have to point to something that exists - it is just a pointer to "something". Choose a naming convention carefully for the target if you expect to create more links.
6. Create/update the symlink translation table to add an entry from the target identifier in step 5 to the new UNC verified in step 4.
7. Turn on widelink capability on the original share if not already
All that is prep - users still see the original share. But, if all that is in place correctly, then these next steps finish the cutover. This is a hard cutover - it will be disruptive to active file users.
8. Rename the top level folder (step 1) to something like "FOLDER-OLD". You might have to force users sessions/files to close to do this.
9. Create a symbolic link (via multi-protocol NFS access to the original share or using a ZAPI utility) that has the top level folder name and points to the "target identifier" from step 5.
10. Check access through the original share to the folder in question via the original name. If all is working, the symbolic link is now redirecting you. You can verify that with a properties view of a file in the new location on a Windows client.
11. If needed, run a last file copy/update from what is now "FOLDER-OLD" to the original FOLDER name. This updates any changes made in the gap between the original copy and the access change. If you schedule things well, this step might not be needed.
12. Delete the FOLDER-OLD version to reclaim space.
OK - that's what you're in for with WideLinks. If you can answer the two questions, I can help you with more specific commands and references.
Widelinks were in my opinion a very under-utilized feature in 7-mode. They provided a lot of power to address data location independence situations. I use them even in cDot to address specific situations where legacy data layout is not conducive to data layout in Clustered DataOntap. I have absorbed legacy server setups where I create a template first level directory that is just widelinks to other volumes/shares even across SVMs. Makes it much easier to present independent administration points to different groups yet maintain the original logical layout, which is something even cDot mount points can't do.
I hope this helps you.
Bob Greenwald
Lead Storage Engineer
Huron Consulting Group
NCDA Clustered | NCIE-SAN Clustererd
