Por que o compartilhamento montado em CIFS é mais rápido que o SMB?

Por que o compartilhamento montado em CIFS é mais rápido que o SMB?

Para começar, esta questão não é realmente um problema que tenho, mas sim um"Por que é assim". Estou tentando retornar ao Linux depois de vários anos no mundo Windows, mas perdi muito... Então, vamos aprender de novo. :)

Eu tenho uma máquina Windows 10 x64 atuando como servidor de arquivos na minha rede. Eu acesso os compartilhamentos do Ubuntu Mate 16.04. O navegador de arquivos principal é o Caja.

Aqui está a parte boa: Quando navego nos compartilhamentos de rede da minha rede e começo a copiar um arquivo, a velocidade máxima é de cerca de 600 Mbit. Mas quando eu monto o compartilhamento permanentemente no Fstab com CIFS (de acordo comhttps://help.ubuntu.com/community/MountWindowsSharesPermanently) Posso utilizar minha velocidade total de link (1 Gbit). Também posso utilizar a velocidade total do link ao usar o smbclient via Terminal.

Alguém pode me explicar por que esse é o caso do Caja (e do Nautilus, pelo que posso dizer) e talvez me dar alguns links onde eu possa ler mais sobre isso? CIFS e SMB não são basicamente a mesma coisa?

Obrigado!

Atualizar:Estou usando uma placa de rede Intel I217-V (rev 04).

Responder1

SMB é um bloco de mensagens de servidor que foi inventado pela IBM para gravar arquivos em uma rede LAN. CIFS é um sistema de arquivos comum da Internet. CIFS é uma implementação específica de SMB feita pela Microsoft.

1.) A implementação CIFS de SMB raramente é usada atualmente. A maioria dos sistemas de armazenamento modernos não usa mais CIFS, eles usam SMB 2 ou SMB 3. No mundo Windows, o SMB 2 tem sido o padrão desde o Windows Vista (2006) e o SMB 3 faz parte do Windows 8 e do Windows Server 2012.

2.) SMB 2 e SMB 3 são atualizações massivas em relação à implementação CIFS.

Agora, algo para ter em mente (tamanho da janela TCP * 8 bits/RTT em milissegundos) = Taxa de transferência máxima de TCP em bps. Embora você possa ter uma rede Gigabit, um único fluxo TCP provavelmente não conseguirá chegar tão alto.

Agora, para otimizar a configuração SMB:

[global]

VER:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532

strict allocate = Yes

VER:https://lists.samba.org/archive/samba-technical/2014-July/101304.html

allocation roundup size = 4096

Permitir leitura de 65.535 bytes em um pacote

ler bruto = Sim

A assinatura do servidor retarda as coisas.

server signing = No

Suporta gravação RAW.

write raw = Yes

"bloqueio estrito = automático" OU "bloqueio estrito = não" é aceitável.

strict locking = No

opções de soquete = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

"tamanho mínimo do arquivo de recebimento" será passado diretamente para o kernel, recvfile/splice SYSTEM CALL.

min receivefile size = 16384

Use chamada de sistema sendfile() mais eficiente

use sendfile = Yes

O Samba deve ser construído com suporte de E/S de suporte a arquivos assíncronos

aio read size = 16384
aio write size = 16384

Também no meu caso precisei alterar a ordem das pesquisas de nome em nsswitch.conf. Acontece que esta configuração continha uma linha como esta.

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 

Simplesmente adicionar "vitórias" à linha de hosts resolveu o problema.

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

informação relacionada