Chapter 17. ファイルとレコードのロッキング

Jeremy Allison

Samba Team

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Eric Roseme

HP Oplocks Usage Recommendations Whitepaper

Table of Contents

機能と利便性
議論
Opportunistic Lockingの概要
SambaのOplocks制御
設定例
Microsoft Windowsのoplocksとキャッシュ制御
ワークステーションサービスのエントリ
サーバーサービスのエントリ
持続的なデータ破壊
よくあるエラー
locking.tdb のエラーメッセージ
Windows XP上でのMicrosoft Officeファイルセーブ時の問題
XP SP1でネットワーク経由でファイルを消すのに長い時間がかかる
参考文献

多くのネットワーク管理者に問題を発生させる1つの領域はロッキングである。 問題の範囲はインターネット上で検索することですぐにはっきりする。

機能と利便性

Sambaは、Microsoft Windows NT4/200xサーバーも提供する、Microsoft Windowsクライアントが 期待するすべてのロッキングのセマンティクスを提供する。

ロッキングという用語は、並外れて広い意味を持ち、この1つの用語の 配下にすべてカテゴライズされる機能の範囲をカバーしている。

Opportunistic lockingはネットワークで結合されたクライアント上で、アプリケーションの 見かけの性能を向上させることが出来る好ましい機能である。しかし、opportunistic locking プロトコルは頑丈ではなく、そのため、極端に単純化した設定か、広範囲の遅くて障害の多い ネットワーク上を超えて起動するときに、問題に遭遇する。この場合、opportunistic locking のOSによる管理か、反復的なエラーは提供することを意図した考えられる性能の利点を相殺する。

Microsoft Windows ネットワーク管理者は、ファイルとレコードのロッキングセマンティックス (動作)はSamba中かMicrosoft Windowsクライアント上のレジストリの設定で制御できることを 知っておく必要がある。

Note

時々、各Microsoft WindowsクライアントのようにSambaサーバー上でロッキングの制御の設定を 無効化する必要がある!

議論

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_FCBDENY_DOSと呼ばれる特別な互換 モードもある。

Opportunistic Lockingの概要

Opportunistic locking (oplocks)はサーバー上に存在するファイルにアクセスする時に、 ネットワークの効率を増大させる目的で、レジストリエントリ(サーバーとクライアント上) 経由でWindowsファイルシステム(APIと対照した場合)によって起動される。効率は、 以下を許容することでクライアント上にローカルにファイルをキャッシュすることにより 増大させる:

Read-ahead:

クライアントはファイルのローカルコピーから読み、ネットワークの待ち時間を なくす。

Write caching:

クライアントはファイルのローカルコピーに書き込み、ネットワークの待ち 間をなくす。

Lock caching:

クライアントはアプリケーションをローカルにロックし、ネットワークの待ち 間をなくす。

oplocksによる効率の増大は、他のプロセスからの同時アクセスのためのファイルのステータスを Windowsがモニターするために、deny-noneでオープンされていたとしても、ファイルに対する 排他的なアクセスを行うことによる。

Windowsは4つの種類のOplocksを定義する:

Level1 Oplock

リダイレクタは、ファイルがdeny none(同時アクセスを許可)で オープンしていることを確認し、ファイルに他のプロセスからの アクセスが無いことを検査し、oplocksが有効になっていることを 確認し、次に、ファイルに対するdeny-all/read-write/exclusive アクセスを許可する。その後、クライアントはキャッシュされたローカル ファイルに対して操作を実行する。

もしも2番目のプロセスがファイルをオープンしようとすると、 オリジナルのoplockをリダイレクタが"ブレーク"するまで オープンは待たされる。oplockブレークは、キャッシュしている クライアントに、サーバーにローカルファイルを書き戻し、ローカルの ロックをフラッシュし、先読みしたデータを廃棄するように通知する。 ブレークが完了し、遅延したオープンが許可され、多重プロセスが、 強制的かバイト幅ロッキングオプションによって指示されたように、 同時ファイルアクセスが出来るようになる。しかし、もしもオリジナルの ファイルがdeny-mode以外の共有モードの場合、次に、2番目の プロセスは、oplockがブレークしても、アクセスが制限されるか アクセスが拒否される。

Level2 Oplock

キャッシングを除いて、Level1 oplockのような機能は、すべての読み出しに 対してのみ重要である。すべてのその他の操作は、サーバー上でファイルの ディスクへのコピーを実行する。

Filter Oplock

ファイルへの書き込み又は削除アクセスを許可しない。

Batch 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クライアントがアクセスしたファイル

ローカルのUNIXとNFSクライアントは強制的なファイルロックメカニズムなしでファイルにアクセス する。そのため、それらクライアントプラットフォームは、ファイルをキャッシュしている Windowsクライアントにサーバーからのoplocksブレークを初期化できない。ローカルのUNIXか NFSファイルアクセスはこのため、データが壊れるようなファイルを公開している、Windows クライアントによってキャッシュされたファイルに書き込める。

もしも、ファイルがWindows間とローカルUNIXかNFSユーザーによって共有されているならば、 oplocksはoffにする。

遅くて信頼できないネットワーク

クライアントサイドの読み取りと書き込みのキャッシングが、回線上でそれらの読み書きを送る 上での大部分の差分を送る時に、oplocksが遭遇する性能向上の最も大きな可能性がある。 これは、ネットワークがとても遅く、詰まっているか分散している(WAN中の場合)には、頻繁に起きる。 しかし、ネットワークの遅延がoplocksメカニズムの信頼性に関して大きな影響があり、そのため、 潜在的に知覚できる効率の向上を十二分に相殺するoplocks問題を発生する見込みを増大する。 もちろん、もしもoplocksブレークが、決して送られる必要がなければ、これは、oplocksを利用 する最も効率的なシナリオである。

もしもネットワークが遅いか、信頼性がないばあいか、WANの場合、もしも複数のユーザーが 同じファイルを定期的に開く事がある場合、決してoplocksを設定しないこと。

マルチユーザーデータベース

マルチユーザーデータベースは、その本質的な性質から、明らかに危険である。それらは通常不定 間隔でたくさんのユーザーによって激しくアクセスされる。oplocksが有効になっている共有上で マルチユーザーデータベースを配置すると、Sambaサーバー上でのロッキング管理のボトルネックに なるだろう。手作りあるいは所用製品のデータベースアプリケーションのどちらにせよ、 共有のoplocksは無効にすること。

PDM Data Shares

IMAN、EnoviaやCleacaseのようなProcess data management (PDM)アプリケーションはWindows クライアントプラットフォームでの使用が増え、そのため、SMBによるデータ格納も増えている。 PDMアプリケーションは、重要なデータのセキュリティとアクセスのために、複数ユーザー環境を 管理する。一般的なPDM環境では、必要に応じてローカルにロードするデータは、洗練された クライアントデザインのアプリケーションに関連づけられる。更に追加で、PDMアプリケーションは 通常各クライアントのデータ状態をモニターする。この場合、クライアントサイドのデータ キャッシングは、ローカルのアプリケーションとPDMサーバーで協調して保守するために、最も 残される。任意のキャッシング作業からクライアントOSを、任意のoplocks管理から、共有上で oplocksを無効にすることによって取り除くことは適切である。

Force Userに対する注意

Sambaには、smb.confの変数によって定義されるどんなユーザーにも、接続してきたユーザーが 共有にアクセスする時に、ユーザーを変更するforce userという パラメーターをsmb.conf中に含むことが出来る。もしもoplocksが共有上で有効になっている場合、 ユーザーアクセス中の変更は、ユーザーが明示的にファイルをロードしなくとも、クライアントに送信 するoplocksブレークを発生させる。ネットワークが遅いか信頼性がない場合、ファイルにアクセス しているユーザーなしでoplocksブレークが失われることがある。これは、oplocksブレークの喪失を 補うために、絶えず再接続するクライアントとして見た目の効率低下を引き起こす。

以下を組み合わせることを防ぐ:

  • smb.conf中の共有定義中のforce user

  • 遅いか信頼性のないネットワーク。

  • Oplocksが有効。

高度なSamba Oplocksパラメーター

Sambaはタイミングと使用レベルの計測のためにoplocksメカニズムの、種々のプロパティを 管理者が調整できるoplocksパラメーターを提供する。これらのパラメーターは、問題を引き起こす ような環境中でoplocksを実装するために、すぐれた融通性を提供する。パラメーターは、 oplock break wait timeoplock contention limitである。

ほとんどのユーザー、管理者と環境にとって、もしも、これらのパラメーターが必要ならば、より良い 選択肢は、単にoplocksをoffにすることである。Samba SWATでは、両パラメーターについて、 Samba oplocksコードを読解しない限り、このパラメーターを変更しないこと。 という説明がある。これは良い助言である。

ミッションクリティカル、高信頼性

ミッションクリティカル、高信頼性を必要とする環境では、データの整合性がしばしば 優先される。複雑で高価な構成は、もしもクライアントとファイルサーバーへの接続が切れた時、 フェイルオーバーによる切り替えが、継続したデータの有効性を提供するためにすぐに行われる ように実装される。

Windowsクライアントのフェイルオーバーの動作は、確立したTCPトランスポート層の接続に 依存しているために、他のプラットフォームよりアプリケーションの中断というリスクとなる。 もしも、ファイルサーバーのフェイルオーバーで接続が中断されたならば、新しいセッションは 確立されねばならない。トランスポート層の切断から正しく復帰するためにコードが書かれている Windowsアプリケーションはまれである。そのため、ほとんどのアプリケーションは、ある種の 中断が生じることになる。最悪の場合、アボートして再起動が必要となる。

もしもクライアントセッションが、oplocksにより、ローカルに読み書きをキャッシュしている ならば、TCPの中断からアプリケーションが再起動か復帰する時、データが失われるかもしれない。 TCPの接続が失われた時、oplocksブレークはクライアントには送られない。この場合、以前の セッションからの作業は失われる。oplocksを無効にしてこのシナリオを観察すると、 もしもクライアントがリアルタイムにファイルサーバーにデータを書き込んでいたら、 フェイルオーバーはディスコネクト時に存在したディスク上のデータを提供するだろう。

ミッションクリティカル、高可用性を要求する環境では、oplocksの使用については厳重に注意を 払う必要がある。理想的には、oplocksを有効/無効にした、すべての影響があるアプリケーション について、広範囲なテストを行うべきである。

Sambaの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を無効にする

以下のようにして、共有単位で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を無効にする

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中で、 共有単位か、サーバー全体で有効に出来る。

Example 17.1. いくつかのファイルがoplocksされた共有

[global]
veto oplock files = /filename.htm/*.txt/
[share_name]
veto oplock files = /*.exe/filename.ext/


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中で共有単位あるいはグローバルにサーバー全体で有効に出来る。

Example 17.2. Oplock Break Contention Limitの設定

[global]
oplock break contention limit = 2 (default)
[share_name]
oplock break contention limit = 2 (default)


Microsoft Windowsのoplocksとキャッシュ制御

ネットワーク経由で共有データベースにアクセスする任意のアプリケーションに影響しうる 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では変わっている。

Note

Windows 2000 は、以前のWindows中でoplocksを無効にするために使うEnableOplocksレジストリ エントリを引き続き使用している。

以下のレジストリエントリを変更することによって、oplocksの許可を拒否することも出来る:

	HKEY_LOCAL_MACHINE\System\
		CurrentControlSet\Services\MRXSmb\Parameters\

		OplocksDisabled REG_DWORD 0 又は 1
		既定値: 0 (無効になっていない)

Note

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 (既定値で無効)

Note

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にバグレポートを 投稿してほしい。可能な限りのたくさんの情報をもらえると、現象の特定の手助けと、 (問題の特定と修正のための基本的なステップである)問題の再現の手助けになる。

locking.tdb のエラーメッセージ

以下のようなたくさんのエラーメッセージが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を再起動する。

Windows XP上でのMicrosoft Officeファイルセーブ時の問題

これはWindows XPのバグである。より詳細な情報は、 Microsoft KBの記事812937 を参照のこと。

XP SP1でネットワーク経由でファイルを消すのに長い時間がかかる

XP SP1を適用語、ネットワーク経由でファイルを消すのに、時々おおよそ35秒もかかる。

これはWindows XPのバグである。より詳しい情報は、 Microsoft KBの記事 を参照のこと。

参考文献

Microsoftのサポートwebサイトで、 ファイルとレコードのロッキングに関する更新された文書をチェックしても良いだろう。 追加で、Sambaのwebサイトで、 lockingという単語を探しても良いだろう。

Microsoft MSDNライブラリ上にある opportunistic locking 節は以下の通り:

Microsoft KB, OPLOCKS によるトランザクションの整合性を維持, Microsoft Corporation, April 1999, Microsoft KB の記事 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 Microsoft KB の記事 129202.



[5] Microsoftはこの件について KB 300216で解説している。