vfs_fileid — クラスター構成時で使えるように、 ユニークなデバイス ID 値で file_id 構造体を生成
vfs objects = fileid
この VFS モジュールは samba(7) システムの一部である。
ファイルロックの際、Samba は file_id 構造体を使ってファイルを一意に
特定する。デフォルトでは、file_id には stat()
システムコールで返されたデバイスおよび inode 番号が格納されている。
file_id はファイルの一意な識別子であるため、これはある特定のクラスター
構成のの中では、すべてのノードで同じ値である必要がある。
このモジュールは SMB_VFS_FILE_ID_CREATE()
の動作を
オーバーライドし、設定されたアルゴリズム( "fileid:algorithm"
オプションを参照のこと)に従ってデバイス番号を生成する。
fsname 又は fsid アルゴリズムを使う場合、file_id を生成するために、
すべてのマウントされたファイルシステムにおいて、
stat()
と statfs()
呼び出しが必要である。
たとえば、NFS ファイルシステムが応答しなくなると、そのような呼び出しは
ブロックされ、smbd プロセスが応答しなくなる。
"fileid:fstype deny"、"fileid:fstype allow"、"fileid:mntdir deny"、
または "fileid:mntdir allow" オプションを使うことで、潜在的に応答しない
ファイルシステムを無視する。
指定できるアルゴリズムはfsname
、
fsid
, next_module
である。既定値は
fsname
である。また、以下は古いアルゴリズムである:
fsname_nodirs
, fsname_norootdir
,
fsname_norootdir_ext
と hostname
。
fsname
アルゴリズムでは、
デバイス ID を カーネルのデバイス名から生成する。
fsid
アルゴリズムは、デバイス ID を
statfs()
システムコールで返された
f_fsid
から生成する。
next_module
アルゴリズムは、モジュールチェイン
内の次の vfs モジュールに id を生成させる。これは主に、fileid
モジュールが提供する、さまざまな 'nolock' 機能と結合して使われる。
古いhostname
アルゴリズムは、ホスト名を
ハッシュして一意のデバイス ID と低レベルの デバイス id を生成する。
また、fileid:nolock_all_inodes=yes
も設定されて
いるものとする。これは、意図的に、クラスタ中のディレクトリの
一貫性を破るために使用でき、fileid:nolock_max_slots
では、ノード内のローカルプロセス間でも同じことができる。注意:
これが何をするかが分かっていない限り、これを使わないこと!
これは、fileid:nolock_all_inodes=yes
を
前提とする。
古いfsname_nodirs
アルゴリズムは、
fileid:nolock_all_dirs=yes
と共に
fsname
を使うための別名である。
注意:これが何をするかが分かっていない限り、これを使わないこと!
よりきめ細かなアプローチについては、
fileid:nolock_paths
を参照のこと。
古いfsname_norootdir
アルゴリズムは、
fileid:nolock_paths= 「.」
と
同時に fsname
アルゴリズムを使うための
別名である。これは、意図的に、共有のルートディレクトリに対する
クラスタ内のロック一貫性を破るために使用できることを意味する。
古いfsname_norootdir_ext
アルゴリズムは、
fileid:nolock_paths= 「.」
と
fileid:nolock_max_slots = 18446744073709551615
と共に fsname
を使うための別名である。
これは、意図的に、共有のルートディレクトリに対するロックの一貫性を
完全に破るために使用できることを意味する。ローカルプロセスですら
もはやロックの一貫性はない。
このオプションはfileid:algorithm
オプションの
レガシーな(古い)バージョンである。これは Samba 3.0 のカスタム
バージョンにおいて、フィールドマッピング機能に関する以前のバージョンで
使われていた。
file_id 生成時に無視されるファイルシステムタイプの一覧。
file_id 生成時に有効となるファイルシステムタイプの一覧。 このオプションが設定された場合、ここで指定されたファイルシステムタイプ 以外は無視される。
file_id 生成時に無視される、ファイルシステムマウントポイント の一覧。
file_id 生成時に有効となる、ファイルシステムマウントポイントの 一覧。このオプションが設定された場合、ここで指定されたファイルシステム マウントポイント以外は無視される。
このオプションは nolock
アルゴリズムの動作を
変更して、同一ホスト上の個々のプロセス間のロックの一貫性を破る。
既定では、ホストごとに有効な同時スロットは1つだけである。スロット数を
増やすことで、ある i ノード上で競合なしに動作する並列プロセスの数を
指定できる。その数は、通常論理 CPU 数よりも大きく、num_cpus の2倍に
なる。
このオプションは、すべてのの ディレクトリ i ノードに対して、
fileid nolock の動作の作用をトリガする。これは、すべてのディレクトリの
ロック一貫性を意図的に破るために使用できる。
注意: これが何をするかが分からない限り、これを使用しないこと!
これは、 SMB 文法を壊す!
より詳細なアプローチについては、fileid:nolock_paths
を
参照のこと。
このオプションは、すべてのディレクトリ i ノードに対して、
fileid nolock アルゴリズムの仕様をトリガする。
注意:これが何をするかが分からない限り、これを使用しないこと!
これは SMB 文法を壊し、データの破壊につながる!
より詳細なアプローチについては、fileid:nolock_paths
を
参照のこと。
このオプションは、ファイルやディレクトリを参照するパスリストを 指定する。意図的にロックの一貫性を破るために、fileid nolock アルゴリズムを 使用する必要がある。指定するパスは、共有ディレクトリからの相対パスでも、 絶対パスでもよい。名前は大文字小文字を区別する unix パス名である! すべてのパスは、共有が接続されている tree connect 時に評価され、 そこから関連するデバイスと、stat() syscallからの i ノード番号だけが 比較されることとに注意。 注意: これは SMB 文法を壊すため、注意して使う必要がある! しかし、特定の (一般的には読み取り専用の) i ノードが強く競合するような 状況では役に立つ。
この古いオプションは、デバイス id を無視しながら設定された
i ノードに対して fileid nolock の動作の使用をトリガする。
これは、意図的に、クラスタ内での対応するファイル又はディレクトリの
ロック一貫性を破るために使用できる。
nfileid:nolock_paths
オプションを使う方が、
より自由度が高く、柔軟で簡単に使用できる。
fsid
アルゴリズムを使って
fileid
モジュールを使う場合の例
[global]
vfs objects = fileid
fileid:algorithm = fsid
競合の激しい (おそらくは読み取り専用の) i ノードへの負荷を避けるために、
fileid
モジュールを使用する。
[global]
vfs objects = fileid
fileid:algorithm = next_module
fileid:nolock_paths = . ContendedFolder1 /path/to/contended.exe
fileid:nolock_max_slots = 256