Bugzilla – Bug 17468
Discovering phase takes much longer on a UNC path, even if local
Last modified: 2019-01-25 12:14:45 UTC
This report actually still affects 7.6.1 r33110, which can't be selected in Bugzilla though. Even though my music library resides on the same machine as SBS, I have to use an UNC path for the library, to make sure that the path is consistent with the playlists created by a client tool. I notices that the "discovering phase" takes much much more time when using an UNC path compared to a direct path. During the scan, there is almost no CPU load and no network traffic. A client tool, which does practically the same (over the network, mind you), is much much faster scanning through the same library. So it cannot be a problem of the network stack itself. It must be related to the way SBS scans the directory structure somehow. Sanning using the local path: Discovering files/directories: D:\Multimedia Files\MP3 (14591 of 14591) Complete 00:00:31 And a network path (still located on the same machine): Discovering files/directories: \\server\mp3 (14591 of 14591) Complete 00:16:22
I can confirm this, I did some testing on 7.6.1 posted in this post: http://forums.slimdevices.com/showthread.php?p=647234#post647234 Using UNC paths to the local computer in 7.6.1 was about 3 times slower than using drive letter paths.
Glad someone posted this bug; sorry to hear that someone else experiences it too though. Erland - I had a 50% speed reduction, not 3x. Martin - Be sure to exclude your A/V scanner from scanning these paths.
Interesting that the speed loss differes that much between our systems. I don't have any virus scanners on that system. But I use quite aggressive power saving techniques and the CPU isn't that strong to begin with. I'll experiment with different power settings and will post the results. Since the actual CPU load is very low, the power saving mechanism might slow down the CPU considerably but therefor also stall the scanning process.
One workaround to the problem of being forced to use UNC paths to comply with playlists created on another computer would be to use a mapped drive letter on the other computer. 1. Create a share for the D: drive on the server. 2. On the machine editing playlists, map the local D: drive letter to the server share. If D: is already in use on the playlist editing computer, you can just change that partition to another letter first. Or, change the D: drive on the server to another letter that's also free on the PC. Then your playlists should contain file paths instead of UNC paths and you should be able to go back to using local file paths for the music folder in SBS.
Thanks for the suggestions, Jim. That might work for some, but there are limitations under WHSv1. I believe Microsoft strongly advises against using the drive letter paths for the shares because of all the behind the scenes stuff going on for drive extender. Besides that, the shares are under D: and this can't be changed on the WHS side, and most computers will already have the D: drive letter in use--so it's a dead end.
(In reply to comment #5) > Besides that, the shares are under D: and this can't be changed on the WHS > side, and most computers will already have the D: drive letter in use--so > it's a dead end. Being in use should pose no problems. As I suggested above, you can easily re-letter the partition that is currently labeled 'D'. It's only when you have applications or application data on D that it becomes something of a chore.
I ran some tests today on my Win2k3 server, and while it's definitely slower to use UNC paths, I don't see anything like the difference shown above. For my 33k track library, discovery takes about 0:25 using a local path and 1:30 using a UNC path. That's pretty much the same 3x slowdown that Erland claimed. Even at that, the overall scanning time isn't as badly affected - maybe 20-25% slower.