NFS fcntl(F_SETLK) problem (Linux->MacOSX)
Yasushi Shinjo
NFS のロックの問題が出ています。クライアントは、Linux
(RedHat, 2.6.9-42.0.2.ELsmp), サーバは、MacOSX 10.4 Server
です。うちの若い者が調べた所、クライアントで fcntl() システ
ムコールの F_SETLK で問題が発生するとのことでした。flock()
システムコールでは発生しません。
この辺り、何か情報はないでしょうか。flock() では問題ないとい
うことから、直感的に怪しいのは、Linux の lockd なんだけれど。
NFS は、v2 でも v3 でも同じように問題が発生します。
lockd の問題だとすると、昔ながらの問題で、なかなか技術が進ま
ないなあという気がします。分散アルゴリズムで難しい所ではある
んだけれど、先人がバグった所で、後の人も同じようにバグるかっ
て言いたい。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
OGAWA KenIchi
記事<YAS.06Se...@kirk.is.tsukuba.ac.jp>から引用します：
> NFS のロックの問題が出ています。クライアントは、Linux
> (RedHat, 2.6.9-42.0.2.ELsmp), サーバは、MacOSX 10.4 Server
> です。うちの若い者が調べた所、クライアントで fcntl() システ
> ムコールの F_SETLK で問題が発生するとのことでした。flock()
> システムコールでは発生しません。
「問題」というのはどういう問題なのでしょうか？
> この辺り、何か情報はないでしょうか。
fcntlではなくflockの挙動なのですが、
Linux NFS faq の D10
http://nfs.sourceforge.net/#faq_d10
に、
flock()/BSD locks act only locally on Linux NFS clients prior to
2.6.12.
とあるので、Linuxのカーネル2.6.9だとflockはネットワーク越しではロック
できないのではないかなと思います。
--
小川建一 mailto:ken...@ice.email.ne.jp
++
Yasushi Shinjo
In article <450a4ff3$0$977$44c9...@news2.asahi-net.or.jp>
OGAWA KenIchi <ken...@ice.email.ne.jp> writes:
> 小川と申します。
> 「問題」というのはどういう問題なのでしょうか？
ロックの問題ですが、具体的な症状としては、ファイルをロックし
ようとすると固まってしまうということです。クライアントは、
Linux、サーバは、MacOSX です。
> fcntlではなくflockの挙動なのですが、
> Linux NFS faq の D10
> http://nfs.sourceforge.net/#faq_d10
> flock()/BSD locks act only locally on Linux NFS clients prior to
> 2.6.12.
> とあるので、Linuxのカーネル2.6.9だとflockはネットワーク越しではロック
> できないのではないかなと思います。
情報ありがとうございます。flock() は固まらないだけで、ロック
としては働いていないということかもしれませんね。
fcntl(F_SETLK) に問題があるからといってねflock() で代替する
というのは、危ないですね。
こちらは、RedHat なので、2.6.9 といいつつ、独自にパッチを当
てている場合はあるのですけれど。３月ごろあった Linux NFSv3
クライアントの find の問題は解消しているみたい。３月ごろは、
NFSv3 で find がまともに動かなくて、しょうがなくて NFSv2 で
凌いでいました。
Takashi SHIRAI
昔は「NFS では lock が効かない」は常識だったので隔世の感が。
In article <YAS.06Se...@kirk.is.tsukuba.ac.jp>,
Yasushi Shinjo <y...@is.tsukuba.ac.jp> wrote:
>新城＠筑波大学情報です。こんにちは。
>ロックの問題ですが、具体的な症状としては、ファイルをロックし
>ようとすると固まってしまうということです。クライアントは、
>Linux、サーバは、MacOSX です。
Linux の NFS は実装が不完全なことで有名ですが、特に lockd
は上手く働かないことが多いようです。
相手が同じ Linux kernel で同じ architecture だと割と安定し
てますが、それでも失敗する時には失敗するので、こと Linux に
関しては昔の fcntl() の常識を適用すべきかと。
因みに、経験則から言うと、deadlock する時には「client 数が
多過ぎ」とか何とか吐いてた気がするので、unlock されるのを待
っている client が多いと何かまずいのかも。
>情報ありがとうございます。flock() は固まらないだけで、ロック
>としては働いていないということかもしれませんね。
>fcntl(F_SETLK) に問題があるからといってねflock() で代替する
>というのは、危ないですね。
glibc を使う限りは lockf() も fcntl() を使って lock 機構を
実装しているように見えるので、lockf() に逃げるという解もあり
ません。
flock() に関しては、Linux kernel 2.x 以降では独立の system
call なので、man page のとおり「NFS で使えない別の lock 機構」
ですが、kernel 1.x だと fcntl() を使うので同じ機構ですね。
--
しらい たかし
Yasushi Shinjo
In article <1jvPg.1691$FL1...@news-virt.s-kddi1.home.ne.jp>
shi...@unixusers.net (Takashi SHIRAI) writes:
> Linux の NFS は実装が不完全なことで有名ですが、特に lockd
> は上手く働かないことが多いようです。
> 相手が同じ Linux kernel で同じ architecture だと割と安定し
> てますが、それでも失敗する時には失敗するので、こと Linux に
> 関しては昔の fcntl() の常識を適用すべきかと。
自分でプログラムを書くということなら、そうなのでしょう。今は、
他人が書いたプログラムが動かないという話なので。具体的に、
今困っているのは、User Mode Linux です。他にもあるのでしょう。
> glibc を使う限りは lockf() も fcntl() を使って lock 機構を
> 実装しているように見えるので、lockf() に逃げるという解もあり
> ません。
今は、fcntl() が固まるということなので、lockf() でも固まるか
もしれません。