I've been doing some re-configuring of cache tasks, and knowing I have some symbolic links between my boot drive (spindle HDDs in RAID) and my SSD drive (the target, G:), I wondered how Primocache handled them. Supposedly symlinks are transparent to the OS.
My source folder is on the SSD drive (since it is the faster of the two), and the symlink folder is on the C: drive. I can't move the original location for the folder away from C: since the software expects it to be there (like so many programs do).
When the software goes to read those files, it is redirected to G: to get the data. But Primocache is intercepting the reads/writes, so does it know about symlinks? Will it cache blocks it *thinks* are on the C: drive, or will it know and cache blocks from the SSD (G:) drive instead?
I'm asking primarily since I have a L2 Task to cache the C: drive, which uses a small partition on the SSD for L2. That's the same drive that the symbolic link points to. So Primocache goes to C: for data, is redirected to G: (the SSD), and might put the information into L2 - which is also on the SSD. That seems like a very inefficient roundabout way for the data to travel, since it ends up being copied to the same physical disk.
If Primocache is smart enough to know it's being redirected, then it wouldn't ever cache the data from the symbolic link folder into L2. I just don't know if that's true in this case.
How does Primocache handle Symbolic Links?
-
- Level SS
- Posts: 477
- Joined: Wed Oct 06, 2010 11:10 pm
Re: How does Primocache handle Symbolic Links?
PrimoCache is block level so it wouldn't be aware of whether the data cached was a link or not. Therefore it shouldn't be caching the linked data, unless you created a separate cache task for the host drive (G).
In your case, yes this would be inefficient (since a file access on C: could result in simultaneous read/write activity on SSD G:) and it would seem a better bet to take an image backup of both volumes and then swap them over (so your SSD becomes your primary drive - space permitting) rather than playing with symbolic links.
With regard to software, my experience has been that virtually any program can be installed to another drive, but relocating it afterwards can be problematic. If you still encounter problems post disk-swap, try uninstalling/reinstalling the software concerned. If the software is failing due to activation problems, then bear in mind this will recur on future system changes and consider a DRM-free alternative which you can carry on using even if the author closes down.
In your case, yes this would be inefficient (since a file access on C: could result in simultaneous read/write activity on SSD G:) and it would seem a better bet to take an image backup of both volumes and then swap them over (so your SSD becomes your primary drive - space permitting) rather than playing with symbolic links.
With regard to software, my experience has been that virtually any program can be installed to another drive, but relocating it afterwards can be problematic. If you still encounter problems post disk-swap, try uninstalling/reinstalling the software concerned. If the software is failing due to activation problems, then bear in mind this will recur on future system changes and consider a DRM-free alternative which you can carry on using even if the author closes down.
Re: How does Primocache handle Symbolic Links?
I think to avoid the redundant copy/cache on G: which we assume is happening, I'm going to re-home the User's "Documents" folder to the same subdirectory on G:, which avoids needing Symbolic Links and any problems that arise from using them. I'll simply have to keep that directory slim until I replace the SSD with a larger/faster model. It's not a bad solution, I'd simply gotten used to using SymLinks.
Thanks for chiming in InquiringMind.
Thanks for chiming in InquiringMind.
-
- Level SS
- Posts: 477
- Joined: Wed Oct 06, 2010 11:10 pm
Re: How does Primocache handle Symbolic Links?
If space is an issue, enabling NTFS compression on that Documents folder might offer a short-term fix (see DansData's writeup on it here), though this may affect performance if you have a slow CPU.