Table of Contents
多くのネットワーク管理者に問題を発生させる1つの領域はロッキングである。問題の範囲はインターネット上で検索することですぐにはっきりする。
Sambaは、Microsoft Windows NT4/200xサーバも提供する、Microsoft Windowsクライアントが期待するすべてのロッキングのセマンティクスを提供する。
ロッキングという用語は、並外れて広い意味を持ち、この1つの用語の配下にすべてカテゴライズされる機能の範囲をカバーしている。
Opportunistic lockingはネットワークで結合されたクライアント上で、アプリケーションの見かけの性能を向上させることが出来る好ましい機能である。しかし、opportunistic lockingプロトコルは頑丈ではなく、そのため、極端に単純化した設定か、広範囲の遅くて障害の多いネットワーク上を超えて起動するときに、問題に遭遇する。この場合、opportunistic lockingのOSによる管理か、反復的なエラーは提供することを意図した考えられる性能の利点を相殺する。
Microsoft Windows ネットワーク管理者は、ファイルとレコードのロッキングセマンティックス(動作)はSamba中かMicrosoft Windowsクライアント上のレジストリの設定で制御できることを知っておく必要がある。
SMBサーバによって実行されることが必要な2つのタイプのロッキングがある。最初のものはオープンしているファイル中の一定の範囲のバイト範囲をクライアントがロックすることができるレコードロッキングである。2番目のものは、ファイルがオープンしているときに指定される拒否モードである。
UNIX配下のレコードロッキングのセマンティックスは、Windows配下のレコードロッキングと大幅に異なる。Samba2.2より前のSambaは、異なったSambaクライアントとの間で、適切なレコードロッキングを実装するために、ネイティブなfcntl()UNIXシステムコールを使うことを試みた。これはいくつかの理由で完全に正しいものにはならなかった。最も簡単なものは、Windowsクライアントはロックするバイトレンジとして、クライアントのOSに依存するが、2の32乗か2の64乗の範囲を指定できた。UNIXロッキングはレンジの幅として2の31乗までしかサポートしていなかった。そのため、2の31乗以上のロック要求を正確に満足させることは出来なかった。そのほかにもここに記述するのには余りにも多すぎる数多くの違いがあった。
Samba2.2以降では、UNIXシステムに依存しない、独立したレコードロッキングを完璧に実装した。もしもクライアントが0から2の31乗までの間でバイト幅ロックを要求した場合、SambaはUNIXシステムにこの要求を落として扱う。他のどのようなロックもUNIXでは扱わない。
厳密に言うと、Sambaサーバはファイル上への各読み/書きの呼び出し前にロックのチェックをすべきである。不幸にも、fcntl()が機能する方法で、これは遅延を引き起こし、rpc.lockd
に負荷を掛けることになる。これは、それに対してロッキングが重要なとき、読み書きの前にロッキングを呼び出すことをクライアントは独立して行うはずという理由で、ほとんど常時不必要である。既定値では、Sambaはクライアントによって明示的に問い合わせがあったときにのみロッキングコールを行うが、もしもstrict locking = yesを設定した場合、読み/書きの呼び出し毎にロックチェックの呼び出しを行う。
locking = noを使うことによってバイト幅ロッキングを完全に停止することも出来る。これは、ロッキングをサポートしない共有か、必要がないとき(たとえばCD-ROMなど)に便利である。この場合、Sambaは毎回OKであると、ロッキング呼び出しの戻り値をクライアントに返すようにごまかす。
2番目のクラスのロッキングは、deny modesである。これらは、そのオープンに対して同時に許されるべきアクセスのタイプを決めるため、ファイルをオープンしたときにアプリケーションによって設定される。クライアントは、DENY_NONE
, DENY_READ
,DENY_WRITE
, か DENY_ALL
を問い合わせできる。DENY_FCB
と DENY_DOS
と呼ばれる特別な互換モードもある。
Opportunistic locking (oplocks)はサーバ上に存在するファイルにアクセスする時に、ネットワークの効率を増大させる目的で、レジストリエントリ(サーバとクライアント上)経由でWindowsファイルシステム(APIと対照した場合)によって起動される。効率は、以下を許容することでクライアント上にローカルにファイルをキャッシュすることにより増大させる:
oplocksによる効率の増大は、他のプロセスからの同時アクセスのためのファイルのステータスをWindowsがモニタするために、deny-noneでオープンされていたとしても、ファイルに対する排他的なアクセスを行うことによる。
Windowsは4つの種類のOplocksを定義する:
リダイレクタは、ファイルがdeny none(同時アクセスを許可)で オープンしていることを確認し、ファイルに他のプロセスからの アクセスが無いことを検査し、oplocksが有効になっていることを 確認し、次に、ファイルに対するdeny-all/read-write/exclusive アクセスを許可する。その後、クライアントはキャッシュされたローカル ファイルに対して操作を実行する。
もしも2番目のプロセスがファイルをオープンしようとすると、 オリジナルのoplockをリダイレクタが"ブレーク"するまで オープンは待たされる。oplockブレークは、キャッシュしている クライアントに、サーバにローカルファイルを書き戻し、ローカルの ロックをフラッシュし、先読みしたデータを廃棄するように通知する。 ブレークが完了し、遅延したオープンが許可され、多重プロセスが、 強制的かバイト幅ロッキングオプションによって指示されたように、 同時ファイルアクセスが出来るようになる。しかし、もしもオリジナルの ファイルがdeny-mode以外の共有モードの場合、次に、2番目の プロセスは、oplockがブレークしても、アクセスが制限されるか アクセスが拒否される。
キャッシングを除いて、Level1 oplockのような機能は、すべての読み出しに 対してのみ重要である。すべてのその他の操作は、サーバ上でファイルの ディスクへのコピーを実行する。
oplocksはファイルシステムによって起動され、アプリケーションAPIではないということは重要な詳細事項である。そのため、あるアプリケーションはoplockされたファイルをクローズできるが、ファイルシステムはoplocksを放棄しない。oplockのブレークが発生したとき、ファイルシステムは次に、2番目のプロセスによる、次のファイルオープンの準備中で、単純にファイルをクローズする。
Opportunistic lockingは、この機能に対して、実際には妥当ではない名前である。この機能の真の利点は、クライアントサイドのデータキャッシングであり、oplocksはネットワーク上のディスクストレージにデータを書き戻すための、単なる通知メカニズムである。oplocksの制限は、サーバとキャッシュしているクライアント間でのoplocksブレーク(通知)を処理するためのメカニズムの信頼性である。もしもこの交換に失敗すると(通常、数多くの理由でタイムアウトするという場合)、クライアントサイドキャッシングの優位性は否定される。
ユーザか管理者が考慮すべき、実際の決断点は、ローカルにクライアント上にキャッシュされる複数のユーザのデータ間で共有するのは賢明であるかどうかと言うことである。多くの場合、答えは「否」である。データをキャッシュするかしないかの決断は真の質問であり、そのため、oplocksはクライアントサイドのキャッシングのトグルとして取り扱うべきである。クライアントサイドのキャッシングが望ましく、信頼性がある場合、それを“on”にする。クライアントサイドのキャッシングが不必要で、信頼性に欠け、あるいは反生産的な場合、“off”にする。
Oplocksは既定値ではすべての設定された共有上にSambaによって“on”に設定されているので、もしも潜在的な利便性が、遅延の可能性より小さい場合、それぞれのケースで決定するときには注意深く行うべきである。以下の推奨項目は、oplocksが効果的になる環境を特徴づけるのに役に立つだろう。
Windowsのoplocksは簡易な効率向上機能である。これは堅牢でも信頼できるプロトコルではない。oplocksのすべての実装は、考え得る性能と信頼性との間でのトレードオフとして評価されるべきである。信頼性は、上記での継続したルールが適用されないように減少する。oplockが有効で、WAN上をまたいで、南太平洋の環礁の、高信頼性のサーバ上で、ミッションクリティカルな、多人数で使う会社のデータベースが台風にさらされている状況を考えてみよう。この設定はoplockの問題に遭遇するだろう。
Oplocksは、クライアントサイドでのデータキャッシングのための構成要素のトグルとして扱われる時、クライアントの性能を理解するために有益であり得る。もしもデータのキャッシングがさえぎられそうな場合、oplocksの使用は評価されるべきである。Sambaはすべての共有に対してoplocksを既定値で有効にする。サーバ上の共有データ、サーバネットワークの信頼性と各共有のoplocksの設定の使用法をクライアントに提供すべきであることに注意深く注意を払う。ミッションクリティカルな領域、高信頼性環境では、データの整合性はしばしば優先度が高くなる。複雑で高価な構成は、もしもクライアントがファイルサーバへの接続が切れた時、継続したデータの可用性を提供するために、フェイルオーバによるサーバ切り替えがすぐに出来ることが出来るように、実装される。
Windowsクライアントのフェイルオーバの動作は、確立しているTCP/IPトランスポートコネクションに依存するという理由で、他のプラットフォームよりもアプリケーションの中断のリスクがより大きい。もしも、ファイルサーバのフェールオーバとして接続が中断されたならば、新しいセッションは再度確立せねばならない。トランスポート層が切断された時から正しく復帰するためにプログラミングされているWindowsクライアントはまれである。そのため、ほとんどのアプリケーションは、ある種の中断を経験することになる。最悪の場合、アボートして再起動が必要となる。
もしもクライアントセッションが、oplocksのために、ローカルに書き込みと読み取りをキャッシングしているなら、TCPの中断からアプリケーションの再起動または復帰のときにデータが喪失するだろう。ファイルサーバが復旧すると、oplocksのブレークはクライアントには送信されない。この場合、先のセッションからの作業は失われる。oplocksが無効になっていて、リアルタイムにファイルサーバにクライアントがデータを書き込むというシナリオを観察することで、フェイルオーバは、切断時に存在するディスク上のデータを提供する。
ミッションクリティカルな、高可用性環境では、oplocksに対して厳重な注意をはらうべきである。理想的には、広範囲なテストは、oplocksが有効かつ無効な状態で、すべての影響されるアプリケーションで行うべきである。
oplocksは、単一のユーザか、同時に1人のみのユーザで、排他的にアクセスされる共有に限定される時に最も有効である。oplocksの本当の姿は、ローカルにクライアントでキャッシングされているデータという理由により、キャッシングを中断する何らかの操作は遅延を引き起こす。
ホームディレクトリは、oplocksが問題ないと理解され、効率を得られる、最も明らかな例である。
共有中のファイルへ各追加ユーザがoplocksを有効にしてアクセスすると、遅延の可能性と、結果として生じる性能の低下が増大する。複数のユーザが、oplocksを有効にした共有上のファイルにアクセスする時、oplocksブレークの送受信と、の管理と、データのオフセットをフラッシュするためにクライアントのキャッシングを他のクライアントが待つ間に結果として生じる遅延の管理の影響は、キャッシュしているユーザの効率向上を相殺する。
oplocksを設定して各追加のクライアントがファイルにアクセスする時、潜在的な効率の向上は否定され、最終的には効率のボトルネックとなる。
ローカルのUNIXとNFSクライアントは強制的なファイルロックメカニズムなしでファイルにアクセスする。そのため、それらクライアントプラットフォームは、ファイルをキャッシュしているWindowsクライアントにサーバからのoplocksブレークを初期化できない。ローカルのUNIXかNFSファイルアクセスはこのため、データが壊れるようなファイルを公開している、Windowsクライアントによってキャッシュされたファイルに書き込める。
もしも、ファイルがWindows間とローカルUNIXかNFSユーザによって共有されているならば、oplocksはoffにする。
クライアントサイドの読み取りと書き込みのキャッシングが、回線上でそれらの読み書きを送る上での大部分の差分を送る時に、oplocksが遭遇する性能向上の最も大きな可能性がある。これは、ネットワークがとても遅く、詰まっているか分散している(WAN中の場合)には、頻繁に起きる。しかし、ネットワークの遅延がoplocksメカニズムの信頼性に関して大きな影響があり、そのため、潜在的に知覚できる効率の向上を十二分に相殺するoplocks問題を発生する見込みを増大する。もちろん、もしもoplocksブレークが、決して送られる必要がなければ、これは、oplocksを利用する最も効率的なシナリオである。
もしもネットワークが遅いか、信頼性がないばあいか、WANの場合、もしも複数のユーザが同じファイルを定期的に開く事がある場合、決してoplocksを設定しないこと。
マルチユーザデータベースは、その本質的な性質から、明らかに危険である。それらは通常不定間隔でたくさんのユーザによって激しくアクセスされる。oplocksが有効になっている共有上でマルチユーザデータベースを配置すると、Sambaサーバ上でのロッキング管理のボトルネックになるだろう。手作りあるいは所用製品のデータベースアプリケーションのどちらにせよ、共有のoplocksは無効にすること。
IMAN、EnoviaやCleacaseのようなProcess data management (PDM)アプリケーションはWindowsクライアントプラットフォームでの使用が増え、そのため、SMBによるデータ格納も増えている。PDMアプリケーションは、重要なデータのセキュリティとアクセスのために、複数ユーザ環境を管理する。一般的なPDM環境では、必要に応じてローカルにロードするデータは、洗練されたクライアントデザインのアプリケーションに関連づけられる。更に追加で、PDMアプリケーションは通常各クライアントのデータ状態をモニタする。この場合、クライアントサイドのデータキャッシングは、ローカルのアプリケーションとPDMサーバで協調して保守するために、最も残される。任意のキャッシング作業からクライアントOSを、任意のoplocks管理から、共有上でoplocksを無効にすることによって取り除くことは適切である。
Sambaには、smb.conf
の変数によって定義されるどんなユーザにも、接続してきたユーザが共有にアクセスする時に、ユーザを変更するforce userというパラメータをsmb.conf
中に含むことが出来る。もしもoplocksが共有上で有効になっている場合、ユーザアクセス中の変更は、ユーザが明示的にファイルをロードしなくとも、クライアントに送信するoplocksブレークを発生させる。ネットワークが遅いか信頼性がない場合、ファイルにアクセスしているユーザなしでoplocksブレークが失われることがある。これは、oplocksブレークの喪失を補うために、絶えず再接続するクライアントとして見た目の効率低下を引き起こす。
以下を組み合わせることを防ぐ:
smb.conf
中の共有定義中のforce user 。
遅いか信頼性のないネットワーク。
Oplocksが有効。
Sambaはタイミングと使用レベルの計測のためにoplocksメカニズムの、種々のプロパティを管理者が調整できるoplocksパラメータを提供する。これらのパラメータは、問題を引き起こすような環境中でoplocksを実装するために、すぐれた融通性を提供する。パラメータは、oplock break wait timeとoplock contention limitである。
ほとんどのユーザ、管理者と環境にとって、もしも、これらのパラメータが必要ならば、より良い選択肢は、単にoplocksをoffにすることである。Samba SWATでは、両パラメータについて、“Samba oplocksコードを読解しない限り、このパラメータを変更しないこと。”という説明がある。これは良い助言である。
ミッションクリティカル、高信頼性を必要とする環境では、データの整合性がしばしば優先される。複雑で高価な構成は、もしもクライアントとファイルサーバへの接続が切れた時、フェイルオーバによる切り替えが、継続したデータの有効性を提供するためにすぐに行われるように実装される。
Windowsクライアントのフェイルオーバの動作は、確立したTCPトランスポート層の接続に依存しているために、他のプラットフォームよりアプリケーションの中断というリスクとなる。もしも、ファイルサーバのフェイルオーバで接続が中断されたならば、新しいセッションは確立されねばならない。トランスポート層の切断から正しく復帰するためにコードが書かれているWindowsアプリケーションはまれである。そのため、ほとんどのアプリケーションは、ある種の中断が生じることになる。最悪の場合、アボートして再起動が必要となる。
もしもクライアントセッションが、oplocksにより、ローカルに読み書きをキャッシュしているならば、TCPの中断からアプリケーションが再起動か復帰する時、データが失われるかもしれない。TCPの接続が失われた時、oplocksブレークはクライアントには送られない。この場合、以前のセッションからの作業は失われる。oplocksを無効にしてこのシナリオを観察すると、もしもクライアントがリアルタイムにファイルサーバにデータを書き込んでいたら、フェイルオーバはディスコネクト時に存在したディスク上のデータを提供するだろう。
ミッションクリティカル、高可用性を要求する環境では、oplocksの使用については厳重に注意を払う必要がある。理想的には、oplocksを有効/無効にした、すべての影響があるアプリケーションについて、広範囲なテストを行うべきである。
oplocsは、ユニークなWindowsファイルロッキング機能である。これは真のファイルロッキング機能ではないが、Windowsのファイルロッキングの多くの議論中に含まれ、そのため、事実上のロッキング機能として考えられる。oplocksは、実際の所、Windowsクライアントファイルキャッシング機能の一部である。これは、エンタープライズコンピューティング領域中に存在する、種々のカスタマイズされたネットワーク上で実装される時には、とりわけ丈夫か信頼性がある機能ではない。
SambaではWindowsと同様に、クライアント側のキャッシング機構であるoplockを、サーバ側のコンポーネントとして実装している。Windowsの機能設計上、oplock は軽量型として設定されている(機能が限定されている)。このためoplockを効果的に設定するには、これらの制限事項の把握が不可欠であり、またカスタマイズされたネットワークやクライアントの利用状況に特化したデータアクセスを構成する際の理解が行き届いている場合にのみ適用されるものである。
Oplocksの基本的な意味は、クライアントが、変更中にそのハードドライブ上にファイルをダウンロードし、キャッシュ出来るということである。もしも、2番目のクライアントがファイルにアクセスしようとした場合、最初のクライアントはブレークを受け取り、サーバに対して同期を取らねばならない。これは、ある場合においては、かなり効率が向上する。いくつかのプログラムは、単一の変更のためにサーバに対してファイルの内容すべてを戻して同期を取ることを行うものもある。
Level1 Oplocks(単に“oplocks”としても知られている)はopportunistic lockingの別の言い方である。
Level2 Oplocksはリードオンリとして取り扱うファイルに対してopportunistic lockingを提供する。通常これはリードオンリか、クライアントが、ファイルのオープン時に、最初に書き込まないファイルに使われる。
Kernel OplocksはLinux kernelに、Microsoft Windowsネットワークファイルロッキングのより良い統合を提供するにも関わらず、Sambaがoplocksしたファイルとの共存を許可する基本的な方式である。SGI IRIXとLinuxは現時点でoplocksを認識するただ2つのOSである。
使用しているシステムがkernel oplocksをサポートしている限り、UNIX/LinuxとSMBクライアントの両方から同じファイルをアクセスする時、oplocksを無効にすべきである。もしも、複数のクライアントからデータベースファイルを共有している時(たとえば、Microsoft Access)、顕著なパフォーマンスダウンと、さらに、最初の場所におけるデータベースのアクセス問題が発生する、ファイル全体(1つのレコードではなく)の同期に影響する、最初のクライアントが受け取る任意のブレークという理由で、oplocksは気にせず常時無効にすべきである。特に、Microsoft Outlookのパーソナルフォルダ(*.pst)はoplocksに対してとてもひどく反応する。疑っているのならば、oplocksを無効にして、その辞典からシステムを調整してみると良いだろう。
もしもクライアントサイドのキャッシングが無効で、ネットワークの信頼性があるのであれば、oplocksをonにすることで利点が得られる。もしも、使用しているネットワークが遅くて、信頼性がないか、他のファイル共有方式(たとえばNFS)との間でファイルを共有しているか、WAN経由の場合か、頻繁に同一ファイルを複数の人がアクセスする場合、クライアントがoplocksブレークを送るオーバヘッドからの利益を得られず、そのかわりに共有に対してoplocksを無効にしたいと思うだろう。
考慮すべき他の要素は、ファイルアクセスの認識されたパフォーマンスである。もしもoplocksが使用するネットワーク上で、わかるほどのスピード向上を提供しない場合、それを取り扱う難しさ分の価値がないかもしれない。
以下の節では、Sambaロッキングの制御に関する2つの異なった側面について評価する。
以下のようにして、共有単位でoplocksを無効にすることが出来る:
[acctdata] |
oplocks = False |
level2 oplocks = False |
既定値のoplocksタイプはLevel1である。Level2 oplocksはsmb.conf
ファイル中で、共有単位に有効に出来る。
代わりに、以下のようにして、共有内でファイル単位にoplocksを無効に出来る:
veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/ |
もしも、Sambaのログエントリから確認出来る、oplocksの問題に遭遇した場合、安全を期すために、oplocksとLevel2 oplocksを無効にしても良い。
Kernel oplocks は、キャッシュされているファイルをUNIXプロセスがオープンしようとする時に、(もしもUNIX kernelがWindowsクライアントに対してoplocksを送信する機能がある時)Sambaに対して通知するsmb.conf
パラメータである。このパラメータはUNIXと、Sambaサーバ上でoplocksが有効になっているWindows間で共有するファイルをアドレスする。UNIXプロセスはWindowsクライアントによってoplockedされた(キャッシュされた)ファイルを開くことが出来、ファイルがデータ破壊のリスクがあるという事を伝える、oplocksブレークをsmbdプロセスは送らない。もしもUNIX kernelがoplockブレークを送る機能があるならば、kenel oplocksパラメータは、Sambaにoplockブレークを送ることを有効にする。kernel oplocksは、smb.conf
ファイル中でサーバ単位に有効に出来る。
kernel oplocks = yes |
既定値はnoである。
Veto oplocksは、oplocksが無効になる特定のファイルを識別するための、smb.conf
パラメータである。veto oplocksに設定されているファイルをWindowsクライアントがオープンする時、クライアントはoplocksが許可されず、すべての操作はクライアント上にキャッシュされたファイルのコピーの代わりにディスク上のオリジナルのファイル上で実行される。UNIXプロセスとoplocksを無効にしたそれらファイルとの間で共有されるファイルを明示的に識別することで、サーバ全体でのoplocks設定が、データ破壊のリスクがない、ファイルのキャッシングという効率の向上を、Windowsクライアントが利用できることを有効にできる。veto oplocksは、以下の“いくつかのファイルがoplocksされた共有”で示されるような、smb.conf
中で、共有単位か、サーバ全体で有効に出来る。
oplock break wait timeは、smb.conf
中のパラメータで、oplockブレーク要求をSambaが繰り返す時間感覚を調整する。Sambaは“Sambaのoplocksコードを読んで理解しない限りこのパラメータを変更しないこと”と忠告している。oplock break wait timeは、以下のように、smb.conf
中でグローバルな形でのみ設定できる。
oplock break wait time = 0 (default) |
Oplock break contention limitは、smb.conf
中のパラメータで、パラメータによって指定された制限に、設定された数多くの競合するクライアントが到達する場合、 oplockを許可するためのSambaサーバのレスポンスを制限する。Sambaは“Sambaのoplocksコードを読んで理解しない限りこのパラメータを変更しないこと”と忠告している。oplock break contention limitは、“Oplock Break Contention Limitの設定”のように、smb.conf
中で共有単位あるいはグローバルにサーバ全体で有効に出来る。
ネットワーク経由で共有データベースにアクセスする任意のアプリケーションに影響しうるWindows 2000/XPワークステーション上でアプリケーション(Norton Antivirusのような)を動かす時によく知られている問題がある。これは、Windows 2000/XP OSの既定値の設定の結果によるものである。他の 2000/XPコンピュータ上の共有データベースファイルに、ワークステーションがアクセスする時、Windows 2000/XP OSは、ファイルをロックし、情報をローカルにキャッシュすることで効率を向上することを試みる。これが起きると、アプリケーションは、ネットワーク操作中、“アクセスが拒否されました”というエラーが表示されて適切に動作しなくなる。
データファイル(データファイルがそこに格納されて、他のWindows PCによってアクセスされるという意味で)のためのデータベースサーバとして振る舞う、NTファミリの、すべてのWindows OSは、データファイルの破損を防ぐリスクを最小限にするために、oplocksを無効にする必要があるかもしれない。これには、Windows 9x/Me、Windows NT、Windows 200xとWindows XPが含まれる。[5]
もしも、サーバの代わりにWindows NTファミリのワークステーションを使っているならば、そのワークステーション上でoplocksを無効にしなければならない。例えば、もしも、Windows NT サーバの代わりにWindows NT ワークステーションをPC上で使っていて、その上に、他のWindows PCからアクセスされるデータファイルがあるならば、そのシステム上でoplocksを無効にしなければならないかもしれない。
大きな違いは、oplocksを無効にするための値を入れるWindowsレジストリの位置である。LanManServerの位置の代わりにLanManWorkstationの位置が使われる。
Windowsレジストリエディタを使ってこのレジストリの値を検査(必要に応じて変更か追加)することができる。このレジストリ値を変更する時、新しい設定を反映させるために、PCを再起動しなければならない。
oplocksのためのクライアントレジストリエントリの位置は、Microsoft Windows NTよりも前の位置から、Windows 2000では変わっている。
Windows 2000 は、以前のWindows中でoplocksを無効にするために使うEnableOplocksレジストリエントリを引き続き使用している。
以下のレジストリエントリを変更することによって、oplocksの許可を拒否することも出来る:
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\MRXSmb\Parameters\ OplocksDisabled REG_DWORD 0 又は 1 既定値: 0 (無効になっていない)
OplocksDisabledというレジストリエントリ値は、リモートファイル上のoplocksの要求のあるなしをWindowsクライアント上で設定する。oplocksを無効にするためには、OplocksDisabledの値は1に設定しなければならない。
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 又は 1 既定値: 1 (既定値で有効) EnableOpLockForceClose REG_DWORD 0 又は 1 既定値: 0 (既定値で無効)
EnableOplocksという値はWindowsベースのサーバ(ファイルを共有しているワークステーションを含む)で、ローカルファイル上のoplocksを許可/拒否することを設定する。
クローズまたはプログラム終了時でオープンしているoplocksを強制的に終了するためには、EnableOpLockForceCloseを1に設定しなければならない。
Level2 oplocksの動作概要は以下の通り:
ステーション1がoplockを要求してファイルを開く。
他のどのステーションもファイルを開かない間、サーバはステーション1に排他的oplockを許可する。
ステーション2がoplockを要求してファイルを開く。
ステーション1がまだファイルを書き込んでいないなら、サーバはステーション1にレベル2の oplockのブレーク通知を行う。
ステーション1はローカルにバッファした情報をサーバに書き戻す。
ステーション1はレベル2のoplockを素unしたサーバに情報を送る(代わりにステーション1は ファイルをクローズすることが出来たはずである)。
サーバはステーション2のオープン要求に対応し、レベル2のoplockを許可する。 その他のステーションは同じくファイルを開くことが出来、同様にレベル2のoplockが 許可される。
ステーション2(か、ファイルをオープンしている他のステーション)はSMB書き込み要求を 送る。サーバは書き込み応答を返す。
サーバは、ファイルをオープンしているすべてのステーションに対して、ロックを 壊さないこと、すなわちファイルに対して oplock を保持しているステーションが ないことを確認する。この時点で、ワークステーションはキャッシュされた 書き込みもロックも保持していないため、break-to-none 勧告に対して応答する 必要がないからである。それぞれのワークステーションは、単にローカルで キャッシュしている先読みデータを無効にするだけでよい。
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanWorkstation\Parameters UseOpportunisticLocking REG_DWORD 0 又は 1 既定値: 1 (真)
これは、リダイレクタがoplockの効率向上機能を使うかどうかを指示する。このパラメータは問題を判別するためにのみ無効にすべきである。
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 又は 1 既定値: 1 (真)
これは、サーバが、ファイルにoplocksを使うことをクライアントに対して許可するかどうかを指定する。oplocksは明確に効率を向上させるが、特にWANのような、ある種のネットワーク上でキャッシュされたデータを失う可能性がある。
MinLinkThroughput REG_DWORD 0 は秒あたり無限のバイト量 既定値: 0
これは、この接続のための、生の(raw) I/Oとoplocksを無効にする前に、サーバによって許可される最小のリンクスループットを指定する。
MaxLinkDelay REG_DWORD 0 から 10万秒 既定値: 60
これは、リンクのディレイで許される最小限の時間を指定する。もしもこの値よりも遅延が大きい場合、サーバは生の(raw)I/Oとoplocksを、この接続では無効にする。
OplockBreakWait REG_DWORD 10 から 180 秒 既定値: 35
これは、oplockブレーク要求に対してクライアントが返答するまで、サーバが待つ時間を指定する。より小さな値はより速やかにクラッシュしたクライアントを検出できるが、キャッシュしたデータを失う可能性がある。
もしもこの章で議論されている設定のすべてを適用したが、データの破壊問題と他の症状が持続しているのであれば、追加して監視するものがある。
単独の欠陥があるネットワークカードのような、欠陥があるネットワークハードウェアについて、開発者から信用できる報告を受けていることが、読み取りキャッシングとデータ破壊に類似している兆候を引き起こす。もしも、繰り返しインデックスした後にもかかわらす、持続的なデータ破壊が起きているならば、問い合わせ中でデータファイルの再構築をしなければならないかもしれない。これは、リビルドするようなのと同じいくつかの定義で新しいデータファイルを作成することを改善し、古いファイルから新しいファイルにデータを転送する。Samba知識ベース中で見つけることが出来る、これを行う、いくつかの手法がある。
サーバをインストールするやいなや、問題が表面化するサイトがある。他のサイト内では長い間問題が表面化していない。例外を除いてほとんど、問題が表面化したとき、当惑と、潜在的なデータ破壊を引き起こすだろう。
過去数年の間、Sambaがデータ破壊を引き起こすというクレームの、数多くの不満が、Sambaメーリングリスト上に投稿されてきた。3つの原因が認識されてきた:
不正なoplocksの設定(アプリが使うものとの非互換)。これは、Microsoft Windows NT4か Microsoft Windows 200xベースで使っているサーバでも共通の問題である。ソフトウェア アプリケーションベンダのファイルロッキングに関する設定手順に急いで従うべきである。 もしも疑うのであれば、サーバとクライアント両方でoplocksを無効にする。Microsoft Windowsクライアント上でキャッシングするすべての形式のファイルを無効にすることも 必要かもしれない。
不完全なネットワークカード、ケーブル、あるいはハブ/スイッチ。これは、一般的に 低コストネットワークハードウェアにおける一般的な事項であるが、より高級なハード ウェアにおける非互換性の問題も時折ある。
データファイルを書く時にSambaのログファイルに時折痕跡が残ることがある。これは、 ごく少数のサイトで報告されていて(過去3年でおおよそ5つ)、すべての再現試験は 失敗した。Sambaチームはこの現象を捕まえられず、そのため、何らかの特定の現象と して分離できていない。Sambaを使う非常に数多くのシステムがあることを考えると、 Sambaチームと同様に、これに影響を受けたサイトにとって、これはいらいらする、 やっかいな難問である。もしも、このタイプの現象に遭遇したならば、遅滞なく、 SambaのBugzillaにバグレポートを 投稿してほしい。可能な限りのたくさんの情報をもらえると、現象の特定の手助けと、 (問題の特定と修正のための基本的なステップである)問題の再現の手助けになる。
“ 以下のようなたくさんのエラーメッセージがSambaのログ中にある: ”
tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic 0x4d6f4b61 at offset=36116
“ これは何を意味するのか? ”
このエラーはtdbファイルが壊れていることを表示している。smbdのすべてのプロセスを停止し、 locking.tdbを削除してsmbdを再起動する。
Microsoftのサポートwebサイトで、ファイルとレコードのロッキングに関する更新された文書をチェックしても良いだろう。追加で、Sambaのwebサイトで、locking
という単語を探しても良いだろう。
Microsoft MSDNライブラリ上にある opportunistic locking 節は以下の通り:
Microsoft KB, “OPLOCKS によるトランザクションの整合性を維持”,Microsoft Corporation, April 1999, MicrosoftKB の記事 224992(訳注:機械翻訳).
Microsoft KB, “Windows で Opportunistic Lock を構成する”,Microsoft Corporation, April 2001 Microsoft KB の記事 296264.
Microsoft KB, “PC Ext: Windows NT の Opportunistic Locking の説明”,Microsoft Corporation, April 1995 MicrosoftKB の記事 129202.