トップページunix
982コメント306KB

【NFS】Network File System

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2006/03/28(火) 11:42:41
nfsに関する話題を扱うスレ
0068名無しさん@お腹いっぱい。2006/11/18(土) 06:04:12
電子メールによる比喩はちがう気がする
遠隔地でも出来るできないで言えば出来る
実使用上のいろいろな問題があるだろうけど
0069名無しさん@お腹いっぱい。2006/11/18(土) 09:12:09
素の TCPでの接続か、RPCでポート番号が一定しない接続かの違いがあるだけで
IPレベルでは同じ事。NFSはポート番号が変わるため、ファイアーウォールで
NFSだけをうまく許可する方法が難しいという点は確かに違うが、、
0070名無しさん@お腹いっぱい。2006/11/18(土) 09:17:21
いやほら電子メールならUUCPとかでも送れたりするじゃん?
0071名無しさん@お腹いっぱい。2006/11/18(土) 09:27:39
そういうことか。じゃあ FTPでたとえた方がいいのかな。
0072名無しさん@お腹いっぱい。2006/11/18(土) 10:19:58
RPCだって、本来はTCP/IP以外のプロトコルスタック上にも実装できるように
設計されたものなんだが、、実際はTCP/IP版以外は使われていないけど、、
0073名無しさん@お腹いっぱい。2006/11/19(日) 23:19:20
>>67
めちゃくちゃ遅いじゃん。TCPパケットヘッダ送るだけで
2秒以上掛かるのか。
0074名無しさん@お腹いっぱい。2006/11/21(火) 14:43:05
NFSのベンチ結果やlinux iSCSI Targetとの比較結果をまとめているサイトってありませんか?

NFS v4 VS iSCSI

でどっちが早いのか・・・
0075名無しさん@お腹いっぱい。2006/11/21(火) 22:03:41
比較にならないものを比較しようとしてませんか?
私の勘違いでしょうか
0076名無しさん@お腹いっぱい。2006/11/21(火) 22:17:01
AoEの圧勝
0077名無しさん@お腹いっぱい。2006/11/21(火) 23:07:52
AppleShare over Ethernet?
0078名無しさん@お腹いっぱい。2006/11/21(火) 23:33:46
Age of ...
0079742006/11/21(火) 23:42:49
>75
難しいかな・・・

XENでNFSで共有するか
OCFS+iSCSIで共有するかでどっちが良いか検討したかったのですけど

>76

文字足らずなのに理解して頂けたようで感謝です。
ATA-over-Ethernet
も検証候補に入れておきます。


0080名無しさん@お腹いっぱい。2006/11/21(火) 23:46:39
AoEデバイスって国内でどっか買えるの?
0081名無しさん@お腹いっぱい。2006/11/22(水) 00:47:30
>80

金物屋で売ってたよ
0082名無しさん@お腹いっぱい。2006/11/22(水) 00:59:43
「金物屋 AoE」でググった。

鉱床からの金貨収集速度が20%上昇した
0083名無しさん@お腹いっぱい。2006/11/22(水) 21:48:00
「金物屋 AoE」でググった。

「オスマン金物屋使った後、スペイン・オスマン金物屋は使用できない」
0084名無しさん@お腹いっぱい。2006/11/22(水) 22:51:59
誰も売ってないという事は俺がCoraidを輸入して売れば儲かるという事ではないだろうか
0085名無しさん@お腹いっぱい。2006/11/23(木) 14:16:32
>84
ttp://www.coraid.com/products.html
これはいいSupermicroですね。
0086名無しさん@お腹いっぱい。2006/11/23(木) 15:14:20
スーパーマイクロと聞くとSONY NEWSのことが真っ先に頭がよぎるのは私だけ?
0087名無しさん@お腹いっぱい。2006/11/23(木) 18:21:32
社員乙
0088名無しさん@お腹いっぱい。2006/11/29(水) 17:12:39
>>84
黒字になる前に、他の業者が販売し始めて、赤字決済。
いや、是非やってくれ。
0089名無しさん@お腹いっぱい。2006/12/06(水) 14:56:58
>>58 RedHat だけど、GFS なんてどうなんだろうね。興味はあるけど暇がねぇ。
0090名無しさん@お腹いっぱい。2006/12/10(日) 15:05:28
共有ファイルシステム古今東西、

Oracle Cluster File System (OCFS)
Google File Systems (Google GFS)
Redhat Global File System (Redhat GFS)
富士通 PRIMECLUSTER GFS (富士通 GFS)
NEC GSTORAGEFS (NEC GFS)
General Parallel File System (IBM GPFS)
SGI Infinite Storage CXFS (SGI CXFS)
VERITAS Cluster File System (VERITAS CFS)

ほかにある?

そういえば、NFSに馴染み深いはずのWAFSは最近どうなった?
0091名無しさん@お腹いっぱい。2006/12/10(日) 15:26:40
[AからZ]FSの全部が揃ってるという話は聞いたことあるよ。
しかも1990年代の時点で。
リストもらっておけばよかったなあ。
0092912006/12/10(日) 15:29:04
>>90は実用のものを挙げてあるけど、
>>91の[A-Z]の話は、特定の組織でしか使われないとか
論文になったことがある程度のものだったかも。
0093名無しさん@お腹いっぱい。2006/12/10(日) 16:40:49
pvfs2 とか 9fs とか
0094名無しさん@お腹いっぱい。2006/12/10(日) 18:36:42
afsとかwebfsとか
0095名無しさん@お腹いっぱい。2006/12/27(水) 18:36:41
SFUを使ってNSFをWindowsにマウントしようと思うのですが、何か潜在的な問題はありますか?
0096名無しさん@お腹いっぱい。2006/12/27(水) 23:10:03
National Science Foundation
0097名無しさん@お腹いっぱい。2007/01/16(火) 20:01:18
板違いなのかもしれんが他に見当たらないので>>95に便乗。
SFU3.5でSolaris上のNFSをマウントしているのですが、
DOSコマンドのmkdirで存在しない中間ディレクトリの作成をするとこけてしまいます。
これってクライアント側の問題ですか?
0098名無しさん@お腹いっぱい。2007/03/07(水) 11:19:31
>>97
こけかたを具体的に。
0099名無しさん@お腹いっぱい。2007/03/07(水) 13:33:44
>>97
権限周りを調べるべし
0100名無しさんお腹いっぱい2007/03/08(木) 05:34:05
DOSのmkdirはしらないが、solarisならmkdirに -p オプションが必要
0101名無しさん@お腹いっぱい。2007/04/08(日) 13:46:29
超早いNFSサーバ専用機を余らせており、
これをWindowsから使いたいと考えています。
NFSサーバはNFSv2/v3/v4を扱えますが、
とりあえずNFSv2は使わない方向で考えています。

ユーザ認証用にAcitiveDirectoryを用意してあるので、
SFUを用いてNISにマッピングすることに問題はありません。

Windows側はDHCPでIPアドレスを割り当てていますが
同じサブネット内に他の部署も混じっているため、
IPアドレスベースでのアクセス制御は実質役に立ちません。

特定のWindowsユーザだけにNFSサーバを使わせたいのですが、
うまい方法は無いでしょうか?
0102名無しさん@お腹いっぱい。2007/04/08(日) 14:00:41
他の人が使ったら即刻解雇!
っていう社則を作ればOK
0103名無しさん@お腹いっぱい。2007/04/08(日) 17:12:23
>Windows側はDHCPでIPアドレスを割り当てていますが
>同じサブネット内に他の部署も混じっているため、
>IPアドレスベースでのアクセス制御は実質役に立ちません。

MACアドレスとIPアドレスの1対1のリストを作ってIPアドレスを配布するか
MACアドレスグループに範囲内のIPアドレスを割り当てる設定にするような感じで
DHCPサーバを弄れば良い
0104名無しさん@お腹いっぱい。2007/04/08(日) 18:14:48
>>103
その手法は確実そうなのですが
DHCPサーバは全く違う部署で管理している上、
在籍者全員に割り当てられるだけのアドレス空間の余裕がありません。
(離席者のIPアドレスを回収するためにリース期間を非常に短くしてある)

SFU使ってNFS/CIFSゲートウェイを立てるしかないんでしょうか...
性能ががた落ちするのは明らかなので、
何か別に巧い方法があればとは思うのですが。
0105名無しさん@お腹いっぱい。2007/04/08(日) 18:25:39
多分IPアドレスに余裕無いだろうなぁと思って2番目のを提案したのですが
DHCPサーバの管理が別部門という条件も出てきた以上、仕方ないですね
性能には目をつぶってそうするしかないでしょう
0106101=1042007/04/08(日) 18:59:54
>>105
レスどうもです。
ゲートウェイに使えそうな機材余ってたかな...

CIFSのライセンスキーを購入すれば
こんな妙な事をしなくても済むのですが
3桁万円するので予算が(略
01071062007/04/19(木) 10:24:22
セットアップしようとした矢先、
NFS鯖は他の事業所にドナドナされる事になりました。
少なくとも1.5TBは有ったのに orz

NFS/CIFSゲートウェイの件は機会があれば試してみようと思います。
0108名無しさん@お腹いっぱい。2007/04/21(土) 05:59:15
1.5Tなんて、もうディスクが3台あれば冗長構成で組めるぜ。
たいした容量じゃない
0109名無しさん@お腹いっぱい。2007/07/02(月) 17:15:30
それにクライアントは何台ぶらさがれるのか、という問題があるけど。
01101072007/07/04(水) 10:05:17
使おうとしてたのはNetAppだった。
HDD4台程度のなんちゃってNASとは
比較にならないよ。
速度もだけど、容量単価も別世界w

FC接続の144GB HDDが21台搭載してあった。
冗長性に余裕持たせたり、
システム領域やsnapshot領域の関係で
物理容量の約半分がユーザ容量になる。
なので1.5GBが使える、と。
0111名無しさん@お腹いっぱい。2007/07/04(水) 10:07:49
1.5GB
たいへんですね。業者にもってかれましたか?
0112名無しさん@お腹いっぱい。2007/07/12(木) 00:51:22
昔のNetAppはそれくらいだったような
01131102007/07/15(日) 00:30:53
ああ
単位間違えてたのか
1.5TBね orz
0114NFSできない!2007/08/12(日) 19:08:55
FreeBSDでNFSを実装しようとしているのですが、client credential too weakエラーが出力されうまくいきません。
識者の方、どうぞご教示くださいませ。

設定した項目としては下記の様な感じです。

[/etc/exports]
/test -maproot=nobody -network 192.168.1.1

として

# showmount -e
Exports list on localhost:
/test 192.168.1.1

[/etc/rc.conf]
rpcbind_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
#nfs_reserved_port_only="YES"
mountd_enable="YES"
mountd_flags="-r"rpcbind_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
#nfs_reserved_port_only="YES"
mountd_enable="YES"
mountd_flags="-r"

[/etc/hosts.allow]
all : 192.168.1.1 : allow


サーバー側の設定は以上で、その後リブートを実施いたしました。
0115名無しさん@お腹いっぱい。2007/08/12(日) 19:11:03
FreeBSDでNFSがマトモに動いたのは4.xまで。それ以降は本気で使ってはいけない。
0116NFSできない!2007/08/12(日) 19:13:56

次にクライアント側で

[/etc/rc.conf]
nfs_client_enable="YES"

とした後に

rpcinfo -p 192.168.1.1
program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100000 4 local 111 rpcbind
100000 3 local 111 rpcbind
100000 2 local 111 rpcbind
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100005 1 udp 838 mountd
100005 3 udp 838 mountd
100005 1 tcp 741 mountd
100005 3 tcp 741 mountd

で確認をとり念の為クライアント側もリブートを行いました。
0117NFSできない!2007/08/12(日) 19:14:30
その後、rootにて下記コマンドを入力すると

# mount_nfs nfs_server:/test /test
[udp] 59.106.93.70:/test: RPCPROG_MNT: RPC: Authentication error; why = Client credential too weak

となり、文献を調べてみてもクライアント側からrootで上記コマンドを実施していれば問題なさそうなのです。

サーバー側の/var/log/messagesには

Aug 12 19:10:46 ns5 mountd[754]: mount request from 192.168.1.1 from unprivileged port

となります。

ちなみに-Pオプションとかをつけてみても状況変わらずです。

2chのNFS識者の方、是非たすけてください。
0118NFSできない!2007/08/12(日) 19:19:15
>>115

めちゃくちゃ早いレスありがとうございます!

そんな事情があったんですか。うちのサーバー5.4なんで無理っていう事ですかね。。
0119名無しさん@お腹いっぱい。2007/08/12(日) 19:21:27
とりあえず、
mountd_flags="-n"
してみろ。
0120NFSできない!2007/08/12(日) 19:22:43
やってみます!
0121NFSできない!2007/08/12(日) 19:28:03
きたーーーーーーーーーーーーーーーーーーーーーー!
すげーーーーーーーーーーーーーーーーーーーー1

ありがとぅううう
0122名無しさん@お腹いっぱい。2007/08/13(月) 12:33:45
>FreeBSDでNFSを実装しようとしているのですが

すげー
コード書き直してくれてるの?
超期待
0123名無しさん@お腹いっぱい。2007/09/21(金) 12:08:45
>>115
これ本当?
もう6.2Rくらいまで行ってるんだけど未だに改善されてないの?
0124名無しさん@お腹いっぱい。2007/09/21(金) 12:37:43
本当
0125名無しさん@お腹いっぱい。2007/09/21(金) 14:44:28
今NFSv4が一番安定して使えるOSって何?
0126名無しさん@お腹いっぱい。2007/09/21(金) 14:55:04
Windows
0127名無しさん@お腹いっぱい。2007/09/21(金) 15:08:15
>>124-126
この流れを見るととても信用できないなあ
誰も検証してないんだろうか
0128名無しさん@お腹いっぱい。2007/09/21(金) 15:20:12
>>127
せっかく回答もらって「信用できない」かよ。
FreeBSD 6.2で NFS鯖運用してみろよ。ドツボにハマルから。
ひとごとだから別に止めないよ。
0129名無しさん@お腹いっぱい。2007/09/21(金) 15:32:37
>>125
Data ONTAPの7.x系
0130名無しさん@お腹いっぱい。2007/09/21(金) 15:44:27
NFSの話は FreeBSDにおいては禁句です。
多くの開発者が NFSと聞いただけで気分を害します。
分別ある大人なら、FreeBSDコミュニティにおいては
NFSの話はそれとなく避けるのがマナーと言うべきものでしょう。
0131名無しさん@お腹いっぱい。2007/09/21(金) 15:53:44
便所の落書き
0132名無しさん@お腹いっぱい。2007/09/21(金) 16:59:31
本家のMLにはNFSがダメダメという投稿がない上に開発者用の
クラスタなど内部で利用されまくってたりする。
ここではNFSダメダメという書き込みがあるけど不具合の詳細
が全然ない。
0133名無しさん@お腹いっぱい。2007/09/21(金) 17:01:29
たかが2chの書き込みにそこまでの信憑性求めんなよ。
自分で検証すれ。
0134名無しさん@お腹いっぱい。2007/09/21(金) 17:07:50
>>132
FreeBSD同士のNFSだと問題が発覚しにくいんだよ。
異OS間のNFSでとたんに問題発覚する。
手元で試してみろよ。百聞は一見にしかず。
0135名無しさん@お腹いっぱい。2007/09/21(金) 17:12:55
まるでLinuxみたいなことを言うなあ
0136名無しさん@お腹いっぱい。2007/09/21(金) 17:22:22
>>132
>ここではNFSダメダメという書き込みがあるけど不具合の詳細
>が全然ない。

他スレに不具合の詳細あったよ。探して見れ。
0137名無しさん@お腹いっぱい。2007/09/21(金) 17:31:23
>>134
FUDに必死だな
0138名無しさん@お腹いっぱい。2007/09/21(金) 21:10:14
FreeBSD 6.2のNFS鯖から、非FreeBSDのNFSクライアントにマウントし、
マウントされたファイルシステム内で(アプリケーションが)lockfしようとすると
ロックが壊れる。(再現率100%)

6.1以前では、ロックが壊れるのではなく、NFS自体が刺さっていた。
6.2ではNFSは刺さらず、ロックを壊してアプリケーションは続行動作するので、
それを見て「6.2以降ではNFSの問題が直った」と勘違いしている人がいるようだが、
実は問題は直っていない。

(もちろん、必要なlockd statd rpcbindは鯖/クライアント両側で起動してる)
0139名無しさん@お腹いっぱい。2007/09/27(木) 22:42:48
質問。
nohideなんてオプションがあるのはLinux(IRIX由来とmanに書いてあったか)だけ?
最近Solaris使い始めて使えるオプションが意外と少ないことに気付いた
0140名無しさん@お腹いっぱい。2007/09/29(土) 00:40:41
>>138
> マウントされたファイルシステム内で(アプリケーションが)lockfしようとすると

system call として advisory lock しか持っていない OS にそれを求められても...

つか, 今時, lockf とか flock なんて野蛮な排他制御を使ってんのかよ?
0141名無しさん@お腹いっぱい。2007/10/18(木) 18:52:12
NFS mountしたファイルシステムでlockfするアプリケーションを動かすのは、運用が間違っとるよ。
FreeBSDに限らず、Solaris等含めて。
0142名無しさん@お腹いっぱい。2007/10/18(木) 21:56:38
>>141
SolarisではNFS上のlockfは全く平気。
すべてのファイルシステムがNFSであるディスクレスクライアントを実現するため、
lockfを含め、NFSもローカルディスクも全く同じように扱えるというのが
大前提としてあるわけだ。
0143名無しさん@お腹いっぱい。2007/10/19(金) 10:59:03
lockfの話は抜きにしても、

2つのNFSクライアントから同時に mkdir(2)またはsymlink(2)した時、
両方のクライアントが成功(戻り値=0)になってしまう事はないのかな?
0144名無しさん@お腹いっぱい。2007/10/21(日) 20:06:01
そういう等羃でない操作はやらないのがNFSのココロ。
0145名無しさん@お腹いっぱい。2007/10/22(月) 13:17:18
NFS上のmkdirやsymlinkが排他的に実行できることは、SolarisやLinuxでは保証されてる。
FreeBSDではコケるのかも知れんが。
0146名無しさん@お腹いっぱい。2007/10/22(月) 15:37:09
一方的に信頼するのは自由だが、OSとプロトコルの方は「保証」などしとらんと思うがな。

RFC1813(RFC3530でもいいが)のCREATEの所を読んでみてくれ。
0147名無しさん@お腹いっぱい。2007/10/22(月) 18:01:54
複数のホストがからむ話だから、誰が誰に対してどういうレベルで保証しているのかを
明確にしないと議論できないな。
0148名無しさん@お腹いっぱい。2007/10/23(火) 11:01:42
symlinkとかアホくさいことしなくても、
シングルホストなら/varか/tmp以下でlockfすりゃいいじゃん。
マルチホストなら排他制御プロセスいっこ用意すれ。
0149名無しさん@お腹いっぱい。2007/10/23(火) 11:35:04
>>148
lockfが使えるならそれで良い。

>>141 が、NFSでlockfするのは運用が間違ってると言ってるから、
その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?

で、シングルホストの話なんか最初から誰もしてない。
マルチホストだからこそ問題になる点の議論。
0150名無しさん@お腹いっぱい。2007/10/25(木) 10:50:37
NFSを想定したコードばかりとは限らない状況で
NFSを使うことになる、なんて話もあるだろう。
そういうときにハマるかハマらないかの差は大きいと思うんだよなあ。
0151名無しさん@お腹いっぱい。2007/10/29(月) 00:31:04
結局なにをどう実験すればいいんだろう。
(1)Solaris10
(2)FreeBSD 6.2(RELENG_6)
(3)NetBSD 3.1
(4)Linux(リリースが新しいもののうちどれか)

これらを混ぜたLANを作り順番にNFSサーバ役をやらせて、
いくつかのロック方法(lockf, flock, fcntl, あと他に何が?)を
使うCのコードを走らせて経過を観察する、でいいのかな?

誰かコード書いてくれないかな。
0152名無しさん@お腹いっぱい。2007/10/29(月) 07:40:49
>>151
flockはもともと単一ホストでしか使えないのでここでは関係なし。
fcntlの(F_SETLKWなど)は、lockfと同じ(というか、lockfがfcntlを呼び出してる)
ので、lockfのみテストすれば桶。

ほか、lockfを使わずに mkdirや symlink や link がロックとして機能するかどうかの
テストができればいいかな。
0153名無しさん@お腹いっぱい。2007/10/29(月) 10:41:18
>lockfがfcntlを呼び出してる
それは実装によって違うだろ
0154名無しさん@お腹いっぱい。2007/10/29(月) 13:52:29
>>152
- 誰かがロック中にサーバが落ちた後のリカバリがまともかどうか
- ロックを獲得したままのクライアントが落ちた後のリカバリがまともかどうか
も必要じゃない?
実装が難しくなるのもそのあたりを考えなきゃいけないからだろうし。
0155名無しさん@お腹いっぱい。2007/10/29(月) 15:02:09
>>154
それはどういう振る舞いをもって「まとも」と見なせばいいんでしょうか。
前者はサーバの落ち具合一つとっても、単なる回線障害なのか、
サーバ側のファイルシステムに絡む問題なのかで話が変わるだろうし。
後者はロックのタイムアウト処理が適切?か、とかですか?
0156名無しさん@お腹いっぱい。2007/10/29(月) 15:33:42
>>149
> その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?

symlinkだのmkdirだのは排他制御の方法としてlockf以上に「お話にならない」。
書類審査で落とされる。
0157名無しさん@お腹いっぱい。2007/10/29(月) 15:42:43
>>156
でも、(少なくとも)Solarisだと、symlinkもmkdirもしっかりロックとして
機能するんだよ。
0158名無しさん@お腹いっぱい。2007/10/29(月) 15:56:52
FreeBSDはlockfがダメだからNFSが使いものにならない

NFSでlockfなんか使うのは運用が間違ってる(mkdirやsymlinkを使えば良い)(>>by 141)

symlinkだのmkdirだのはお話にならない(by >>156)

FreeBSDではNFSは使えない。


結局こういうことになるじゃんw
0159名無しさん@お腹いっぱい。2007/10/29(月) 16:02:26
symlinkとかではお話にならないとか言ってる奴は……お話にならないな。
メール関係のデーモンやツールをソースからコンパイルする時に
気づくことすら知らないわけで……
0160名無しさん@お腹いっぱい。2007/10/29(月) 20:47:12
とりあえずポリシーとか仕様とか一切とっぱらいで、
ロックとして使えるもの、使われがちなもの、に対して、
各OSをサーバ、クライアントにしたときの動作相性表を書いてみろ、
ってことか? 横方向クライアントOS、縦方向サーバOSにして、
lockf, flock, fcntl, symlink, mkdir
で表が5枚出来る、と。
0161名無しさん@お腹いっぱい。2007/10/30(火) 00:22:59
nfsv4だったらいいんじゃない。
0162名無しさん@お腹いっぱい。2007/10/30(火) 01:21:29
>>161
http://pc11.2ch.net/test/read.cgi/unix/1012808941/643-652n
0163名無しさん@お腹いっぱい。2007/10/30(火) 01:38:08
あるじゃんNFSv4
snowhite.cis.uoguelph.ca/nfsv4/
0164名無しさん@お腹いっぱい。2007/10/30(火) 12:39:49
サーバNetApp, クライアントTurboLinux Fujiという環境で
たまに下記のように .nfs〜 で始まるファイルが出来ている
事あるのだけど、これはどういうタイミングで出来るのでしょうか?

また、消してかまわないのでしょうか??

-rw-r--r-- 1 hogehoge admin 2253 10月 10 15:36 .nfs002d56600000001
0165名無しさん@お腹いっぱい。2007/10/30(火) 13:09:57
>>157
仕様上正しく動くことが保証されていないと、1億年と2000年前から動かしたときには
コケることになる。これは排他制御とはいえない。
NFS protocolのsymlinkは保証なんかしていない。

fcntlが使うlockd protocolは保証してるけど、こちらは伝統的にbuggyな実装が多かった。

>>158
なんでNFSで出来ない排他制御をやりたがるのか。問題に応じて解決法はいろいろある。
そもそも遅延とパケットロスのあるTCP/IP越しに排他制御やろうってのが性根が
腐ってるわけで、性能が問題にならないなら1台にまとめればいいし、
性能が重要ならcriticalな処理だけ切り出して1台にまとめ、残りを分散すればよい。

>>159
逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
前提に、それでも衝突することがないように(排他できなくてもよいように)
工夫して書かれている。
0166名無しさん@お腹いっぱい。2007/10/30(火) 13:16:18
>>164
UNIXでは、プロセスが開いているファイルでも削除できる。
そのとき、ファイルはすでに削除され見えないのだが、
オープンしたプロセスだけはファイルにアクセスし続けられる。

同じことはNFS上でもできるのだが、NFSでは見えなくするわけにはいかないので、
.nfsXXXX にリネームしてお茶を濁している。
これはプロセスがファイルをクローズしたときに削除される。

クライアントが削除を怠ると(=クライアントのOSが落ちると)
.nfsはストレージ上に残されたまま放置される。
0167名無しさん@お腹いっぱい。2007/10/30(火) 13:51:42
>>165 なんでNFSで出来ない排他制御をやりたがるのか。
だってNFSと銘打ってるのにそれが出来てる(ように見える)OSがあるんだもんよー。
FreeBSDで出来ないのは悔しくね? という話だと思っていた。
■ このスレッドは過去ログ倉庫に格納されています