Почему общий ресурс, смонтированный по протоколу CIFS, работает быстрее, чем SMB?

Почему общий ресурс, смонтированный по протоколу CIFS, работает быстрее, чем SMB?

Начнем с того, что этот вопрос на самом деле не является моей проблемой, а скорее"почему это так". Я пытаюсь вернуться к Linux после нескольких лет в мире Windows, но я так много потерял... Так что вот вам и обучение заново. :)

У меня есть машина с Windows 10 x64, которая выступает в качестве файлового сервера в моей сети. Я получаю доступ к общим папкам из Ubuntu Mate 16.04. Основной файловый браузер — Caja.

А вот и хорошая часть: Когда я просматриваю сетевые ресурсы в своей сети и начинаю копировать файл, максимальная скорость составляет около 600 Мбит. Но когда я монтирую ресурс постоянно в Fstab с CIFS (согласноhttps://help.ubuntu.com/community/MountWindowsSharesPermanently) Я могу использовать полную скорость соединения (1 Гбит). Я также могу использовать полную скорость соединения при использовании smbclient через терминал.

Может ли кто-нибудь объяснить мне, почему это касается Caja (и Nautilus, насколько я могу судить) и, возможно, дать мне ссылки, где я могу почитать об этом больше? Разве CIFS и SMB по сути не одно и то же?

Спасибо!

Обновлять:Я использую сетевую карту Intel I217-V (rev 04).

решение1

SMB — это серверный блок сообщений, изобретенный IBM для записи файлов по локальной сети. CIFS — это общая файловая система Интернета. CIFS — это конкретная реализация SMB, созданная Microsoft.

1.) Реализация CIFS SMB в наши дни используется редко. Большинство современных систем хранения данных больше не используют CIFS, они используют SMB 2 или SMB 3. В мире Windows SMB 2 был стандартом с Windows Vista (2006), а SMB 3 является частью Windows 8 и Windows Server 2012.

2.) SMB 2 и SMB 3 представляют собой существенные обновления по сравнению с реализацией CIFS.

Теперь следует помнить о следующем (размер окна TCP * 8 бит / RTT в миллисекундах) = максимальная пропускная способность TCP в бит/с. Хотя у вас может быть гигабитная сеть, одиночный поток TCP вряд ли сможет достичь такой скорости.

Теперь оптимизируем конфигурацию SMB:

[global]

ВИДЕТЬ:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532

strict allocate = Yes

ВИДЕТЬ:https://lists.samba.org/archive/samba-technical/2014-July/101304.html

allocation roundup size = 4096

Разрешить чтение 65535 байт в одном пакете

читать сырое = Да

Подписание сервера замедляет работу.

server signing = No

Поддержка записи в формате RAW.

write raw = Yes

Допустимы значения «строгая блокировка = автоматическая» ИЛИ «строгая блокировка = нет».

strict locking = No

параметры сокета = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

«min receivefile size» будет передан непосредственно ядру, recvfile/splice SYSTEM CALL.

min receivefile size = 16384

Используйте более эффективный системный вызов sendfile()

use sendfile = Yes

Samba должна быть собрана с поддержкой асинхронного ввода-вывода файлов

aio read size = 16384
aio write size = 16384

Также в моем случае мне нужно было изменить порядок поиска имен в nsswitch.conf. Оказывается, эта конфигурация содержала такую ​​строку.

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 

Простое добавление «побед» в строку хозяев решило проблему.

hosts:          files wins mdns4_minimal [NOTFOUND=return] dns mdns4

Связанный контент