[Chapter 5] 5.5 ロックと oplock

5.5 ロックと Oplocks

一つのファイルに並列的に書き込みが行われることは、OSとしては望ましからざることである。これを避けるため、殆んどのOSでは ロック機構 を用いて、ある時点では一つのプロセスのみがファイルに書き込みを行っていることを保証する。OSは伝統的にファイル全体をロックするが、新しいOSでは、ファイル中のバイト単位での範囲をロックすることも可能である。別のプロセスが既にロックされているファイル(もしくはファイルの一部)に書き込もうとした時、その試みはOSからエラーリターンされ、ロックが解放されるまでは待つことになる。

Samba も標準的な DOS や NT のファイルシステムの(排他的)ロック要求をサポートしている。これは一つのプロセスだけがある時間サーバ上のあるファイル全体、もしくはバイト単位の範囲に書き込み可能であるというものである。更に Samba は Windows NT の世界では opportunistic lockingすなわち oplock として知られている新しいロック機構にも対応している。

5.5.1 Opportunistic Locking

opportunistic ロックにより、クライアントからのファイルアクセスの高速化を図るため、クライアントが Samba サーバに対してファイルに排他的な書き込みを行うだけでなく、ファイルの変更点をクライアント(Samba サーバではなく)にキャッシュするという通知を行えるようになる。クライアントがファイルを opportunistical にロックしたことを Samba が認識すると、Samba は opportunistic ロックを行うために、そのバージョンを記録し、クライアントがファイルの更新作業を完了するのを待つ。完了した時点で、クライアントは最終的な変更を Samba サーバに対して同期させるために送付することが求められる。

もし、別のクライアントが、最初のクライアントが作業を完了する前にファイルにアクセスしようとした場合、Samba は oplock break 要求を最初のクライアントに対して行うことができる。これにより、最初のクライアントは変更点のキャッシュを停止し、現在のファイルの状態をサーバに返却するため、割り込みをかけたクライアントは更新されたファイルの内容を利用することができる。しかし、opportunistic ロックは標準的な排他ロックの代替とはならない。opportunistic ロックは、oplock break を獲得した割り込みプロセスが、元々のプロセスがファイルに対して排他的ロックも獲得していることを発見するためだけに、ロックを確認する図 5.8 では、opportunistic ロックの動作を図解した。

図 5.8: Opportunistic locking

ロックに関して、Samba が提供するデフォルトのロック機構 -互換性のためにある標準的な DOS/Windows の排他ロックとローカルなキャッシュを可能にすることで、パフォーマンスを向上させる oplock - を用いることを強く推奨する。OSがoplock 機能を持っているのであれば、パフォーマンスの向上がみられる筈である。これらのオプションを変更する特別な理由がない限り、これらをそのままにしておくのが一番である。

5.5.2 Unix and Locking

Windows システムは、他人の行った変更の上書きを避けるために、互いに協調して動作する。しかし、Samba に格納されたファイルが UNIX のプロセスからアクセスされた場合、UNIX のプロセスが Windows の oplock について全く関知しないため、簡単にこのロックが破綻してしまう。幾つかのUNIX システムは、Samba が行う Windows のoplock を認識できるように改良が行われている。現在サポートがあるのは SGI IRIX 6.5.2f 以降のバージョンのみであるが、Linux と FreeBSD もすぐに実装されることになるだろう。

oplock を認識できるシステムの場合、Samba の設定ファイル中にkernel oplocks = yes と設定する。これによって UNIX プロセスと Windows ユーザとの間での競合をなくすことができる。

kernel oplocks をサポートしていないシステムの場合、Windows ユーザがア癖死しているファイルに UNIX のプロセスが読み書きを行うと、データが破壊される可能性がある。しかし、Samba はkernel oplocks がない場合でも簡単な防止機構を備えている: veto oplock files オプションである。Windows ユーザと UNIX ユーザの両方から Samba のファイルを利用することが予測される場合は、それらのファイル名をa veto oplock files オプションに設定しておく。これにより、マッチしたファイル名については、oplock の利用が抑止される。すなわちクライアントでのキャッシュが抑止され、Windows と UNIX のプログラムがシステムのロック機構を用いるようになり、ファイルに対する競合の検出は更新時に行われるようになる。設定例を以下に示す:

veto oplock files = /*.dbm/

このオプションは、UNIX のプロセスと Windows のユーザが .dbm という拡張子で終わるファイル名のファイルを編集することを可能にする。このオプションの文法はveto filesオプションと同様である。

ロックと oplocks に関連する Samba のオプションを表 5.8に示す。

表 5.8: ロックと Oplocks の設定オプション
オプション	パラメータ	機能	デフォルト	範囲
`share modes`	真偽値	`yes`の場合、DOS形式のファイルロックをサポートする	`yes`	共有
`locking`	真偽値	`yes`の場合、バイト範囲ロックを有効にする	`yes`	共有
`strict locking`	真偽値	`yes`の場合、バイト範囲のロックが存在する場合、そのファイル全体へのアクセスを禁止する	`no`	共有
`oplocks`	真偽値	`yes`の場合、その共有のファイルについて、クライアント上でローカルにファイルキャッシュすることが可能になる	`yes`	共有
`kernel oplocks`	真偽値	`yes`の場合、カーネルが oplock をサポートしていることを通知する	`yes`	グローバル
`fake oplocks`	真偽値	`yes`の場合、クライアントにロックが行われたことを通知するが、実際にはロックを行わない	`no`	共有
`blocking locks`	真偽値	ロックの要求者がロックの獲得を待つことが可能になる	`yes`	共有
`veto oplock files`	文字列 (ファイル名のリスト)	設定したファイルに対しては oplock を行わない	なし	共有
`lock directory`	文字列 (フルパス名)	lock 関連を含む幾つかの Samba のファイルがおかれる場所を設定する	Samba の makefile で設定される	グローバル

5.5.2.1 share modes

この最も原始的なロックは、Samba が share modesとして知られる排他ロックを行うことを可能にする。これはテキストエディタなどがファイルを明示的に上書きされることを防止するために利用する。For reference, the deny-mode locks are listed in 表 5.9.

表 5.9: SMB の排他ロック
Lock	説明
`DENY_NONE`	他のプロセスの要求を拒否しない
`DENY_ALL`	そのファイルに対する全てのオープン要求を拒否する
`DENY_READ`	そのファイルに対する読み込みのみのオープン要求を拒否する
`DENY_WRITE`	そのファイルに対する書き込みのみのオープン要求を拒否する
`DENY_DOS`	読み込みのためにオープンしている場合、他のプロセスは読み込みはできるがファイルへの書き込みはできない。書き込みのためにオープンしている場合、他のプロセスはそのファイルをオープンすることができない
`DENY_FCB`	Obsolete.

これらのロックの利用を実施する share modes パラメータは、デフォルトで有効になっている。これを無効にするには、以下のコマンドを利用する:

[accounting]
	share modes = no

行うに足る正当な理由がない限り、デフォルトのロック機構を無効にしないことを強く推奨する。多くの Windows や DOS のアプリケーションは、正しく動作する上でこれらのロック機構に依存しており、この機能がなくなるといろいろ不具合が発生するだろう。

5.5.2.2 locking

locking オプションはクライアントからの要求に応じてサーバーサイドでのバイト範囲ロックを行うか否かを制御する。Samba のサーバサイドにおけるバイト範囲ロック実装は通常のUNIXのadvisoryロックであるため、正しく振る舞っている他のUNIXプロセスがロックされたバイト範囲に上書きすることを妨げる。

このオプションは以下のようにして共有単位で指定することができる:

[accounting]
	locking = yes

locking オプションがyesの場合、ロックを要求したプロセスは現在何らかのタイプのロックを保持しているプロセスがそれをリリースするまで(もしくはクラッシュするまで)待たされることになる。このオプションがnoの場合、ファイルに対するロックやアンロックの要求は成功したように見えるにも関わらず、バイト単位のロックは保持されない。このオプションのデフォルトはyes になっているが、読み込み専用のメディアの場合は、これをオフにすることもできる。

5.5.2.3 strict locking

このオプションにより、すべてのファイルアクセスにおいて、アクセスされるバイト範囲がロックされているかどうかをチェックするようになる。クライアントが全てのロック機構を実装している場合、これは不要である。このオプションはデフォルトで no に設定されているが、共有単位で設定を行うことも可能である:

[accounting]
	strict locking = yes

このオプションが yes の場合, バイト範囲ロックを行う全てのファイルに対して強制的なロックが行われる。

5.5.2.4 blocking locks

Samba は blocking locks もサポートしている。これは範囲ロックの一種である。もしバイト範囲が利用できない場合、クライアントは自分が待つ時間を指定する。サーバはロック要求を蓄積して、定期的にファイルが利用可能になったかどうかを確認する。利用可能になると、クライアントに通知が行われるが、待ち時間が経過すると Samba はクライアントに対して要求の失敗を通知する。この実装により、クライアントが定期的にロック可能かどうかをポーリングすることを避けることができる。

このオプションは以下のように共有単位で無効にすることができる:

[accounting]
	blocking locks = no

yesに設定された場合、blocking locks がファイルに対して強制される。このオプションがnoに設定された場合、Samba は通常のファイルロック機構がそのファイルに対して行われたかのように動作する。デフォルトの値は yes である。

5.5.2.5 oplocks

このオプションはクライアントの oplock サポートを有効にしたり無効にしたりする。このオプションはデフォルトで有効になっている。しかし、以下のようにすることでこれを無効にすることもできる:

[data]
	oplocks = no

もしネットワーク環境が非常に不安定だったり、多くのクライアントが opportunistic lock の恩恵を受けられなかったりする場合はこの機能を停止した方がよいであろう。同じファイルを UNIX アプリケーション(例えば viなど)と SMB クライアントの両方からアクセスするような場合は、(前述した kerel oplocks がサポートされているOSを利用しているという幸運に芽ぐまれていない限り、)このオプションを無効にすべきである。

5.5.2.6 fake oplocks

opportunistic lock が Samba で利用可能になるまで、Samba デーモンはfake oplocks オプションを用いることで、oplock が可能であるかのように見せかけていた。このオプションが有効になると、全てのクライアントは、ロックしようとしたファイルが opportunistic lock 可能であると通知されるようになり、同時アクセスに関して全く警告されなくなる。本当の oplock が Samba で利用可能になったので、このオプションを現在用いることは避けるべきである。

5.5.2.7 kernel oplocks

Samba とは別の UNIX のアプリケーションが Windows クライアントから oplock をおこなったファイルの更新の要求を識別する場合、それは(OSにもよるが)恐らく成功し、Samba とクライアントは全く何も知らされないだろう。しかし、ローカルなUNIXのOSがそれをサポートしていた場合、Samba は oplock されたファイルのアクセスに対して警告を行い、UNIX プロセスを中断させ、クライアントに対して、Samba 経由でキャッシュされているコピーを書き戻すように通知を行い、それが完了するまでファイルのオープンを行わないであろう。これは、Samba が動作している OS のシステムカーネルが Samba と同様にoplock をハンドルする機能を持っているということになる。

この動作は、kernel oplocks オプションを以下のように設定することで有効になる:

[global]
	kernel oplocks = yes

Samba は自動的に kernel oplock を検知し、存在する場合それを利用する。執筆次点において、この機能は SGI IRIX の 6.5.2f 以降のバージョンでのみサポートされているが、Linux と FreeBSD でのサポートが近い将来に行われると期待される。kernel oplock をサポートしないシステムは、UNIX のプロセスがファイルを更新しても、クライアントシステムはその変更をすぐには知らされない。

5.5.2.8 veto oplock files

veto oplock files オプションによって、絶対にopportunistic lock を獲得できないファイル名のリストを提供することが可能である。このオプションはグローバルに提供することも、共有単位で提供することも可能である。以下に一例を示す:

veto oplock files = /*.bat/*.htm/

このオプションの値は、パターンのリストとなる。各々のパターンのエントリは、リスとされるパターンが一つだけの場合も含め必ずスラッシュ(/)文字で先頭、末尾および各パターン間を区切る必要がある。アスタリスクは、0 文字以上の文字を表すワイルドカードとして利用できる。クエスチョンマークは、任意の1文字を表す。

UNIX から更新する可能性のあるファイルや、幾つかのプロセスから同時に共有する予定のファイルについては、oplock を無効にすることを推奨する。

5.5.2.9 lock directory

このオプション (lock dirと呼ばれることもある) は、Samba が SMB の排他ロックファイルをおくディレクトリを指定する。ブラウズリストや共有メモリファイルなどのファイルも同様にこのディレクトリに置かれる。WINS が有効な場合、WINS データベースもこのディレクトリに書き込みを行う。このオプションのデフォルトは Samba の makefile で指定されるが、典型的には /usr/local/samba/var/locks である、この場所は、以下のようにして変更できる:

[global]
	lock directory = /usr/local/samba/locks

ロックファイルを /var/spool/locksのような、より一般的な場所に移したいということがない限り、通常はこのオプションを設定する必要はないであろう。


5.4 ファイル名の短縮 (Name Mangling) と大文字小文字		6. ユーザ、セキュリティ、ドメイン

Using Samba