Network and Storage Protocols

any problems with shortcut on one volume pointing to another volume?

wlandymore
3,970 Views

I have a FAS2020 that has the 1TB limit for a volume and I'm coming up against it with one of my volumes. I have created another volume on other disks and then I've put a shortcut with the same name within the first volume pointing to the second one. I will move all the data from one of the large folders that's just public access and put it on the new volume. My question is: Are there any problems with doing this to avoid the 1TB cap or will the fact that I've placed a shortcut in one volume pointing to another one be okay for things like SnapMirror, etc. The data that's contained on this is not really important but it is large so that's why I was doing this. I didn't want to use something like Win DFS because that seemed like it would be more of a change and this one I can do in the background and then remove the folder on the first volume to free up 150GB.

1 ACCEPTED SOLUTION

pierrecarette
3,970 Views

We use a mix of NFS/CIFS access in our enviroment so shortcuts are not an option. We use widelinks instead to enable DFS at the filer level.

View solution in original post

3 REPLIES 3

pierrecarette
3,970 Views

I am assuming this for NFS access only. We use symlinks in volumes all the time with the use of autofs and /net on our Unix/Linux clients so we don't have to worry about having all the static mounts defined on each servers. The symlink target usually looks like something /net/filer/nfsshare. We also use widelinks to enable Windows DFS.

Hopefully this helps.

wlandymore
3,970 Views

no, this was for CIFS. But currently people are going to a main folder that has this public one inside. They will continue to access the data in the same way because they're going in from the top level and nothing should have to be re-pointed. But instead of having the public data folder in that CIFS share I have made another volume, copied the data to it, and then left the link behind with the same name pointing to the new volume. This frees up a lot of space because it is now going through the shortcut and writing to the other volume. It seems to work fine and I can't see any negatives on the surface....but I'm not an expert. Basically I'm using it the way DFS does but the top level namespace was already there and then I'm redirecting them from within that.

pierrecarette
3,971 Views

We use a mix of NFS/CIFS access in our enviroment so shortcuts are not an option. We use widelinks instead to enable DFS at the filer level.

Public