Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Nové soubory umístěné ve sdíleném adresáři se na jiných SMB klientech objeví až se zpožděním
leden 08
Nové soubory umístěné ve sdíleném adresáři se na jiných SMB klientech objeví až se zpožděním

Dneska přišlo mailem, tak to rovnou hodím na web, protože se jedná o poměrně častou a přitom velmi zajímavou otázku.

Na Windows XP a Windows 2003 a starších se to nestávalo - tedy krom podivných případů, pokud jste měli zapnuty Offline Files a kdoví jaká online detekce nefungovala. Jde nám zde o klienty s Windows Vista a novějšími, kteří se pomocí SMB 2.0 připojují na souborové servery s Windows Vista a Windows 2008 a novějšími. Jenom za takové situace se použije SMB 2.0. Pokud se například i Windows 7 připojují na Windows 2003 file server, stejně to sklouzne na starší SMB 1.0.

Novinkou ve Windows Vista a Windows 7 je SMB 2.0 a ve Windows 8 dokonce SMB 3.0. Toto nové verze a jejich implementece přidaly různé keše na stranu klientů. Nemyslím teď keš obsahu souborů (to se jmenuje Offline Files), ale jen informací o atributech souborů a výpisy adresářů a informace o tom, že soubor neexistuje. Takže vlastně "jen" metadata.

Dokumentace a registrové hodnoty na vylepšení případně vypnutí té keše jsou zde.

Projevy keše

Dva základní projevy, které čas od času můžete pozorovat, nastávají v okamžiku, kdy jste do nějakého sdíleného adresáře (shared folder) z jednoho počítače přidali nějaký nový soubor a snažíte se ten soubor otevřít z jiného počítače. Pokud jste se z toho druhého klienta už na obsah sdíleného adresáře (shared folder) předtím dívali, nebo se ten soubor snažili otevřít, možná vám to bude i nadále říkat, že soubor neexistuje.

  • prohlížíte si výpis obsahu sdíleného adresáře a přitom tam ten soubor ještě nevidíte (tady to asi nic nehlásí, jenom ten soubor nevidíte)
  • nějaký program se snaží přistoupit do konkrétního souboru, který tam před chvilkou ještě nebyl a pořád to ještě nejde (v takovém případě by to hlásilo File Not Found)

Proč to má smysl?

Mnoho programů zkouší existenci souborů ještě předtím, než k nim přistoupí. Test existence je poměrně drahá operace. Drahá na počet paketů, nebo lépe řečeno paketových výměn (round-trip) mezi klientem a serverem. SMB protokol je tradičně dost ukecaný a prostě klient musí na druhou stranu poslat hodně paketů a čeká na ně jednotlivé odpovědi. Když máte moc dlouhé prodlevy (zpoždění, neboli latency, tedy dlouhé round-trip-time - RTT) mezi klientem a serverem, může takový test i na ADSL trvat i několik sekund.

Programy, protože mnoho programátorů o problémech SMB a RTT v životě neslyšelo, ty testy dělají opakovaně, klidně v sekvenci desítky těsně za sebou. Takže by to pak trvalo i na rychlejších sítích a pevných linkách.

SMB 2.0 to prostě vylepšilo a pokud soubor jednou nenajde, tak si to pak ještě pár sekund myslí a nechodí zbytečně do sítě.

Ty keše se samozřejmě aktualizují okamžitě na stejném stroji, ze kterého jste tu změnu provedli. Takže problém mají jenom jiné počítače, než ze kterého jste tam ten nový soubor nahrávali. Tady bych jenom dodal, že nevím, nezkoušel jsem, jestli se keš aktualizuje, pokud tam ten soubor hodíte lokálně (jenom přes NTFS) a přitom se do toho sdíleného adresáře dívate přes share a jeho síťovou cestu, i když je to na stejném stroji. Klidně bych si byl ochoten myslet, že i tak se ta keš bude uplatňovat se zpožděním.

Řešení

Jako uživatelé prostě několik sekund počkejte.

Jako programátoři nemůžete počítat s tím, že se soubor na jiném klientovi okamžitě objeví, jakmile ho do shared folder strčíte z jiného počítače. To bude chtít nějakou lepší synchronizaci. Nebo vypnout ty keště v registrech, jenže to není asi dobrý nápad pro aplikačního programátora.

Comments

SMB kes 2

Presne s tim se se potykal pred cca 3/4 rokem, po konzultaci s Vami jsem do GPO nastavil

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters

na nulu vsem a problem zmizel jak para nad hrncem....

Delalo to typicky po naskanovani dokumentu do slozky, ostatni klienti to videli az ne za par sekund, ale az tak po minute.... a to vadilo.

Roman
Roman on 8.1.2014 13:43

Re: Nové soubory umístěné ve sdíleném adresáři se na jiných SMB klientech objeví až se zpožděním

jak se teďka dívám, tak v tom článku je napsáno, že výchozí keš je dokonce 10 MINUT??? To je trošku moc na můj vkus. Ale je to samozřejmě dokonce i tak možné. Musel bych to vyzkoušet.
ondass on 8.1.2014 13:54

Re: Nové soubory umístěné ve sdíleném adresáři se na jiných SMB klientech objeví až se zpožděním

a ještě mě napadla druhá věc

- co takhle to zkusit přes jiné jméno toho stejného serveru? Jako například \\fileserver a \\fileserver.gopas.cz, nebo i \\ip.ip.ip.ip? Vzhledem k tomu, že ten klient tohle podle mě rozlišuje jako různé servery a například se do toho i znovu ověřuje (kerberos, ntlm), tak by to mohlo zafungovat.
ondass on 8.1.2014 13:57

Re: Nové soubory umístěné ve sdíleném adresáři se na jiných SMB klientech objeví až se zpožděním

Díky článku teď vím, že nejsem debil, jak jsem si při jednom takovým projevu myslel :)
Borek on 8.1.2014 16:08

Vypnut SMB2

Mysme to vacsinou riesili aktualizaciou OS na klientoch, alebo vypnutim SMB2 na strane servera podla clanku http://support.microsoft.com/kb/2696547/en-us.
Ondrej Zilinec on 9.1.2014 21:04

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments