Назад | Перейти на главную страницу

mklink на общий сетевой ресурс, путь UNC или подключенный диск?

Есть ли производительность, разрешение или другие соображения, о которых следует подумать при использовании mklink путь к общему сетевому ресурсу вместо простого пути UNC (или подключенного диска, если на то пошло).

Например, можно ли считать эти три способа доступа к сетевому ресурсу функционально эквивалентными и примерно взаимозаменяемыми?

mklink /d c:\shares\warehouse \\server1\warehouse
xcopy /s c:\shares\warehouse d:\temp\warehouse_copy

.

xcopy /s \\server1\warehouse d:\temp\warehouse_copy

.

net use X: \\server1\warehouse
xcopy /s X:\ d:\temp\warehouse_copy

Сервер - Windows 2003, клиенты - Win7 Pro. Сеть в основном гигабитная, хотя тут и там есть несколько отстающих на 100 Мбит. В этом примере я использовал командную оболочку cmd, потому что это проще всего объяснить, на практике доступ к ресурсу также будет осуществляться множеством других методов (Windows Explorer, диалоговые окна «открытия» Office, службы резервного копирования системы и т. Д.)

Я настоятельно рекомендую НЕ использовать символические ссылки с удаленной целью. Мое объяснение состоит в том, что символическая ссылка делает запись в таблице основных файлов NTFS, и хотя это не обосновано, я считаю, что это может вызвать проблемы при выполнении низкоуровневых операций NTFS MFT (таких как автономный CHKDSK).

Что касается производительности, я не вижу, чтобы была вообще разница. Оба приводят к трафику SMB. Маршрут символической ссылки должен проходить через перенаправление (обрабатываемое NTFS.SYS), но «задержка» здесь будет во много тысяч раз меньше, чем любые последующие задержки в сети ...