SMB client - multichannel support

[MiroslavPragl]

Ahoj, je tu nejaky zkuseny CIFS/Samba odbornik? Nedari se mi prinutit smb klienta, aby pouzival 2 sitovky v multichannel modu:

Konfigurace klienta: UBUNTU server, Samba client 4.19.5-Ubuntu.
 
Problem:
server ma 2 GBe adapters, IP addresses: 10.0.0.242, 10.0.0.243 (fixed)
client ma 2 GBe adapetrs, IP addresses: 10.0.0.19, 10.0.0.36 (DHCP)
(takze celkem 4 kabely v temze switchi)
 
1) primountuji share ze smb serveru pomoci libovolne z jeho IPs:
mount -t cifs -o multichannel,username=******,pass=******,vers=3.11 //10.0.0.243/WindowsImageBackup /mnt/WindowsImageBackup
 
2) samba client korektne pozna obe server IPs a pouzije je, viz log:
[   19.356382] CIFS: Attempting to mount //10.0.0.243/WindowsImageBackup
[   19.471326] CIFS: VFS: successfully opened new channel on iface:10.0.0.242
 
3) ale klient ma bind jen na JEDNU local IP (.19). Druha klientova IP (.36) se flaka:
netstat -n|grep 10.0.0.24[23]
tcp        0      0 10.0.0.19:45554         10.0.0.243:445          ESTABLISHED
tcp        0      0 10.0.0.19:33314         10.0.0.242:445          ESTABLISHED
 
Takze rychlost je samozrejme jen 1 Gbps misto ocekavanych 2. Bottleneck je pouzivani jedineho adapteru klienta.
Server ma pouzite / vytizerne oba adaptery, celkem rovnomerne  (kazdy ~ 500 Mbps)

Pokud na teze konfiguraci nabootuji Win 11, mam samozrejme rychlost 2 Gbps dle ocekavani

Predem dik za rady

MP
 

[Reklama]

[M Z]

Pokud se za poslednich par mesicu nic nezmenilo, tak linuxovi cifs klient multichannel nepodporuje.

[MiroslavPragl]

Mohl bys poslat odkaz?
Ze je to experimentalni feature vim, ale jak vidis, klient pouziva 2 kanaly, jen oba z jedne klientske sitovky.

Treba je omezene podporovany jen multichannel pomoci RSS jedne sitovky, ale nikde jsem nenasel jasnou informaci.

Dik

MP

[MiroslavPragl]

Jeste doplnim kernel 6.8.0-49

Multichannel by MEL BYT podporovan jadernym modulem (dle https://wiki.samba.org/index.php/LinuxCIFSKernel) od kernelu 5.5

MP

[MiroslavPragl]

Wel yes, but actually no.

Resp. dostal jsem prvni odpoved od samba.org, kam jsem hlasil jako potencialni chybu, volne prekladam:
"neni to chyba, je to vlastnost; multichannel znamena, ze klient pouziva jednu sitovku, a server 2 a vice"
Neslusne jsem odpovedel neco jako ze take dokazu zvysit vykon zasuvky tim, ze do ni dam rozdvojku.

Asi jsem ti mel verit, nicmene bez odkazu na ofiko dokumentaci jsem neduverivy.

MP

[Reklama]

[ja.]

Ako tu už bolo spomenuté, libsmbclient (súčasť samby) nepodporuje multichannel. Multichannel podporuje samba iba na strane serveru.

Modul z jadra možno áno, ale to nie je to, čo Ubuntu (gvfs, kio) používajú.

Multichannel samozrejme môžu podporovať aj klienti a to je presne to, čo robí napríklad Windows alebo MacOS. Viacero sieťových rozhraní je pritom len jedna alternatíva, ďalšou je použitie sieťových rozhraní s asymetrickou kapacitou (napr. klient má 2.5 GbE a server niekoľko 1 GbE rozhraní; keď klient vytvorí 2-3 spojenia multichannel, pôjde mu to rýchlejšie aj s jedným rozhraním), alebo ďalšou alternatívou je použitie iných transportov ako tcp (RoCE/RDMA, ktoré sú z pohľadu protokolu ďalší kanál). Ďalšia možnosť je teaming/bonding, keď klient chce vyťažiť jeho kapacitu, tak nutne potrebuje viacero tcp spojení. Dokonca aj keď má zariadenie len jednu sieťovku, ktorej bandwidth je menší ako naproti na serveri, môže multichannel priniesť zrýchlenie, pretože RSS.

No ale presne toto je to, čo libsmbclient používaný v linuxových DE nevie. Niektoré, nebudem teraz ukazovať prstom, jeden dokonca robí kontraproduktívne veci, ako je rozsekanie trafficu na 64kB segmenty, čím spoľahlivo zabije možnosť mať viacero paralelných async requestov (ktoré libsmbclient vie).

[MiroslavPragl]

Dik.
Jak uz jsem psal, kdyby neumel vubec, byl bych s tim OK. Ale zere me, ze umi udelat 2 klientske sockety proti 2 serverovym IP/if, jen ne z ruznych zdrojovych IP/if.

Je to skoda, smb je solidni protokol/filesystem. Mozna nejlepsi.

MP

P.S. Proc to delam: dostal jsem vyrazenou SAS paskovou mechaniku, jsou brzo vecery, hraju si:

- Pro Win jsem nenasel solidne optimalizovany tar (da na 2gigabitove siti ledva 1 gigabit, evidentne mu nesedi \\.\tape0).
- V linuxu je zase brzdou sit (viz vyse), tar jsem musel naspeedovat pres mbuffer, jinak s malymi soubory je to tragedie na kvadrat.
- Veeam community jede pres \\.\tape0 jak z praku,kesuje si sam, pokud mechanika komprimuje tak mu nestaci ani ty 2 Gb, ale je to moloch s proprietarnim formatem a principialne neumi o moc vic nez ten dedek tar. Nechci nechci. Nechci nechci.

[Michal Šmucr]

V poslední době jsem neměl moc potřebu tohle řešit, protože jsem používal buď rychlejší rozhraní nebo bonding (a víc klientů), ale je to zajímavé.

Zkusil jsem si to nasimulovat a musím říct, že se to chová dost specificky.
Pokus jsem dělal jen teď na QEMU/KVM virtuálu, kde jsem pak zalimitoval rychlost dvou síťovek na fyzický počítač (který byl zároveň CIFS klientem) na cca 1Gbit.
SMB multichannel připojení se povedlo.
Pro jistotu jsem to ověřil přes

echo 1 >/proc/sys/kernel/sysrq
echo 1 >/proc/fs/cifs/cifsFYI

cat /proc/fs/cifs/DebugData

...kde pak bylo následující:

   Server interfaces: 2   Last updated: 570 seconds ago
   1)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.240
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

   2)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.134
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

Při čtení ze serveru to pak jelo pokaždé pouze přes adresu a síťovku, kterou jsem použil při připojování CIFS sdílené složky (tedy v mém případě první).
Ať jsem nastavoval, co chtěl, měnil způsoby čtení (iodepth, vlákna..), zkoušel různé nastavení SAMBY na serveru atp.
Monitoroval jsem na serveru i device statistiku přes sar (ze sysstatu) a data šla vždy jen přes jednu síťovku.

Ano podle toho by se zdálo, že to opravdu nefunguje (minimálně na agregaci rychlosti, failover jsem nezkoušel)
Nicméně pak jsem testoval zápis.
Pokud to bylo jednovláknový zápis s iodepth=1 (nebo třeba jednoduchý zápis z urandom přes dd), tak se to chovalo úplně stejně jako čtení - vše přes první síť.
Ale když jsem zvedl iodepth třeba na 4, nebo na server zapisoval víc souborů naráz, tak to vysaturovalo obě linky na max.
I při kopírování souboru v Nautilu (GNOME) na server to šlo v pohodě až na 220MB/s - kopírování tady evidentně také naplní delší frontu IO operací a ty pak jedou přes obě spojení/adresy.

Takže v tomhle testovacím prostředí to vypadá, že multichannel smysl má i z Linuxového CIFS klienta, ale jen pro zápis.

Možná by na to čtení teoreticky mohlo mít vliv i to, že mám s těmi virtuály specifickou topologii sítě s bridgem a pokud bych to opakoval třeba na dvou fyz. počítačích, kdy by měl každý dvě fyz. síťovky, tak by se to mohlo chovat odlišně.. Ale moc bych na to nesázel. Plus jsem dělal teď jen rychlý test, nehledal jsem nikde ve fórech, mailing listech atp.

[Michal Šmucr]

Tak ještě další věci.
Teď jsem si všiml, že v předchozím příspěvku jsem psal o tom povolení sysrq a cifsFYI přes sysfs.. To jsem omylem zkopíroval z historie terminálu, kde to bylo pro ukecanější debug přes dmesg, což by to info o spojeních v DebugData nemělo být třeba, pardon.
Dělal ještě test s víc jádry, resp cifs moduly.
U 5.15 a CIFS modulem 2.33 (Oracle UEK) to chodí přes jednu síťovku jak pro čtení, tak i zápis.
To, co jsem psal předtím, že zápis využije obě síťovky, fungovalo s kernelem 5.11 a CIFS modulem 2.50 (jak Oracle UEK Next, tak OpenSUSE Tubmleweed).