Oportunistické zamykání

Základní myšlenkou tohoto mechanismu je urychlit práci se sdílenými soubory.

Na úrovni PC FANDu to znamená se soubory, které jsou v katalogu (návěští) označeny znakem #, resp. #R.
Na úrovni operačního systému (MS DOS) jde o soubory, otevřené (funkce MS DOSu open handle) s kódem přístupu 42H (deny none) resp. 40h.

Takto otevřené soubory standardně není možno kešovat ze serveru do paměti stanice (klienta), neboť konkurenční stanice by "neviděly" data, kešovaná na jinou stanici (Pozor na to, že nejde o kešování na úrovni serveru, které je běžné - a funguje - na všech typech známých serverů). Tento fakt (nekešování) vede k výraznému zpomalení práce se sdílenými soubory, řádově 10 - 20 násobné zpomalení oproti exclusívnímu režimu.

Smyslem použití oportunistického zamykání je to, že za určitých okolností povolí server vykešování dat na klienta i pro sdílený soubor, což vede k (výraznému) zrychlení. To je ovšem možné jen v případě, že ostatní klienti "nedělají nic závažného". Oportunistické zamykání má několik úrovní (3) z nichž některé zahrnují i další efekty, např. takové, že stanicí uzavřený soubor (close handle) server neuzavře a ponechá ho vykešovaný na stanici.

Poznámka:
DOSoví pamětníci si možná vzpomenou na utilitku FASTOPEN. Z hlediska PC FANDu však například snaha o urychlení otevírání a zavírání souborů není příliš významná, neboť aplikace PC FANDu (většinou) otevírají a zavírají soubory jen "občas".

Pokud zde přemýšlivý čtenář-programátor začíná mít podezření na zdroj možných potíží při sdílení dat, bude mít asi pravdu, neboť situace v praxi - z hlediska stability konečných aplikací vypadá následovně:

Na serverech Novel je sice (od verze 4.11, klient od verze 3.0.0) oportunistické zamykání podporované, ovšem při standardní instalaci je vypnuté. Zřejmě z toho důvodu nejsou na sítích Novell téměř žádné potíže, které by nebyly řešitelné.
U serverů Windows NT / 2000 / XP je oportunistické zamykání standardně zapnuto. Proto se servery NT často jeví jako velmi rychlé, ovšem občas se vyskytují "podivné stavy" - zaklesnutí stanic (deadlock), ztráty dat, nadměrné blokování, výrazné zpomalení při připojení druhé a další stanice. Co zatím přesně nevíme je to, zda v případě problémů je nutno oportunistické lokování zcela vypnout nebo zda by stačilo některými parametry tento mechanismus vhodně optimalizovat. Připomeňme, že PC FAND sám používá standardní zamykání oper. systému MS DOS, kdežto oportunistické zamykání je záležitost na úrovni inteligence spojení server-klient v síti LAN. Oplock je vlastnost protokolu SMB (Server Messages Block).
Na LINUXu, protokol SAMBA, je oplock také implementován, nejsou s ním však hlášeny žádné potíže, u FAND aplikací.

Odkazy

Originální (anglický) termín pro oportunistické zamykání je opportunistic lock, velmi často se používá zkráceně oplock.

Celkem dost informací je na CD-romech MSDN (Microsoft Developer Network), třeba 1/99, stačí zadat hledání termínu "opportunistic lock" nebo "oplock"
Na internetu lze použít adresy:
- Configuring Opportunistic Locking in Windows
- File and Record Locking
- Explanation of Opportunistic Locking on Windows NT
- ... vzhledem k neustálé aktualizaci WEBů prostě zadejte hledání oplock, nebo použijte pro hledání název klíče v registrech na nějakém vyhledávači nebo přímo na WEBu Microsoftu.

Stručně základní nastavení:

Podle zkušeností z praxe by se měl oplock vypnout vždy, když je podezření na problémy při práci se soubory v síťovém prostředí. To jest občasné chyby na souborech, bezdůvodné reindexování, neobvyklé zpomalení aplikace, ... V podstatě na Win NT, 2000, XP nám není známo jiné nastavení systému Win, které by mělo na souborové operace v síti LAN nějaký zřetelný vliv.
V některých diskuzích na NETu se uvádějí i možnosti optimalizace OPLOCKu, ale to asi bude dost individuální pro jednotlivé aplikace a hlavně pro konkrétní instalaci sítě.

WinNT, XP, 2000, server 2003

Registry (program REGEDIT, jen pro pokročilé !)
Na diskuzích se objevují různá doporučení pro nastavení registrů Windows. Pokud to shrneme, tak pri vypnutí OPLOCKu jde o registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters]
"OplocksDisabled"=dword:00000001
"InfoCacheLevel"=dword:0000000a

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"EnableOpLocks"=dword:00000000
"EnableOplockForceClose"=dword:00000001
"CachedOpenLimit"=dword:00000000
"AutoDisconnect"=dword:ffffffff
"SharingViolationRetries"=dword:00000000
"SharingViolationDelay"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"UseOpportunisticLocking"=dword:00000000
"UseLockReadUnlock"=dword:00000000
"UseUnlockBehind"=dword:00000000
"CacheFileTimeout"=dword:00000001

Obecně platí, že pokud není odpovídající klíč v registru uveden, platí jeho implicitní hodnota. Přesné významy jednotlivých klíčů lze dohledat na WEBu Microsoftu.

Pokud se vypnutí OPLOCKU na dané síti považuje za příliš tvrdý zásah, lze zkusit OPLOCK optimalizovat. Jasný postup na to není, jde o dynamickou záležitost každé instalace. Možnosti jsou v hodnotách klíčů:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"SizReqBuf"=dword:00003904
"SharingViolationDelay"=dword:0000000a
"SharingViolationRetries"=dword:00000002

Nějaké vysvětlení k tomu třeba zde Technet - SharingViolationRetries