06/10/25 17:57:32
Yes
51:名無しさん＠お腹いっぱい。
06/10/28 00:34:22
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
でも？
52:名無しさん＠お腹いっぱい。
06/10/28 11:33:21
>>51
FreeBSD の rpc.lockdは動作がおかしい。
FreeBSD自身の lockf()は、flock()として動作してるｗ
よって、全然駄目駄目。
試しに、複数のFreeBSDクライアントから lock書ける実験をしてみるといい。
lock無視してファイル壊すから。
53:名無しさん＠お腹いっぱい。
06/10/28 12:32:21
今年の5月か6月あたりに直ったんじゃなかったっけ。
54:名無しさん＠お腹いっぱい。
06/10/28 13:18:50
>>53
rpc.lockdの件はともかく、
flock/lockfの件も直ったの?
直ったかどうかというより、これってFreeBSDの仕様の問題だから、
今までflockの動作をしていたのを急にlockfの動作にすると
別の部分で不具合が出るから、直しようがないと思うんだが、、
55:名無しさん＠お腹いっぱい。
06/11/10 14:32:56
>>54
いつの時代の話？
lockf(3) は内部で fcntl(2) を呼ぶようになっていますが。flock(2) ではなく。
56:名無しさん＠お腹いっぱい。
06/11/12 15:53:18
NFS over SSHのやり方を教えてください。
57:名無しさん＠お腹いっぱい。
06/11/12 16:49:44
URLﾘﾝｸ(www.google.com)
58:名無しさん＠お腹いっぱい。
06/11/12 22:45:01
結局ステートレスじゃないNFSに替わるネットワークを透過的に使えるファイルシステムなんてものは無いということなのか？
59:名無しさん＠お腹いっぱい。
06/11/12 22:58:16
つ SMB
60:名無しさん＠お腹いっぱい。
06/11/13 09:37:56
mjsk
61:名無しさん＠お腹いっぱい。
06/11/17 15:36:58
NFSv4の立場は・・・・・・
62:名無しさん＠お腹いっぱい。
06/11/17 16:18:12
FreeBSDの NFSv4対応はいつになりますか? Linuxでさえ対応してるのに、、
63:名無しさん＠お腹いっぱい。
06/11/17 19:02:55
NFSって遠隔地、例えば東京大阪間のようなものでもグローバルIPさえあればつなぐことができるのでしょうか？
64:名無しさん＠お腹いっぱい。
06/11/17 19:05:16
電子メールって遠隔地、例えば東京大阪間のようなものでもグローバルIPさえあれば送ることができるのでしょうか？
と聞いてるのと同じ。
65:名無しさん＠お腹いっぱい。
06/11/18 01:13:20
同じかなー
66:名無しさん＠お腹いっぱい。
06/11/18 04:22:47
なんか怖いな
67:名無しさん＠お腹いっぱい。
06/11/18 05:58:43
20世紀の頃、某ISPのWebサーバの
ユーザ領域をNFSマウントしちゃえたことあるよ
28.8bpsで
68:名無しさん＠お腹いっぱい。
06/11/18 06:04:12
電子メールによる比喩はちがう気がする
遠隔地でも出来るできないで言えば出来る
実使用上のいろいろな問題があるだろうけど
69:名無しさん＠お腹いっぱい。
06/11/18 09:12:09
素の TCPでの接続か、RPCでポート番号が一定しない接続かの違いがあるだけで
IPレベルでは同じ事。NFSはポート番号が変わるため、ファイアーウォールで
NFSだけをうまく許可する方法が難しいという点は確かに違うが、、
70:名無しさん＠お腹いっぱい。
06/11/18 09:17:21
いやほら電子メールならUUCPとかでも送れたりするじゃん？
71:名無しさん＠お腹いっぱい。
06/11/18 09:27:39
そういうことか。じゃあ FTPでたとえた方がいいのかな。
72:名無しさん＠お腹いっぱい。
06/11/18 10:19:58
RPCだって、本来はTCP/IP以外のプロトコルスタック上にも実装できるように
設計されたものなんだが、、実際はTCP/IP版以外は使われていないけど、、
73:名無しさん＠お腹いっぱい。
06/11/19 23:19:20
>>67
めちゃくちゃ遅いじゃん。TCPパケットヘッダ送るだけで
2秒以上掛かるのか。
74:名無しさん＠お腹いっぱい。
06/11/21 14:43:05
NFSのベンチ結果やlinux iSCSI Targetとの比較結果をまとめているサイトってありませんか？
NFS v4 VS iSCSI
でどっちが早いのか・・・
75:名無しさん＠お腹いっぱい。
06/11/21 22:03:41
比較にならないものを比較しようとしてませんか？
私の勘違いでしょうか
76:名無しさん＠お腹いっぱい。
06/11/21 22:17:01
AoEの圧勝
77:名無しさん＠お腹いっぱい。
06/11/21 23:07:52
AppleShare over Ethernet?
78:名無しさん＠お腹いっぱい。
06/11/21 23:33:46
Age of ...
79:74
06/11/21 23:42:49
>75
難しいかな・・・
XENでNFSで共有するか
OCFS+iSCSIで共有するかでどっちが良いか検討したかったのですけど
>76
文字足らずなのに理解して頂けたようで感謝です。
ATA-over-Ethernet
も検証候補に入れておきます。
80:名無しさん＠お腹いっぱい。
06/11/21 23:46:39
AoEデバイスって国内でどっか買えるの？
81:名無しさん＠お腹いっぱい。
06/11/22 00:47:30
>80
金物屋で売ってたよ
82:名無しさん＠お腹いっぱい。
06/11/22 00:59:43
「金物屋 AoE」でググった。
鉱床からの金貨収集速度が20%上昇した
83:名無しさん＠お腹いっぱい。
06/11/22 21:48:00
「金物屋 AoE」でググった。
「オスマン金物屋使った後、スペイン・オスマン金物屋は使用できない」
84:名無しさん＠お腹いっぱい。
06/11/22 22:51:59
誰も売ってないという事は俺がCoraidを輸入して売れば儲かるという事ではないだろうか
85:名無しさん＠お腹いっぱい。
06/11/23 14:16:32
>84
URLﾘﾝｸ(www.coraid.com)
これはいいSupermicroですね。
86:名無しさん＠お腹いっぱい。
06/11/23 15:14:20
スーパーマイクロと聞くとSONY NEWSのことが真っ先に頭がよぎるのは私だけ？
87:名無しさん＠お腹いっぱい。
06/11/23 18:21:32
社員乙
88:名無しさん＠お腹いっぱい。
06/11/29 17:12:39
>>84
黒字になる前に、他の業者が販売し始めて、赤字決済。
いや、是非やってくれ。
89:名無しさん＠お腹いっぱい。
06/12/06 14:56:58
>>58 RedHat だけど、GFS なんてどうなんだろうね。興味はあるけど暇がねぇ。
90:名無しさん＠お腹いっぱい。
06/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は最近どうなった？
91:名無しさん＠お腹いっぱい。
06/12/10 15:26:40
[AからZ]FSの全部が揃ってるという話は聞いたことあるよ。
しかも１９９０年代の時点で。
リストもらっておけばよかったなあ。
92:91
06/12/10 15:29:04
>>90は実用のものを挙げてあるけど、
>>91の[A-Z]の話は、特定の組織でしか使われないとか
論文になったことがある程度のものだったかも。
93:名無しさん＠お腹いっぱい。
06/12/10 16:40:49
pvfs2 とか 9fs とか
94:名無しさん＠お腹いっぱい。
06/12/10 18:36:42
afsとかwebfsとか
95:名無しさん＠お腹いっぱい。
06/12/27 18:36:41
SFUを使ってNSFをWindowsにマウントしようと思うのですが、何か潜在的な問題はありますか？
96:名無しさん＠お腹いっぱい。
06/12/27 23:10:03
National Science Foundation
97:名無しさん＠お腹いっぱい。
07/01/16 20:01:18
板違いなのかもしれんが他に見当たらないので>>95に便乗。
SFU3.5でSolaris上のNFSをマウントしているのですが、
DOSコマンドのmkdirで存在しない中間ディレクトリの作成をするとこけてしまいます。
これってクライアント側の問題ですか？
98:名無しさん＠お腹いっぱい。
07/03/07 11:19:31
>>97
こけかたを具体的に。
99:名無しさん＠お腹いっぱい。
07/03/07 13:33:44
>>97
権限周りを調べるべし
100:名無しさんお腹いっぱい
07/03/08 05:34:05
DOSのmkdirはしらないが、solarisならmkdirに -p オプションが必要
101:名無しさん＠お腹いっぱい。
07/04/08 13:46:29
超早いNFSサーバ専用機を余らせており、
これをWindowsから使いたいと考えています。
NFSサーバはNFSv2/v3/v4を扱えますが、
とりあえずNFSv2は使わない方向で考えています。
ユーザ認証用にAcitiveDirectoryを用意してあるので、
SFUを用いてNISにマッピングすることに問題はありません。
Windows側はDHCPでIPアドレスを割り当てていますが
同じサブネット内に他の部署も混じっているため、
IPアドレスベースでのアクセス制御は実質役に立ちません。
特定のWindowsユーザだけにNFSサーバを使わせたいのですが、
うまい方法は無いでしょうか?
102:名無しさん＠お腹いっぱい。
07/04/08 14:00:41
他の人が使ったら即刻解雇！
っていう社則を作ればＯＫ
103:名無しさん＠お腹いっぱい。
07/04/08 17:12:23
>Windows側はDHCPでIPアドレスを割り当てていますが
>同じサブネット内に他の部署も混じっているため、
>IPアドレスベースでのアクセス制御は実質役に立ちません。
MACアドレスとIPアドレスの1対1のリストを作ってIPアドレスを配布するか
MACアドレスグループに範囲内のIPアドレスを割り当てる設定にするような感じで
DHCPサーバを弄れば良い
104:名無しさん＠お腹いっぱい。
07/04/08 18:14:48
>>103
その手法は確実そうなのですが
DHCPサーバは全く違う部署で管理している上、
在籍者全員に割り当てられるだけのアドレス空間の余裕がありません。
(離席者のIPアドレスを回収するためにリース期間を非常に短くしてある)
SFU使ってNFS/CIFSゲートウェイを立てるしかないんでしょうか...
性能ががた落ちするのは明らかなので、
何か別に巧い方法があればとは思うのですが。
105:名無しさん＠お腹いっぱい。
07/04/08 18:25:39
多分IPアドレスに余裕無いだろうなぁと思って2番目のを提案したのですが
DHCPサーバの管理が別部門という条件も出てきた以上、仕方ないですね
性能には目をつぶってそうするしかないでしょう
106:101=104
07/04/08 18:59:54
>>105
レスどうもです。
ゲートウェイに使えそうな機材余ってたかな...
CIFSのライセンスキーを購入すれば
こんな妙な事をしなくても済むのですが
3桁万円するので予算が(略
107:106
07/04/19 10:24:22
セットアップしようとした矢先、
NFS鯖は他の事業所にドナドナされる事になりました。
少なくとも1.5TBは有ったのに orz
NFS/CIFSゲートウェイの件は機会があれば試してみようと思います。
108:名無しさん＠お腹いっぱい。
07/04/21 05:59:15
1.5Tなんて、もうディスクが3台あれば冗長構成で組めるぜ。
たいした容量じゃない
109:名無しさん＠お腹いっぱい。
07/07/02 17:15:30
それにクライアントは何台ぶらさがれるのか、という問題があるけど。
110:107
07/07/04 10:05:17
使おうとしてたのはNetAppだった。
HDD4台程度のなんちゃってNASとは
比較にならないよ。
速度もだけど、容量単価も別世界w
FC接続の144GB HDDが21台搭載してあった。
冗長性に余裕持たせたり、
システム領域やsnapshot領域の関係で
物理容量の約半分がユーザ容量になる。
なので1.5GBが使える、と。
111:名無しさん＠お腹いっぱい。
07/07/04 10:07:49
1.5GB
たいへんですね。業者にもってかれましたか？
112:名無しさん＠お腹いっぱい。
07/07/12 00:51:22
昔のNetAppはそれくらいだったような
113:110
07/07/15 00:30:53
ああ
単位間違えてたのか
1.5TBね orz
114:NFSできない！
07/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
サーバー側の設定は以上で、その後リブートを実施いたしました。
115:名無しさん＠お腹いっぱい。
07/08/12 19:11:03
FreeBSDでNFSがマトモに動いたのは4.xまで。それ以降は本気で使ってはいけない。
116:NFSできない！
07/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
で確認をとり念の為クライアント側もリブートを行いました。
117:NFSできない！
07/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識者の方、是非たすけてください。
118:NFSできない！
07/08/12 19:19:15
>>115
めちゃくちゃ早いレスありがとうございます！
そんな事情があったんですか。うちのサーバー5.4なんで無理っていう事ですかね。。
119:名無しさん＠お腹いっぱい。
07/08/12 19:21:27
とりあえず、
mountd_flags="-n"
してみろ。
120:NFSできない！
07/08/12 19:22:43
やってみます！
121:NFSできない！
07/08/12 19:28:03
きたーーーーーーーーーーーーーーーーーーーーーー！
すげーーーーーーーーーーーーーーーーーーーー１
ありがとぅううう
122:名無しさん＠お腹いっぱい。
07/08/13 12:33:45
>FreeBSDでNFSを実装しようとしているのですが
すげー
コード書き直してくれてるの？
超期待
123:名無しさん＠お腹いっぱい。
07/09/21 12:08:45
>>115
これ本当？
もう6.2Rくらいまで行ってるんだけど未だに改善されてないの？
124:名無しさん＠お腹いっぱい。
07/09/21 12:37:43
本当
125:名無しさん＠お腹いっぱい。
07/09/21 14:44:28
今NFSv4が一番安定して使えるOSって何？
126:名無しさん＠お腹いっぱい。
07/09/21 14:55:04
Windows
127:名無しさん＠お腹いっぱい。
07/09/21 15:08:15
>>124-126
この流れを見るととても信用できないなあ
誰も検証してないんだろうか
128:名無しさん＠お腹いっぱい。
07/09/21 15:20:12
>>127
せっかく回答もらって「信用できない」かよ。
FreeBSD 6.2で NFS鯖運用してみろよ。ドツボにハマルから。
ひとごとだから別に止めないよ。
129:名無しさん＠お腹いっぱい。
07/09/21 15:32:37
>>125
Data ONTAPの7.x系
130:名無しさん＠お腹いっぱい。
07/09/21 15:44:27
NFSの話は FreeBSDにおいては禁句です。
多くの開発者が NFSと聞いただけで気分を害します。
分別ある大人なら、FreeBSDコミュニティにおいては
NFSの話はそれとなく避けるのがマナーと言うべきものでしょう。
131:名無しさん＠お腹いっぱい。
07/09/21 15:53:44
便所の落書き
132:名無しさん＠お腹いっぱい。
07/09/21 16:59:31
本家のMLにはNFSがダメダメという投稿がない上に開発者用の
クラスタなど内部で利用されまくってたりする。
ここではNFSダメダメという書き込みがあるけど不具合の詳細
が全然ない。
133:名無しさん＠お腹いっぱい。
07/09/21 17:01:29
たかが2chの書き込みにそこまでの信憑性求めんなよ。
自分で検証すれ。
134:名無しさん＠お腹いっぱい。
07/09/21 17:07:50
>>132
FreeBSD同士のNFSだと問題が発覚しにくいんだよ。
異OS間のNFSでとたんに問題発覚する。
手元で試してみろよ。百聞は一見にしかず。
135:名無しさん＠お腹いっぱい。
07/09/21 17:12:55
まるでLinuxみたいなことを言うなあ
136:名無しさん＠お腹いっぱい。
07/09/21 17:22:22
>>132
>ここではNFSダメダメという書き込みがあるけど不具合の詳細
>が全然ない。
他スレに不具合の詳細あったよ。探して見れ。
137:名無しさん＠お腹いっぱい。
07/09/21 17:31:23
>>134
FUDに必死だな
138:名無しさん＠お腹いっぱい。
07/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は鯖/クライアント両側で起動してる)
139:名無しさん＠お腹いっぱい。
07/09/27 22:42:48
質問。
nohideなんてオプションがあるのはLinux(IRIX由来とmanに書いてあったか)だけ？
最近Solaris使い始めて使えるオプションが意外と少ないことに気付いた
140:名無しさん＠お腹いっぱい。
07/09/29 00:40:41
>>138
> マウントされたファイルシステム内で(アプリケーションが)lockfしようとすると
system call として advisory lock しか持っていない OS にそれを求められても...
つか, 今時, lockf とか flock なんて野蛮な排他制御を使ってんのかよ?
141:名無しさん＠お腹いっぱい。
07/10/18 18:52:12
NFS mountしたファイルシステムでlockfするアプリケーションを動かすのは、運用が間違っとるよ。
FreeBSDに限らず、Solaris等含めて。
142:名無しさん＠お腹いっぱい。
07/10/18 21:56:38
>>141
SolarisではNFS上のlockfは全く平気。
すべてのファイルシステムがNFSであるディスクレスクライアントを実現するため、
lockfを含め、NFSもローカルディスクも全く同じように扱えるというのが
大前提としてあるわけだ。
143:名無しさん＠お腹いっぱい。
07/10/19 10:59:03
lockfの話は抜きにしても、
2つのNFSクライアントから同時に mkdir(2)またはsymlink(2)した時、
両方のクライアントが成功(戻り値=0)になってしまう事はないのかな?
144:名無しさん＠お腹いっぱい。
07/10/21 20:06:01
そういう等羃でない操作はやらないのがNFSのココロ。
145:名無しさん＠お腹いっぱい。
07/10/22 13:17:18
NFS上のmkdirやsymlinkが排他的に実行できることは、SolarisやLinuxでは保証されてる。
FreeBSDではコケるのかも知れんが。
146:名無しさん＠お腹いっぱい。
07/10/22 15:37:09
一方的に信頼するのは自由だが、OSとプロトコルの方は「保証」などしとらんと思うがな。
RFC1813(RFC3530でもいいが)のCREATEの所を読んでみてくれ。
147:名無しさん＠お腹いっぱい。
07/10/22 18:01:54
複数のホストがからむ話だから、誰が誰に対してどういうレベルで保証しているのかを
明確にしないと議論できないな。
148:名無しさん＠お腹いっぱい。
07/10/23 11:01:42
symlinkとかアホくさいことしなくても、
シングルホストなら/varか/tmp以下でlockfすりゃいいじゃん。
マルチホストなら排他制御プロセスいっこ用意すれ。
149:名無しさん＠お腹いっぱい。
07/10/23 11:35:04
>>148
lockfが使えるならそれで良い。
>>141 が、NFSでlockfするのは運用が間違ってると言ってるから、
その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?
で、シングルホストの話なんか最初から誰もしてない。
マルチホストだからこそ問題になる点の議論。
150:名無しさん＠お腹いっぱい。
07/10/25 10:50:37
NFSを想定したコードばかりとは限らない状況で
NFSを使うことになる、なんて話もあるだろう。
そういうときにハマるかハマらないかの差は大きいと思うんだよなあ。
151:名無しさん＠お腹いっぱい。
07/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のコードを走らせて経過を観察する、でいいのかな？
誰かコード書いてくれないかな。
152:名無しさん＠お腹いっぱい。
07/10/29 07:40:49
>>151
flockはもともと単一ホストでしか使えないのでここでは関係なし。
fcntlの(F_SETLKWなど)は、lockfと同じ(というか、lockfがfcntlを呼び出してる)
ので、lockfのみテストすれば桶。
ほか、lockfを使わずに mkdirや symlink や link がロックとして機能するかどうかの
テストができればいいかな。
153:名無しさん＠お腹いっぱい。
07/10/29 10:41:18
>lockfがfcntlを呼び出してる
それは実装によって違うだろ
154:名無しさん＠お腹いっぱい。
07/10/29 13:52:29
>>152
- 誰かがロック中にサーバが落ちた後のリカバリがまともかどうか
- ロックを獲得したままのクライアントが落ちた後のリカバリがまともかどうか
も必要じゃない？
実装が難しくなるのもそのあたりを考えなきゃいけないからだろうし。
155:名無しさん＠お腹いっぱい。
07/10/29 15:02:09
>>154
それはどういう振る舞いをもって「まとも」と見なせばいいんでしょうか。
前者はサーバの落ち具合一つとっても、単なる回線障害なのか、
サーバ側のファイルシステムに絡む問題なのかで話が変わるだろうし。
後者はロックのタイムアウト処理が適切？か、とかですか？
156:名無しさん＠お腹いっぱい。
07/10/29 15:33:42
>>149
> その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?
symlinkだのmkdirだのは排他制御の方法としてlockf以上に「お話にならない」。
書類審査で落とされる。
157:名無しさん＠お腹いっぱい。
07/10/29 15:42:43
>>156
でも、(少なくとも)Solarisだと、symlinkもmkdirもしっかりロックとして
機能するんだよ。
158:名無しさん＠お腹いっぱい。
07/10/29 15:56:52
FreeBSDはlockfがダメだからNFSが使いものにならない
↓
NFSでlockfなんか使うのは運用が間違ってる(mkdirやsymlinkを使えば良い)(>>by 141)
↓
symlinkだのmkdirだのはお話にならない(by >>156)
↓
FreeBSDではNFSは使えない。
結局こういうことになるじゃんｗ
159:名無しさん＠お腹いっぱい。
07/10/29 16:02:26
symlinkとかではお話にならないとか言ってる奴は……お話にならないな。
メール関係のデーモンやツールをソースからコンパイルする時に
気づくことすら知らないわけで……
160:名無しさん＠お腹いっぱい。
07/10/29 20:47:12
とりあえずポリシーとか仕様とか一切とっぱらいで、
ロックとして使えるもの、使われがちなもの、に対して、
各OSをサーバ、クライアントにしたときの動作相性表を書いてみろ、
ってことか？ 横方向クライアントOS、縦方向サーバOSにして、
lockf, flock, fcntl, symlink, mkdir
で表が５枚出来る、と。
161:名無しさん＠お腹いっぱい。
07/10/30 00:22:59
nfsv4だったらいいんじゃない。
162:名無しさん＠お腹いっぱい。
07/10/30 01:21:29
>>161
ｽﾚﾘﾝｸ(unix板:643-652番)n
163:名無しさん＠お腹いっぱい。
07/10/30 01:38:08
あるじゃんNFSv4
snowhite.cis.uoguelph.ca/nfsv4/
164:名無しさん＠お腹いっぱい。
07/10/30 12:39:49
サーバNetApp, クライアントTurboLinux Fujiという環境で
たまに下記のように .nfs～ で始まるファイルが出来ている
事あるのだけど、これはどういうタイミングで出来るのでしょうか？
また、消してかまわないのでしょうか？？
-rw-r--r-- 1 hogehoge admin 2253 10月 10 15:36 .nfs002d56600000001
165:名無しさん＠お腹いっぱい。
07/10/30 13:09:57
>>157
仕様上正しく動くことが保証されていないと、1億年と2000年前から動かしたときには
コケることになる。これは排他制御とはいえない。
NFS protocolのsymlinkは保証なんかしていない。
fcntlが使うlockd protocolは保証してるけど、こちらは伝統的にbuggyな実装が多かった。
>>158
なんでNFSで出来ない排他制御をやりたがるのか。問題に応じて解決法はいろいろある。
そもそも遅延とパケットロスのあるTCP/IP越しに排他制御やろうってのが性根が
腐ってるわけで、性能が問題にならないなら1台にまとめればいいし、
性能が重要ならcriticalな処理だけ切り出して1台にまとめ、残りを分散すればよい。
>>159
逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
前提に、それでも衝突することがないように(排他できなくてもよいように)
工夫して書かれている。
166:名無しさん＠お腹いっぱい。
07/10/30 13:16:18
>>164
UNIXでは、プロセスが開いているファイルでも削除できる。
そのとき、ファイルはすでに削除され見えないのだが、
オープンしたプロセスだけはファイルにアクセスし続けられる。
同じことはNFS上でもできるのだが、NFSでは見えなくするわけにはいかないので、
.nfsXXXX にリネームしてお茶を濁している。
これはプロセスがファイルをクローズしたときに削除される。
クライアントが削除を怠ると(=クライアントのOSが落ちると)
.nfsはストレージ上に残されたまま放置される。
167:名無しさん＠お腹いっぱい。
07/10/30 13:51:42
>>165 なんでNFSで出来ない排他制御をやりたがるのか。
だってNFSと銘打ってるのにそれが出来てる(ように見える)OSがあるんだもんよー。
FreeBSDで出来ないのは悔しくね？ という話だと思っていた。
168:164
07/10/30 19:31:59
>>166
ありがとうございました。
169:名無しさん＠お腹いっぱい。
07/10/31 02:24:25
出来ているように見えるだけで
本当に出来ているのかは定かではないｗ
170:名無しさん＠お腹いっぱい。
07/10/31 12:47:49
>>165
>逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
>前提に、それでも衝突することがないように(排他できなくてもよいように)
>工夫して書かれている。
えー。
嘘書いちゃ、だめだよ。
171:170
07/10/31 12:53:50
ああ、プロトコル上だけで実現できるかどうかの話をしてるのか。
symlinkはロック機構じゃないんだから、symlinkの使い方を工夫しないで
実現できないのは当然じゃん。
172:名無しさん＠お腹いっぱい。
07/10/31 15:00:03
たとえばqmailのmaildir。
NFS環境下で安全にメッセージを配送するために、
ユニークなファイル名で衝突しないようにしている。
URLﾘﾝｸ(cr.yp.to) を見ると先頭に書いてあるのは、
> Two words: no locks.
173:名無しさん＠お腹いっぱい。
07/11/12 14:19:39
実家 in 四国にあるマシンのディスクを
俺んち in 大阪にあるマシンから nfs でマウントするのは無謀？
セキュリティ面はおいといて（ VPN 張るので）、
速度的にとか、ファイルの書き換えしてると不意に
ファイルがロストしちゃったりとか、そういうことってある？
174:名無しさん＠お腹いっぱい。
07/11/12 14:53:17
俺は東京にいるんだが普通にSan Joseのファイルサーバをマウントしてるぞ。
175:名無しさん＠お腹いっぱい。
07/11/12 15:07:04
>>174
そんな無謀な・・・
そういう時って TCP ベースの nfs 使うの？
それとも VPN 張った上でいつもの UDP なやつ？
そもそも NFS で TCP って聞いたときには
うへぇ、と思ったものだが。
176:名無しさん＠お腹いっぱい。
07/11/12 17:38:36
> NFS で TCP うへぇ
何で？
177:名無しさん＠お腹いっぱい。
07/11/12 19:10:29
>>176
NFS側にリトライ処理が付いてるのに
TCPにする事でTCP側の再送制御が増えるからではないかと。
1000/100Mbps混在でイーサネットスイッチが
バッファ溢れしてデータをポロポロこぼすような環境だと
NFS over TCPはそれなりに有効。
というかウチの社では推奨してる。
エラーフリー環境で使うなら、
TCPよりUDPの方が速いベンチ結果にはなるね。
178:名無しさん＠お腹いっぱい。
07/11/13 17:31:15
> 1000/100Mbps混在でイーサネットスイッチが
> バッファ溢れしてデータをポロポロこぼすような環境だと
まてまてIEEE802.3xのフロー制御あるんだからいまどきそんな環境ありえんだろ。
そんなとこでNFS使ったら再送発生するたびにどれだけつっかえるんだよ。
先にまずネットワーク直せよ。
179:名無しさん＠お腹いっぱい。
07/11/13 23:07:09
>> 1000/100Mbps混在でイーサネットスイッチが
>> バッファ溢れしてデータをポロポロこぼすような環境だと
>まてまてIEEE802.3xのフロー制御あるんだ>からいまどきそんな環境ありえんだろ。
普通そうだよな。
でも、そんなスイッチが半年前まで現行機種でな。
営業が安さにつられて構成勝手に変えて、
そのゴミスイッチ相手に格闘する羽目に orz
180:名無しさん＠お腹いっぱい。
07/11/14 00:33:23
flow controlで送信止められちゃうとnicの送信ディスクリプタが
足りなくなってOS内でパケット捨てることはあるかもしれない。
181:173
07/11/15 19:26:23
なんかうまくいかなかった原因がわかりました。
PPTP で Linux - Linux で VPN 張ってたんですが，
PPP での MTU のネゴシエーションがうまくできてなかったみたいで
1500 になってたのが原因でした．
思い切って 1400 にしたら問題なくなりました．
うむむ，NTT西日本のフレッツとケイオプティコムの
eo光の間の VPN なんですが，結構ヘッダついてるんだなぁ．
最適値は 1408 のような気もするけど面倒なので 1400．
普通は自動的にネゴってくれますよねぇ？
182:名無しさん＠お腹いっぱい。
07/11/19 13:13:21
URLﾘﾝｸ(www.linux.or.jp)
183:名無しさん＠お腹いっぱい。
07/11/20 11:13:29
NFSに強いスイッチを探してます。クライアントは６４台くらいです。
構成としては、クライアントとサーバを１つのスイッチに集約するのではなく、
２４ポートを数台使ってツリー型の構成にし、ツリーの上流にサーバを置く
形を想定しています。ネストは２段くらいです。
そのものずばりのお勧めより、こういう用途のときにスイッチに必要な機能は
どういうものかを教えていただけると、品定めするときに参考になるのですが、
お知恵を拝借できますでしょうか？
184:名無しさん＠お腹いっぱい。
07/11/20 11:39:49
普通にCatalystで良いジャン
185:名無しさん＠お腹いっぱい。
07/11/20 11:56:43
ワイヤースピード、ノンブロッキング
低レイテンシ
広帯域スイッチファブリック
186:名無しさん＠お腹いっぱい。
07/11/20 12:54:06
>>184
そこをもうちょっと安めでお願いできますか……
187:名無しさん＠お腹いっぱい。
07/11/20 20:32:18
NICは全てIntelで揃えるのが吉。
あと、サーバに極端な負荷がかからないよう、アップリンクだけ1Gにして
クライアントは全て100Mにするのが吉。
188:名無しさん＠お腹いっぱい。
07/11/21 08:56:03
Broadcom はだめですか？
AMD Opteron なサーバと Intel の NIC の
相性が悪いとかないかな？
189:187
07/11/21 10:09:53
>>188
> Broadcom はだめですか？
Broadcomは評価した事が無いので知らない。
190:名無しさん＠お腹いっぱい。
07/11/22 23:36:32
intelもだめだよなあ。相性悪すぎ。ギガビットは総じてダメ。
191:名無しさん＠お腹いっぱい。
07/11/23 01:10:20
蟹ギガ。これ、素人にはお勧めしない
192:名無しさん＠お腹いっぱい。
07/11/23 11:57:03
>>190
ちょ、んなこといったら使うものないじゃん。
193:名無しさん＠お腹いっぱい。
07/11/23 12:16:00
10Gbとか?
194:名無しさん＠お腹いっぱい。
07/11/23 12:18:50
>>192
Broadcomでいいじゃん
195:名無しさん＠お腹いっぱい。
07/11/23 23:24:06
broadcomは悪くないがvariantが多すぎて一口に語れないのが問題。
196:名無しさん＠お腹いっぱい。
07/11/24 00:21:00
なるほどね
197:名無しさん＠お腹いっぱい。
07/11/24 14:06:57
詳しい人に質問、unixでは次のプログラムで読取専用ファイルの作成が可能
int main() {
int fd; char buf[10];
int fd=open("poi", O_CREAT|O_TRUNC|O_WRONLY|O_EXCL, S_IRUSR|S_IRGRP|S_IROTH);
write(fd, buf, sizeof(buf)); /* creatを行ったfdは書き込みが可能 */
fclose(fd);
}
これをNFSv3マウントされたディレクトリ上で実行すると
CREAT, SETATTR, WRITEのprotocolが順に発行されます。
これをNFSサーバ側で問題なく扱おうとすると面倒があって
最後の読取専用へのWRITEを許可するかどうか、
WRITE要求のハンドルがCREATE時のものと一致するかで判断しないといけない。
このような判定の実装はNFSサーバにとって義務なのかな？
198:名無しさん＠お腹いっぱい。
07/11/24 14:11:09
>>197
当然義務。
読取専用かどうかは、creatまたはopenの際のみに有効な属性で、
一旦open(ハントル取得)してさえしまえば、
ファイル自体の読みとり専用かどうかに関係なく、
O_WRONLYとかでopenされたのなら書き込みができなければならない。
199:名無しさん＠お腹いっぱい。
07/11/24 14:11:38
>>197
プログラム中のfclose(fd)はclose(fd)の間違いです
200:名無しさん＠お腹いっぱい。
07/11/24 14:17:29
>>198
おー、こんなピンポイントで回答が来るなんて凄いです 流石unix板
ちなみにこれはCVSが実際にやってくれる操作です
201:名無しさん＠お腹いっぱい。
07/11/24 14:19:25
ちなみに、わざわざ C言語でプログラムしなくても、
シェル上で同じことができる。
umask 777
echo hoge > file
とやれば、fileは読み込みも書き込みも不許可で作成されるが、
echo hogeの内容はちゃんとfileに書き込まれる。
fileがNFS上にあっても当然動作しなければならない。
202:名無しさん＠お腹いっぱい。
07/11/24 14:21:35
なるほどumaskはそうやって使うんですね
203:名無しさん＠お腹いっぱい。
07/11/24 17:34:17
>>198
RFC1813, 4.4 Permission issues の第3段落に書いてありました
204:名無しさん＠お腹いっぱい。
07/11/25 15:06:35
RPC でつかうポートが変化するから、
NATルータ越しのNFSは㍉？
VPN 通すしかない？
205:名無しさん＠お腹いっぱい。
07/11/25 17:00:41
Intelの82573L で2.4系カーネルでNICのリセット多発した。
結局、NICのROMのアドレス1部変更で直った。
2.6カーネルでは解消された。
206:名無しさん＠お腹いっぱい。
07/12/06 13:41:08
>>204
実装によってはポート固定も無理ではないが、
ここで聞かないとわからないレベルならお薦めしない。
あと、WebNFSという選択肢もある。
207:名無しさん＠お腹いっぱい。
07/12/19 02:30:55
NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
NFSサーバに10GBのファイルがあって、それをNFSクライアントで読み込むときに
10GB全部をクライアントでリード・ライトしなきゃいけないとかそういうことなんでしょうか？
208:名無しさん＠お腹いっぱい。
07/12/19 09:08:58
>>207
> NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
どこであるいは誰に聞いた？
209:名無しさん＠お腹いっぱい。
07/12/19 09:21:46
>>208
google: NFS iSCSI ファイル ブロック
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞データ転送の単位は，NASにアクセスするときはファイル単位となる。つまり，NASへのデータ・アクセスでは，ファイル名や共有名などファイルを特定する呼び名で管理している。
＞これに対し，SANの場合はブロック単位の処理になる（通常1つのファイルは1つまたは複数のブロックで構成される）。SANでは，リモートにあるディスク装置内のディスクが，あたかもローカル・ディスク（RAWデバイス＊4）であるかのように振る舞う。
（略）
＞IP-SANには，「FCIP（Fibre Channel over IP）」「iFCP（Internet Fibre Channel Protocol）」「iSCSI（Internet SCSI）」という規格がある。この中で最も期待されているのがiSCSIである。
ってことじゃねーの？
210:名無しさん＠お腹いっぱい。
07/12/19 09:58:18
SCSIの復活キター？
211:名無しさん＠お腹いっぱい。
07/12/19 11:14:58
って事はiSCSIの方が巨大ファイルでは優位って事なの？
212:名無しさん＠お腹いっぱい。
07/12/20 16:46:40
何を持って優劣の指標としているのか明快に述べよ
213:名無しさん＠お腹いっぱい。
07/12/20 16:58:19
何を持って誤字の書込みをしているのか明解に述べよ
214:名無しさん＠お腹いっぱい。
07/12/27 14:42:36
NFSとiSCSIではファイルシステムの層が違う。
ファイル操作システムコール(API)
VFS
個々のファイルシステム(ext3,xfs,reiserfs,fat16,iso9660)
ドライバ
ハードウェア
NFSってのはファイル操作システムコールに相当、ファイル単位でも扱えるし、
バイト単位で読んだりもできる。VFSから下は考えなくてよい。
iSCSIってのはドライバに相当、ファイル単位では考えないで、
ハードウェアとのやりとりの最小単位(ブロック単位)で考えなければならない。
システムとして利用するには、ファイルシステム、VFS、システムコールも備えていなければならない。
215:名無しさん＠お腹いっぱい。
07/12/27 14:48:10
>>212-213
以って？
216:名無しさん＠お腹いっぱい。
07/12/27 19:59:34
RedHat Linux Enterprise Linux ES 4 2台で NFS サーバと NFS クライアントの設定をしました。
NFS サーバと NFS クライアント側では、それぞれの /etc/passwd にユーザが同じuid、gidで
登録されていて、group hoge に属するユーザだけに書き込ませたいです。
NFSサーバ側：
# mkdir -p /opt/share; ← NFS で共有したいディレクトリを作成
# chgrp hoge share
# chmod g+ws share;
/etc/exports の内容：
/opt/share 192.168.0.0/255.255.255.0(rw,sync)
NFS クライアント側
# mkdir -p /opt/share ← マウントポイントとなるディレクトリを作成
# chgrp hoge share
# chmod g+ws share;
mount -t nfs {nfs_server_name}:/opt/share /opt/share
ここまでは簡単にできたなのですが、nfs クライアント側から、umask が 0022 なユーザが
書き込みをすると、NFS サーバ側では -rw-r--r-- というファイルができます。
ここまではあたりまえですが、これを NFS 側で、強制的に -rw-rw-r として保存するような設定はありますか?
samba だと smb.conf で、公開ディレクトリのブロックの中で
directory mask = 0664
とできますが、これと同じようなことがしたいです。
217:名無しさん＠お腹いっぱい。
07/12/28 05:39:34
/opt/share のファイルシステムのマウントオプションのumaskしだいでは?
NFSサーバの実装によってはそういうのもありえるかもしれないけど、
NFSサーバでumaskを強制させてもあまり意味がないのかも。roかrwくらいだろうし…
218:216
08/01/05 07:48:19
>>217
レスどうもありがとうございます。遅くなってすみません。
結局以下の方法で対応しました。
NFS サーバ側で uid hoge / gid hoge という共通ユーザを作成し、
NFS サーバの /etc/exports で以下のようにした。
/opt/share 192.168.0.0/255.255.255.0(rw,sync,all_squash,anonuid=xxx,anongid=xxx)
↑ uid=xxx gid=xxx は、hoge:hoge の uid と gid
こうすることで、NFS クライアント側は gid hoge に属していれば、uid は別のユーザが
作成したファイルを、別のユーザが消すことができるようになりました。
理想は NFS サーバ側で、どの NFS クライアントのユーザがファイルを作成したか知れたほうが
よかったのですが、ここは目をつぶりました。
なお man mount すると、-t で指定するファイルシステムタイプの中で、
一部では -o に mask みたいなオプションが指定できるようですが、-t nfs のときは、
mask と行ったオプションは用意されていませんでした。
219:名無しさん＠お腹いっぱい。
08/01/06 11:20:48
そもそも論になるけど、NIS使えば?
220:名無しさん＠お腹いっぱい。
08/01/06 21:59:39
えーマジNISー？ｗ
NISが許されるのは10人未満のLANまでだよねーｗｗｗ
221:名無しさん＠お腹いっぱい。
08/01/06 23:17:07
>>220
じゃあなんNISればいいんですか？＞＜
222:名無しさん＠お腹いっぱい。
08/03/08 17:17:43
複数台のサーバ環境（自宅サーバ郡）でNFS使って共有するときって、どのディレクトリをシェアするのが効率的なんでしょ
みなさんの運用方法で「これはおすすめ！」っての、教えてもらえないでしょうか。
ちなみにうちはCentOS5の6台構成（Web 3台、Db1台、開発用1台、DB＆NFS＆Samba鯖機1台）
223:名無しさん＠お腹いっぱい。
08/03/08 17:39:30
WebサーバでNFSなんて使わないでくださいネ。
224:名無しさん＠お腹いっぱい。
08/03/08 17:43:03
>>223
え、そうなの？
/usr/local/libならシェアしてるけども。
225:名無しさん＠お腹いっぱい。
08/03/08 23:39:09
NFSっていらんやろ
226:名無しさん＠お腹いっぱい。
08/03/08 23:47:11
>>222
/homeのNFS共有は当然として、
OSのバージョンが同じなら /usr以下をすべてNFS共有する。
updatesとか、OSのバージョン管理が一元化できる。
ホストを1台増やす時でも、OSをインストールする必要はない。
もともとインストール済の/usrをNFS共有して、
ホスト毎に必要な/etcや/varなどを個別に用意するだけで済むから。
227:名無しさん＠お腹いっぱい。
08/03/09 13:46:30
>>223
ロードバランサーでWebサーバ束ねているような場合、コンテンツの
directoryをNFSで共有って、良くやるパターンだよね？
セキュリティの事を気にして言っているの？
だとしても、その対処法はあるわけで。
228:名無しさん＠お腹いっぱい。
08/03/09 21:25:20
たいていのパッケージシステムは、/usrのNFS共有を想定してないんじゃないかな。
少なくとも、 ベンダやメンテナによるテストはあまりされていないよね。
そもそも今はパッケージシステム(と安くなったディスク)のおかげで、/usrを共有する必要性って薄くない?
ロードバランサで分散しなきゃならないWebトラフィックって、CGI(CPU bound)なやつで、
その場合はRDBを共有するんじゃないかな。NFSサーバではなく。
NFSに限らず、ネットワークは不確かで、トラブルの発生源の代表格。
厄介なホスト間の依存性も発生するし、ホストローカルで完結するならその方がいいに決まってる。
このシステムにNFSって本当に必要なの? って自問してみるのは、管理コストを減らすのに役立つと思う。
個人的な感覚では、システムのメンテナンスのためにNFSをスポットで利用するのは便利だと思う。
(一般ユーザの/homeや/usr/portsみたいなのを共有するということね)
229:名無しさん＠お腹いっぱい。
08/03/09 22:31:09
Solarisでは、/usrはNFS共有することが前提で、
パッケージは SUNW**u が /usr用、SUNW**r が /usr以外用と、
きちんと分けて考えられてるね。
なるべく共有できるバイナリを増やすため、
/binを廃止して /binを /usr/binへのsymlinkにしてるくらいだし。
230:名無しさん＠お腹いっぱい。
08/03/09 23:41:52
つ、つまり共有すべきなのは/usr, /homeの二つが鉄板ということでおｋ？
ていうかNFSで共有してる時点でかなりアクセスのパフォーマンスが低下することは避けられないですよね、うーむ。
LAN内で共有してるのであればそんなに気にスンナってか。
231:名無しさん＠お腹いっぱい。
08/03/10 10:44:40
いまどきNFSなんて使ってるのか？
232:名無しさん＠お腹いっぱい。
08/03/10 11:13:09
>>230
日本語が読めてないな。
Solarisは/usrを共有することを想定して設計されているから共有できる。
おまえが使うOSはSolarisなのか?
233:名無しさん＠お腹いっぱい。
08/03/10 11:36:11
*BSD方面では、NFSは「無かったこと」にしたいんだろうなｗ
234:名無しさん＠お腹いっぱい。
08/03/10 11:42:27
よく知らんけど、Linux方面のNFS実装ってマシになったの?
235:名無しさん＠お腹いっぱい。
08/03/10 13:58:02
数年前にzero copyな実装になって今ではNFSv4まで対応してます。
236:名無しさん＠お腹いっぱい。
08/03/10 14:41:03
NFSでマウントしたディレクトリってやっぱりアクセス速度が低下するんですか
ってことはデータベース（MySQL)のデータ領域をNFS共有して運用するなんてしちゃだめですね。
でもなんでWebならいいんだ？
237:名無しさん＠お腹いっぱい。
08/03/10 14:53:29
書き込まないなら良いんじゃない？遅いけど。
238:名無しさん＠お腹いっぱい。
08/03/10 16:02:19
OracleみたいにNFS向けに最適化されているならともかく、
通常のデータベースはNFSファイルシステム上に置いてはいけない。
> でもなんでWebならいいんだ？
Webでもよくはない。NFSで複数のWebサーバがコンテンツを共有するのは、
導入費用も管理コストも高くつくアプローチだ。
239:名無しさん＠お腹いっぱい。
08/03/10 16:05:35
しちゃだめって言うより
意味なくね？
240:名無しさん＠お腹いっぱい。
08/03/10 16:08:35
>>238
> OracleみたいにNFS向けに最適化されている
そうなんか。
Windows 用のだとネットワークストレージ上に DB 作成するのは
やめとけ、みたいな感じだったけど(実際ごにょごにょしないと
作成出来ないし)。
241:名無しさん＠お腹いっぱい。
08/03/10 16:20:33
一万個の小さいhtmlファイルが1分ごとに更新されるとかの変なwebサイトで無い限り
NFSなんて使わないほうがいい
242:名無しさん＠お腹いっぱい。
08/03/10 16:36:32
>>236
>>227のことと合わせて考えると、Webの場合はCPUがボトルネックになりやすいから、
ロードバランサを導入する意味はある。ただし、変更されるデータの一貫性維持は
どこかで考えておかないといけない。ありがちなのは、そういうデータはDBサーバに
置いて、一貫性維持はアプリケーションとDBの合わせ技でまかなう感じ。
で、Webサーバと同じ理屈で、DBサーバのデータ領域をNFS上に置いて並列運用すると
どうなるかは…
243:名無しさん＠お腹いっぱい。
08/03/10 16:40:10
ちょうど今やろうとしてたことが話題にでてきたので教えてください。
サーバが自社内に10台あります、1台目（A）がDBサーバ兼Sambaファイル共有サーバ、もう一台(B)がログ解析＆バックアップ機、
残りの８台をWebサーバにしているのですが、この８台にWebコンテンツが分散しているのが運用上大変（めんどくさい)なため
Aのサーバサーバとして８台のWebをクライアントとしたNFSを構成しようと考えていました。
Webコンテンツは/home以下にHTMLファイルのほかPHPやJavaで書いたスクリプトやプログラムが含まれています。また、オリジナルで
書いたライブラリや、PEARなどの外部ライブラリを習慣として各Web機の/usr/local/libに格納しています。
これらそれぞれのバージョン管理などが非常にめんどくさいので、NFSを導入したいと考えているのですが、
↑のお話だとパフォーマンスが悪いので辞めたほうがよいということですか？
詳しいから、お知恵拝借させてください。
244:名無しさん＠お腹いっぱい。
08/03/10 17:01:22
>>238
WEBサーバの場合、どういう手法が良いんですかね？
rsyncとか？
245:名無しさん＠お腹いっぱい。
08/03/10 17:05:01
>>243
rsync3.0が出て速くなった(らしい)よ
246:名無しさん＠お腹いっぱい。
08/03/10 20:38:04
>>243
ここでそれを質問するということは、NFS環境下で障害を起こすアプリケーション・
ユーザコードの有無を検証できる人があなたの組織にはいないと見るけど、どうかな。
ならばrsyncで各サーバにファイルを配布するスクリプトを書いた方が安全だと思う。
コマンド1発で出来るようにしておけば管理の手間も生じない。
(バージョンに依存したアプリケーションが置かれているとかの理由で)共通化できない
特定のホストを個別に対応することも容易。
一般論として、すでに動いているサーバの構成を変えるのは上策じゃない。
NFSを入れるなら、運用を開始する前にテストするべき。
247:名無しさん＠お腹いっぱい。
08/03/10 21:37:33
NFSはもう古い、って広告、昔あったよね
248:名無しさん＠お腹いっぱい。
08/03/10 21:38:39
>>247
どんなん？
249:名無しさん＠お腹いっぱい。
08/03/10 22:05:11
>>242
DBにデータを書き込むアプリなら良いけど、ファイルシステム上に
ファイル生成したり、書き換えたりする奴もあるよね。
そうした場合は、NFS置くのが定石。
NetAppみたいの使えば、パフォーマンスもそれほど心配無いだろう。
250:名無しさん＠お腹いっぱい。
08/03/11 16:22:22
NetApp買えるなら、その金で1台に集約してNFS不要にする手もあるな。
251:名無しさん＠お腹いっぱい。
08/03/11 16:32:41
>>249
アプリケーションがちゃんと並列動作まで考慮してくれてるならいいけど、
通常ファイル使うことからしてあまり期待できないような。
アプリケーションの中身知ってるものならいいけど、自分は定石とまでは言いたくないな。
252:名無しさん＠お腹いっぱい。
08/03/11 23:07:04
いずれ結局中身を気にすることにはなる
253:名無しさん＠お腹いっぱい。
08/03/12 00:42:22
>>251
ここで言っているアプリは、ロードバランサーで負荷分散できる様な
Webアプリだからね。DBだけじゃなくて、ファイルに書く奴あるじゃん。
そう言うのは、NFSファイルサーバ立てて使うよね？
254:名無しさん＠お腹いっぱい。
08/03/12 08:27:40
まあそうだけど、それは「まずい設計をどうにか延命する方法」であって、定石と呼ぶのは抵抗あるなあ。
逆説的だけど、NFS環境を想定したコードが書ける人は、NFSに依存しないで済む方法も用意する。
NFSを使わざるを得ない、というのは、それが本当にNFS上で運用しても問題ないように出来ているのか、一沫の不安を感じるのだ。
NetAppまで導入してしまえば、バックアップ等の運用コストを下げられる余地がでてくるので、
NFSをデスクトップクライアント限定の技術だと考えるのは保守的な考え方かもしれないけどね。
255:名無しさん＠お腹いっぱい。
08/03/12 12:59:40
すくなくとも DBのID/PASSはファイル持ちだと思うな。
256:名無しさん＠お腹いっぱい。
08/03/12 13:04:17
アクセスをきっかけに変更されないデータならどうだっていいんだけどさー、
>>253はファイルに書くって書いてるじゃん……
257:名無しさん＠お腹いっぱい。
08/03/12 13:30:05
>>256
アプリケーションの設計の話だ。
ストレージはファイルシステムだけじゃないだろ?
複数ホスト間で変更の共有が必要な情報を、安易にファイルシステムに格納するアプリケーションは、
トラブルを潜在している徴候だ。
258:256
08/03/12 14:56:34
>>257
いやまぁ、だからそういうことを言いたいわけで。
書き込みするのにNFS共有するのは危ないだろうと。
259:名無しさん＠お腹いっぱい。
08/03/13 02:27:16
自宅で5台動かしてるCentOSサーバ（Webサーバ）それぞれにログインするのがめんどい…
/homeを一台でNFS共有して使いまわそうかなと思うのだけど、邪道かな
ついでに/usr/local以下も共有して、自作ライブラリやソースファイルをシェアするってのも検討中。
ガッコで教わったわけじゃないので、どういう風に使うのかが正道なのかわからず、すまんかった…
260:名無しさん＠お腹いっぱい。
08/03/13 10:22:35
/homeは共有してもいいんじゃないか？
261:名無しさん＠お腹いっぱい。
08/03/13 11:25:47
/homeやサイトローカルなディレクトリのNFS共有は真っ当だろう。
てか、自宅なら好きにやればいいと思うが、
システムのブートやデーモンの類はNFSサーバに依存させないのが吉。
ホスト間の依存関係が複雑になると管理がとてもとても面倒になるから。
あと卒直に言えば、ログインが面倒になるほどホスト増やす時点で
かなり間違った道を進んでいる。
262:名無しさん＠お腹いっぱい。
08/03/13 12:16:40
>>261
ログイン簡単にするって、どうすればいいの？
うちの会社は100台弱あって大変… /usr/localをシェアするのっていいなあ
263:名無しさん＠お腹いっぱい。
08/03/13 13:23:30
機械なんだから管理はどんどん自動化しろよ。
なんのためのUNIXだよ。
264:名無しさん＠お腹いっぱい。
08/03/13 13:29:48
シェアはしないけどNFSにする、って方法もあるぞ。
クライアントの /usr/local他のデータを個別に NFS鯖側に持つ。
すると、NFS鯖にログインするだけですべてのクライアントのデータをいじれる。
シェアはしていないので、書き込み競合とかの問題もなし。
265:名無しさん＠お腹いっぱい。
08/03/13 15:14:19
>>263
それ、俺もすげー興味ある。
どんな感じで管理してるの？ 参考にしたい。
266:名無しさん＠お腹いっぱい。
08/03/13 16:38:40
NFSにちょっと関係があるかと思い便乗質問で恐縮ですが、
NISも導入した方がいいでしょうか？ ひとつのサーバにパスワードやグループなどを
一括管理できるようになるのはメリットかと思うのですが、逆にデメリットって実運用
ではどんなことがあるのかと思い。 よろしくおねがいしまんこ。
267:名無しさん＠お腹いっぱい。
08/03/13 16:40:04
今更NISか？
LDAPで良いんじゃね？
268:名無しさん＠お腹いっぱい。
08/03/13 18:19:01
>>266 UNIXだけで組んだシステムならNISでも悪くないよ。シンプルだし。
デメリットとしては、古臭いというぐらいだと思うｗ ある程度の規模になると
LDAP + NSS + nscd の方が安定性も反応性も高い希ガスです。
>>262 100台って少ないね・・・
>>263 激しく同意。人間様のプライドとして単純作業はすべて機械にやらせる。
>>265 cfengine とか Puppet とか？
漏れは自作フレームワークでインスコからメンテから全部楽々運用だな。
人海戦術の手作業で鯖管理してるような DQN を見てると悲しくなる。
269:名無しさん＠お腹いっぱい。
08/03/13 19:14:31
自作フレームワークをオープンソースでうpしてくれ
270:名無しさん＠お腹いっぱい。
08/03/13 19:17:46
NIS使うとshadow passwdの意味がなくなるんだよな。いや、別にいいんだけど
271:名無しさん＠お腹いっぱい。
08/03/13 19:37:56
うちもNFS+NISだな。
/homeと/usrをNFSで共有。PXE Bootで/もNFS越し。
まあ、数値計算用でほとんど同じ構成だから、あまり凝ったことをしなくても管理は楽。
272:名無しさん＠お腹いっぱい。
08/03/13 20:48:20
>>270 C2セキュリティのオプションONにすればok
ypcatで表示しなくなる。
それでも気になる人はNIS+をどうぞ。
273:名無しさん＠お腹いっぱい。
08/03/13 21:16:38
NIS+はサポート終了だって
274:名無しさん＠お腹いっぱい。
08/03/13 22:41:03
めでたしめでだし
275:名無しさん＠お腹いっぱい。
08/03/15 01:07:04
NFSの転送速度って遅くないですか？
276:名無しさん＠お腹いっぱい。
08/03/15 05:48:30
いやーそれほどでも
277:名無しさん＠お腹いっぱい。
08/03/15 09:32:29
うちは50MB/secが限度だった
278:名無しさん＠お腹いっぱい。
08/03/15 15:36:04
うちは75MB/sぐらい。
279:名無しさん＠お腹いっぱい。
08/03/15 16:06:22
> UNIXだけで組んだシステムならNISでも悪くないよ。
悪いこといわんからLDAPにしとけ。
NIS/NIS+はobsolete technologyだ。
特に100台あると(>>262)、NISにはmap転送ストームの問題がある。
280:名無しさん＠お腹いっぱい。
08/03/15 16:56:06
NFS自体
281:名無しさん＠お腹いっぱい。
08/03/15 19:10:52
NIS+はobsolete technologyだが
NISは今も今後も現役。
282:名無しさん＠お腹いっぱい。
08/03/15 19:55:48
昔はうちでも/usr/localをNFSで共有してたけど、パフォーマンスが悪いので
rsyncで毎晩mirrorする設定にしてるよ。共有してるのは/homeだけ。
/usr/localを更新したら トリガーになるファイルのタイムスタンプを更新して
ＮＦＳ server側で
touch /usr/local/UPDATE
と印付けておく。
で、client側では、
if [ /mnt/local/UPDATE -nt /usr/local/UPDATE ]; then
DORSYNC="1"
fi
とかして実行させる。ここで全てのclientが同時にrsyncかけると負担がかかるので
そのへんはばらけるように工夫する。
283:名無しさん＠お腹いっぱい。
08/03/15 20:12:24
>>281
NISはレプリカが多い時に、
パスワードの同時変更が起きると悲惨。
まさにobsolete。
284:名無しさん＠お腹いっぱい。
08/03/15 20:14:03
NISではレプリカとは言わん。批判するなら正しい用語で。
285:名無しさん＠お腹いっぱい。
08/03/15 20:18:36
じゃあスレーブなw
286:名無しさん＠お腹いっぱい。
08/03/15 20:21:16
ここでhesiodの出番だな
287:名無しさん＠お腹いっぱい。
08/03/15 20:23:38
yppushが起きるだけだが? 何が悲惨?
288:名無しさん＠お腹いっぱい。
08/03/15 20:30:30
NISがだめだとおもうならnetinfoを使えばいいのに
289:名無しさん＠お腹いっぱい。
08/03/16 01:21:26
おっさんが多いスレなのかしら
290:名無しさん＠お腹いっぱい。
08/03/16 14:43:57
エクスポートする、またはマウントするパスで、効率的なやり方を教えてください
291:名無しさん＠お腹いっぱい。
08/03/16 15:30:25
/
292:名無しさん＠お腹いっぱい。
08/03/22 05:02:33
高スペック機1台をNFSサーバにして /export/各サーバ名/home それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンのLinux（centos5.1 x86_64）同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
293:名無しさん＠お腹いっぱい。
08/03/22 08:57:35
Linuxのネタをここでやろうとするのは変
294:名無しさん＠お腹いっぱい。
08/03/22 12:13:28
高スペック機1台をNFSサーバにして /export/各サーバ名/home それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンの FreeBSD 6.3R同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
295:名無しさん＠お腹いっぱい。
08/03/22 12:30:31
FreeBSDでNFSはヤツの召還呪文
296:名無しさん＠お腹いっぱい。
08/03/22 19:51:32
NFSは激遅
297:名無しさん＠お腹いっぱい。
08/03/22 20:56:27
>>294
そんなことしないでバックエンド側でファブリック組めばええんちゃう？
298:名無しさん＠お腹いっぱい。
08/03/23 03:07:14
>>262
1000台以上あるけど、適当な認証鍵つくって、ループスクリプトでsshでttyつかんで...
ちょいshellscriptを汎用的に書いておけば、一気に全台同じコマンドじっこうできるよん
299:名無しさん＠お腹いっぱい。
08/03/23 16:29:41
>>298 どの様に書くのでしょうか。教えていただけますか。ぜひサンプルを。
300:名無しさん＠お腹いっぱい。
08/03/24 16:42:59
NISよりも優秀なのってなんだっけ？
301:名無しさん＠お腹いっぱい。
08/03/24 19:57:40
>>300
Active Directoryです。
302:300
08/03/24 22:22:59
>>301
ありがとう、Active Directoryを導入しました
303:名無しさん＠お腹いっぱい。
08/03/25 10:57:40
>>292
Web公開ファイルを/homeで共有するってこと？ アクセス数次第だなぁ。
スタッフアカウントを/homeで共有するのは良いアイデア。
/usrを共有するのは悪いアイデア。rsyncで同期しておけば良い話だから。
304:名無しさん＠お腹いっぱい。
08/03/25 11:04:28
>>303
アクセスが多い場合、NFSの転送速度からするとよくないんじゃね？
/homeもrsyncかｗｗｗ
305:名無しさん＠お腹いっぱい。
08/03/25 12:13:21
Webコンテンツならローカルに置くだろうけど、
EtherもCPUも速くなった今の時代、単純にNFSだから遅いとはいいきれない。
ローカルの単体SATAとリモートのNetApp、どちらが平均アクセス速度が速いか。
実運用ならバックアップも考えないと。
306:名無しさん＠お腹いっぱい。
08/03/26 02:15:23
CODAも、AFSもどこ行っちまったのだろ。
教えてくれ。
307:名無しさん＠お腹いっぱい。
08/03/26 02:49:23
Webアプリのこの時代に分散ファイルシステムってもの…
Satyanarayananのページに久々に行ってみたら、
Internet Suspend/Resumeってのやってんのな。
これもGoogle Gear辺りと比べるとかなり低い階層でやってるな。
308:名無しさん＠お腹いっぱい。
08/03/26 08:48:24
W
S
I
こ
309:名無しさん＠お腹いっぱい。
08/03/28 01:17:22
URLﾘﾝｸ(lists.freebsd.org)
310:名無しさん＠お腹いっぱい。
08/03/28 14:26:06
nfsでマウントしているディレクトリに、100byte程度のデータを
細かく書いていくプログラムを走らせると、そのクライアント側の
ホストでnfsディレクトリにかなり長い時間アクセスできなくなるのですが
この現象の解決策に関する情報はありませんか？
OSはRedhatlinux4.6 64bit
カーネルは2.6.9-67.EL でも2.6.24でも起こります
同じことをRedhatLinux3.0 の64bit版でやっても起こらないのですが・・
311:名無しさん＠お腹いっぱい。
08/03/28 18:18:40
a) 100バイトずつ投げるな
b) ELなんだからベンダのサポートに投げろ
c) Linuxなんぞ投げ捨てろ
312:名無しさん＠お腹いっぱい。
08/03/28 18:42:22
どうでもいいが、RedHat4.xって、1998年かそれ前後頃、
3.xは1997年頃? すげー古いOSだよね?
313:名無しさん＠お腹いっぱい。
08/03/28 19:01:45
RHLに4.6なんてない。
314:名無しさん＠お腹いっぱい。
08/04/01 02:59:21
>>310
NFSをasyncにしてみたら?
315:名無しさん＠お腹いっぱい。
08/04/01 04:09:49
cacheも増やすべき。acdirmax辺り。
mountオプソンで指定。
316:名無しさん＠お腹いっぱい。
08/04/01 07:49:06
時間割くなら、try&errorの厨ニングよりプログラム直した方が幸せになれると思われ。
NFSだろうがなかろうが、バッファリングせず100byteずつwrite(2)ってのは頭おかしい。
データの整合性を維持する意図でそうしてるならasync mountで動かすのは本末転倒だしな。
ソースがないならご愁傷様。
317:315
08/04/01 08:49:29
あれ? 小さいファイルをたくさん作るのかと思ったよ。
どっちとも取れるけど、一つのファイルに少しづつ書くなら、
ディレクトリがアクセスできなくなるのはおかしいなあ。
318:名無しさん＠お腹いっぱい。
08/04/02 01:41:55
>>310
現状のマウントオプション晒しなYo!
319:名無しさん＠お腹いっぱい。
08/04/05 13:20:26
まあrhelなら4.6はあるけど板違いだしなあ
320:名無しさん＠お腹いっぱい。
08/04/09 09:41:04
NFSv3 で同じLANにつながっているマシン同士ではサクサク
ファイル公開できているんだけど、セキュリティ上の理由から
TCPしか通してくれないL3スイッチ越しの隣の部屋のNFSサーバの
ディレクトリを NFSv4 でマウントしたら ls に引っかかる。
ファイルの読み書き、でっかいファイルの転送速度に関しては
たいした違いも無いんだけど、 ls で引っかかる。数秒。
何が原因なんでしょうか？
当然 portmap なんかも通らないんですが、それが原因
なんでしょうか・・・でも NFSv4 だしなぁ。2049/tcp
だけで使えると思うんだけど。
321:名無しさん＠お腹いっぱい。
08/04/09 09:47:49
>>320
L3が糞
322:名無しさん＠お腹いっぱい。
08/04/09 09:55:21
>>321
id でも引っかかるんで、nsswitch.conf 見てみたら、
hosts に wins が指定されていた orz
samba とか使ってねぇのに。
323:名無しさん＠お腹いっぱい。
08/04/09 10:36:20
NFSv4のクライアントは何?
Solaris以外でまともに使えるのある?
324:名無しさん＠お腹いっぱい。
08/04/09 10:46:04
>>323
>>322 で自己解決したようです
>>321 ハズレ
325:323
08/04/09 11:58:15
いや、トラブルとは関係ない質問
326:名無しさん＠お腹いっぱい。
08/04/09 12:51:31
まともに使える=俺の環境・俺の使ってるアプリケーションが動く、だから
基準が人によって全然違うんだよな。
クライアントは1台なのか100台なのか、
テキストエディタでファイルが開けばいいのか、データベースが置けないとダメなのか。
327:323
08/04/09 13:09:20
基準は>>320の基準でいいや。
「～をこう使っていてトラブルなし」ってんで。
ちなみに俺は自宅のファイル共有で使うことしか想定してない。
v3→v4の移行するかどうか。
仕事ならクライアントサイドはSolaris以外でv4使わないし。
328:320=322
08/04/09 13:28:11
server Ubuntu 6.06.2 LTS / kernel 2.6.15
client CentOS 5 / kernel 2.6.18
329:名無しさん＠お腹いっぱい。
08/04/13 03:40:27
質問です、自宅のLANにCentOS5.1のマシンが4台入る予定なのですが、なるだけ
少ない台数で集中管理したいと思っています。
1台の/homeを他3台でシェアしようと思うのですが、自宅LANのような小規模な環境
だとあまり意味の無い方法でしょうか？
それか、みなさんの書き込みを読んでいると人気の、rsyncをつかって1台のデータを
共有しようかと思ったのですが、リアルタイムに同期してる訳じゃないですよね。
330:323
08/04/13 09:05:07
>>328
Linuxかあ。今度トライしてみるわ。
ちなみにサーバはOpenSolaris。
331:名無しさん＠お腹いっぱい。
08/04/13 09:08:15
>>329
全部、デスクトップ機なの?
ノートにNFSホームは良くないと思うけど、
デスクトップならオフライン利用考える必要ないしNFSでいいと思うよ。
332:名無しさん＠お腹いっぱい。
08/04/13 12:01:06
>>331 サンクスっ！
NFSでシンプルに構成しようと思います。
よく考えてみりゃ/homeだけってのももったいないから他のも共有マウントしよう
かと思うのだけど、みんなどんな感じでマウントしてるんでしょう？定石ってあるのでしょうか。
マウントする側（3台の方）のHDDって８０GBもあるんだけど、マウントしちゃうと余計HDD領域が余っちゃう
よね、なんだかもったいねえ。
333:名無しさん＠お腹いっぱい。
08/04/13 12:20:52
クライアントはHDD外してディスクレスだよ。
ネットブートして、/ 全体すべて NFSだよ。
LANが速いと、かえってローカルHDDより速い感じがするくらい。
334:名無しさん＠お腹いっぱい。
08/04/13 13:04:27
>>333
素人に無駄な期待を抱かせるような書き込みはよせ。
それはハイエンドのNFS専用鯖機のときの話だ。
335:名無しさん＠お腹いっぱい。
08/04/13 13:41:34
>>334
自宅のふつーのPCで >>333 みたいなことしてるけど、、
336:名無しさん＠お腹いっぱい。
08/04/13 14:22:05
>>335
さて、これが無駄な期待でない理由を説明してくれ。
「ローカルHDDより速い感じがするくらい。」
337:名無しさん＠お腹いっぱい。
08/04/13 17:00:31
誇張表現
338:名無しさん＠お腹いっぱい。
08/04/13 17:56:21
そりゃ、ユーザ一人とか、Ｎｅｔｗｏｒｋスカスカなら
そこそこ良いかもしれんけど・・・・・
339:名無しさん＠お腹いっぱい。
08/04/13 18:08:20
自宅でやっているときの話とかいているから
ユーザーは分かっている範囲だしネットワークはすかすかだろうな
340:名無しさん＠お腹いっぱい。
08/04/14 00:51:14
>>332
・/homeと/usr/localだけ共有。
相互依存が起きないように両方同じサーバに。
・システムが必要とする分だけを全て/パーティションに。
パッケージシステムに任せて決して共有しない。
・残りは別パーティションとし、nfs exportして、
画像、音楽データを入れたり、バックアップに使ったり。
341:名無しさん＠お腹いっぱい。
08/04/14 08:38:20
ぶっちゃけ自宅ならば/homeというよりも、/home/homepageだけをシェアして
基本的にワンユーザー（homepage)で運用したほうが効率いいんでないかい？
あとは>>340の言うとおり/usr/localもかなあ
個人的にはDNSやsambaを設定してる/etcの一部ファイルもうまくシェアできないかと悩み中
342:名無しさん＠お腹いっぱい。
08/04/14 08:40:19
>>341
おまえ家族いないのか?
343:名無しさん＠お腹いっぱい。
08/04/14 19:52:49
むしろ家族がいてNFSを使っているような奴が異常
344:名無しさん＠お腹いっぱい。
08/04/14 20:00:20
鯖なんか立てたら、
うるせーよとクレームくる。
345:名無しさん＠お腹いっぱい。
08/04/14 20:49:40
居間のPCでも寝室のPCでも子供部屋のPCでも、
どのPCからログインしても自分の$HOMEで同じ環境にするには
ふつーNFSだろ。
346:名無しさん＠お腹いっぱい。
08/04/14 21:03:29
寝室でエロ動画ばっか見てないで、たまには奥さんの相手してやれよ。
347:名無しさん＠お腹いっぱい。
08/04/14 21:32:01
恥ずかしがり屋の妻がPCの中から出てきてくれません
348:名無しさん＠お腹いっぱい。
08/04/14 22:19:54
君のPCの中にいてくれるならそれでいいじゃないか
349:名無しさん＠お腹いっぱい。
08/04/14 22:33:23
>>348
生きろ
350:名無しさん＠お腹いっぱい。
08/04/15 02:29:46
/homeを共有したとしてもログインするためのアカウントやパスワード情報がシェアできなきゃ意味なくね？
351:名無しさん＠お腹いっぱい。
08/04/15 03:40:35
ホームと比べて人力同期の手間が大した事ない上にスレ違い。
352:名無しさん＠お腹いっぱい。
08/04/15 06:27:47
>>350
だから NIS使うんだろ。
353:名無しさん＠お腹いっぱい。
08/04/15 07:42:33
NFSはv4でTCPだけで使えるようになったけど、
NISはやっぱりportmap必須でポートの制御が難しいね。
LDAPでもよくね？
354:名無しさん＠お腹いっぱい。
08/04/15 08:48:17
UDP通してなんか問題ある? ポートの制御? そのなの必要ある?
355:名無しさん＠お腹いっぱい。
08/04/15 13:48:51
ていうかエルダップ使えよ、
国民は全員使ってるぜ、おまえんち以外は。
356:名無しさん＠お腹いっぱい。
08/04/15 14:14:35
そもそもportmap(rpcbind)は、ポート番号を意識せずに、
さらに言えば、下位レイヤーがTCP/IPソケットかどうかすら意識せずに
通信できる上位レイヤーのための概念だ。
それを使わずにポート番号固定にしてTCP/IPに依存するのは昔の考え方。
357:名無しさん＠お腹いっぱい。
08/04/15 14:24:09
誰も固定にするなんて言っていない。
358:名無しさん＠お腹いっぱい。
08/04/15 14:47:45
そういう場合はどうすると言ったのかを言わないと「固定にする」と言ったとみなされたままになる。
359:名無しさん＠お腹いっぱい。
08/04/15 22:30:41
べつにNISでもLDAPでもNetInfoでもいいよ
360:名無しさん＠お腹いっぱい。
08/04/16 02:54:04
>>359
比較するとしたらどれが良いと思う？
361:名無しさん＠お腹いっぱい。
08/04/16 04:21:04
LDAP
362:impress入門者
08/04/16 16:14:03
>>682, 683
マイレイアウト追加って出来ますか?
数式の規定フォントの指定って出来ますか?
363:名無しさん＠お腹いっぱい。
08/04/16 16:25:44
NFSじゃ無理
364:名無しさん＠お腹いっぱい。
08/04/16 22:21:40
いや、なんとかすりゃできるかもよ？
俺は教えないけどね
365:名無しさん＠お腹いっぱい。
08/04/19 03:14:55
NFSで/usrをシェアするってどうなの？
366:名無しさん＠お腹いっぱい。
08/04/19 06:55:24
どうって、普通だよ
367:名無しさん＠お腹いっぱい。
08/04/19 13:57:21
や、/usr/localを共有するもんだと思ってたんだけど
>>365みたく/usrなんて共有していいものなのか？
368:名無しさん＠お腹いっぱい。
08/04/19 14:53:31
>>367
/usrだからこそ共有していい。
ホスト間で共有できるものは /usr以下(/usr/bin /usr/lib /usr/sbin等)に。
ホスト間で共有できないものは /etc /var /bin /sbin /lib等に
というルールになっている。
Solarisではホスト間で共有できるファイルを増やすため、
/binをsymlinkにして、すべて/usr/binに移動している。
369:名無しさん＠お腹いっぱい。
08/04/19 16:58:26
NFS鯖に障害が出たときにすげー面倒くさそう。/sbinだけあってもなぁｗ
用途や規模や更新頻度にもよるけど、漏れはrsyncとかパッケージの管理とかで
統一する方が好きかな。
370:名無しさん＠お腹いっぱい。
08/04/19 21:36:28
んじゃ、NFSじゃなくrsyncで全ホスト間の/usrで同期をとるならば
cronとかで定期的に親機から全ホストに対してrsyncするスクリプトを叩く、でおｋ？
一時間おきとかに。
371:名無しさん＠お腹いっぱい。
08/04/20 11:17:05
パッケージとパッチ使えよ。
372:名無しさん＠お腹いっぱい。
08/04/20 12:23:00
/usr以下なら、更新したタイミングで同期すればいいじゃない
373:名無しさん＠お腹いっぱい。
08/04/20 12:58:33
ガチで管理したいならもうpuppetとか導入しちゃった方がいいんじゃない？
374:名無しさん＠お腹いっぱい。
08/04/25 02:29:03
パペットってどうよ？
10台以下の環境で使うほどの必要あるかな
375:名無しさん＠お腹いっぱい。
08/04/27 10:35:38
RDISKはNFSですか？
376:名無しさん＠お腹いっぱい。
08/05/02 07:46:00
NFSでマウントしたボリュームについても，クライアント側で
通常のファイルシステムのようにキャッシュは有効なのでしょうか？
NFS 鯖においてあるファイルを NFSv3 でマウントして，
そこそこ大きなファイル（10M程度のログファイル）を
何度も読み込むとすると，何度もトラフィックが発生
するものなのでしょうか？
Linux ユーザなのですが NFS のスレが Linux 板にないのでここに来ました．
なお，FS-Cache とか cachefilesd は使っていません．
通常のディスクキャッシュの仕組みがNFSでマウントした
ボリュームでも働くかどうかということです．
377:名無しさん＠お腹いっぱい。
08/05/02 07:51:22
>>376
当然キャッシュされる。もちろん、クライアントの搭載メモリ次第だが。
同じファイルを読み込む場合、2回目は速い。
378:名無しさん＠お腹いっぱい。
08/05/02 09:19:12
>>376
man 5 nfsも読んどいてくれ
379:376
08/05/02 13:35:30
レスありがとうございます。最近NFSを利用している
クライアントマシンから「NFSが気絶してる」という
苦情を受けるので、使い方を聞いてみたら10000個ほどの
10MB程度のファイルを次々と grep しただけ、とのこと。
しかも1ファイルごとに100回くらい読み直したとのコト。
せめてクライアント側でキャッシュが有効なら同じファイル
100個読むのは別に負荷じゃないよなぁとおもったのです。
さきほど nfsstat をサーバ側でやってみたら、
Server nfs v3:
null getattr setattr lookup access readlink
6 0% 18278453 80% 143964 0% 781712 3% 2524218 11% 0 0%
read write create mkdir symlink mknod
352987 1% 455073 1% 54698 0% 6321 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
51737 0% 5598 0% 88 0% 0 0% 107265 0% 27950 0%
fsstat fsinfo pathconf commit
8 0% 2 0% 0 0% 17191 0%
うむむ、getattr だけで 80% らしい。80% というのが回数なのか
そのコールを処理するのにかかった時間なのかわかりませんが、
なんにせよ getattr 恐るべし。man 5 nfs によるとディレクトリ
エントリがらみのキャッシュ時間を設定しろということなのでしょうか。
うちの使い方では関係ないですが、ディレクトリエントリを
キャッシュしちゃうとロックファイルのような使い方を
してるアプリケーションにとってはまずいことがおきる？
380:名無しさん＠お腹いっぱい。
08/05/02 13:44:43
>>379
RHEL4ならbugzilla見にいけ
381:376
08/05/02 16:31:35
>>380
サーバは Ubuntu LTS 6.0.6 LTS です。が
今使ってるカーネルのバージョンに絡んだ何かが
あるかもしれないので時間のあるときに見てみます。
ところで、みなさん nfsd の数ってどうやって最適値を
見積もってらっしゃるんでしょうか？ デフォルトが 8
だし、デュアルコアだから 16、いや、20 くらいにしておこう
程度の発想しかできないんですが、たとえば /proc 以下の
何かをモニタしていればヒントが得られるのでしょうか。
382:名無しさん＠お腹いっぱい。
08/05/02 16:42:55
>>381
URLﾘﾝｸ(nfs.sourceforge.net)
383:376
08/05/02 18:48:15
>>382 THX
384:名無しさん＠お腹いっぱい。
08/05/03 01:38:24
>>379
NFSマウントしているところで、
シリアスな「ロックファイル」を使っちゃいかん。
firefoxの二重起動禁止程度の奴なら実用上問題ないけど。
385:名無しさん＠お腹いっぱい。
08/05/05 02:07:33
NFSで10台くらいとシェアするとやっぱりパフォーマンス落ちますか
386:名無しさん＠お腹いっぱい。
08/05/05 03:26:14
サーバによるよ。
ローカルディスクより速いサーバは一杯ある。
387:名無しさん＠お腹いっぱい。
08/05/05 12:57:28
ML115なんですが
388:名無しさん＠お腹いっぱい。
08/05/05 13:56:40
マウントするだけなら変わらない（当たり前？）。
少々のコマンドを読む程度ならそれもあまり変わらない。
I/Oを大量に発生させるクライアントが多ければ、下がる。
としか言いようがないよ。
ここ参考にならんかな？
URLﾘﾝｸ(www.spec.org)
ならんか。
389:名無しさん＠お腹いっぱい。
08/05/05 14:27:08
実際にやってみて問題がでたら、ひとつずつ解消してきゃいい。
そういう手間暇かけて試行錯誤するのが許されず、
一発で正着が欲しいなら、経験のある人に頼めばいい。
390:名無しさん＠お腹いっぱい。
08/05/05 17:06:14
NFSやるならNISも必須だろ
391:名無しさん＠お腹いっぱい。
08/05/05 18:03:12
いやそれほどでも
392:名無しさん＠お腹いっぱい。
08/05/05 19:49:13
NISとかLDAPとかNetInfoとかアカウント管理なくても、
NFSプロトコルは問題なく動きます。
393:名無しさん＠お腹いっぱい。
08/05/05 20:00:13
アカウント管理なんてする必要あるのか？
100台だろうが1万台だろうが、手作業でアカウント設定すりゃいいじゃん
394:名無しさん＠お腹いっぱい。
08/05/05 20:05:59
アイデンティティ管理って奴ですかな。
395:名無しさん＠お腹いっぱい。
08/05/05 20:07:52
認証したい時(UNIX認証は除く)はsecure RPCかKerberosが必要になる。
396:395
08/05/05 20:08:47
>>395
Secure RPCのDES認証かKerberos認証というべきだった。
397:名無しさん＠お腹いっぱい。
08/05/08 11:00:16
サーバ、クライアントともに
Ubuntu Linux 6.06 LTS
kernel 2.6.15
で nfs4 での利用を試みているのですが、
ブート後数日は普通に動いているのに
いつの間にか ls すると Input/ouptut error
と表示されるようになります。
でもディレクトリエントリが取得できないだけで
そこにあるはずのファイルは読み書きできます。
何が起こっているのでしょうか？
ちなみに Netfilter (iptables) や hosts.{allow|deny}
での制限は一切無しの状態です。
/etc/exports を書き換えて、同じ場所を
NFS v3 でエクスポートしてマウントすると
普通に ls できます。NFS において ls だけできない
（そこにあるはずのファイルにはアクセスできているのに）
というのはどんな状態なのでしょうか？
398:名無しさん＠お腹いっぱい。
08/05/08 11:05:27
>>397
>というのはどんな状態なのでしょうか
普通に、ディレクトリだけが読めない状態。
NFS関係なしに、
chmod a-r .
ってやると、カレントディレクトリをlsできなくなるが、
その下にあるファイルは(ファイル名がわかっていれば)読める。
399:397
08/05/08 11:12:12
複数台あるファイル鯖で、NFS v3 で普通はマウントしていて
幸せな暮らしを営んでいるのですが、ファイアウォールの関係で
隣の部署からは NFS v4 (proto=tcp) でマウントしています。
そいつだけたまにディレクトリエントリが見えなくなるのです。
ファイルにはアクセスできているので気づかないことも多いです。
障害発生時刻とログをつぶさに観察していると
nfs_update_inode : inode number mismatch
expected (0:14/0x2), got(0:14/0xb001)
がサーバ側で出たあとにクライアント側からディレクトリ
エントリが見えなくなるようです。それが出たあとも
気を取り直して NFS v3 でマウントしているクライアントからは
何も障害が見えません。
さらに NFS 鯖のログをさかのぼってみていると
nfs4_cb : server xxx.xxx.xxx.xxx not responding, timed out
が頻繁に出ています。これと関係あるのでしょうか。
nfs4_cb が何かこれからググろうと思いますが、
属性キャッシュがらみなのだろうか・・
400:名無しさん＠お腹いっぱい。
08/05/08 11:17:59
まずfirewallを疑えよ。
firewallの中でnfs4で確かめてみたら。
401:名無しさん＠お腹いっぱい。
08/05/08 11:18:43
スキルもなく実績もないUbuntuLTSなんか使うなよ。
402:397
08/05/08 11:42:00
>>400
ファイル鯖上で localhost がエクスポートしているものを
localhost でマウントしても同じ障害が発生します。
とりあえず週末に業務が終わったらカーネルを差し替えるべく
VMware 上で他のバージョンのカーネルでの挙動を確かめてみます。
403:名無しさん＠お腹いっぱい。
08/05/08 11:59:23
TCPにしたいだけなら、NFSv3のTCPにすればいいじゃないか。
404:397
08/05/08 13:06:30
>>403
できれば idmap も使いたく・・
405:名無しさん＠お腹いっぱい。
08/05/08 13:12:41
uid振り直して統一しておけばいい。
406:名無しさん＠お腹いっぱい。
08/05/08 13:19:01
Googleもいいけど、そこまでログ追ったならソースコード見た方が早いよ
407:名無しさん＠お腹いっぱい。
08/05/09 17:45:30
サーバをSolarisに変えろ! > NFSv4
408:名無しさん＠お腹いっぱい。
08/05/10 04:31:26
>>397
NFSv4 で認証した時のプロセスID が変わってたらそれが原因の一つでは？
任意の時間で、チェックしてアクティブに umount してからマウントしな
おすと何事もなかったように見えるのではないでしょうか。
409:名無しさん＠お腹いっぱい。
08/05/11 14:29:05
>>407みたいなこという人ってどこまで本気なんだろう？
410:名無しさん＠お腹いっぱい。
08/05/12 18:17:58
まじ
411:名無しさん＠お腹いっぱい。
08/05/13 15:31:21
LinuxでNFSサーバとかどこまでマジなの? という切り口もあるので
どっちもどっち。立ち位置の違いに過ぎない。
412:名無しさん＠お腹いっぱい。
08/05/13 16:10:19
NECと富士通の独自NFSサーバはLinux製。
ただしNFSモジュールは別途開発したものに差し替えてる。
413:名無しさん＠お腹いっぱい。
08/05/15 00:31:40
nfs mount 時の rsize, wsize ですが、これを指定しない場合は
いくらになるんでしょうか？
414:名無しさん＠お腹いっぱい。
08/05/15 07:00:16
>>413
指定しなければデフォルトの値になります。
指定しなかったからといって決して 0にはなりませんので、ご安心ください。
415:名無しさん＠お腹いっぱい。
08/05/15 08:55:59
>>414
あほか。wsize/rsizeをいじりたくなったらデフォルト値を知る必要があるだろ。
>>413
OS（とそのバージョン）による。
FreeBSDなら/usr/include/nfsclient/nfs.hにNFS_WSIZE,NFS_RSIZEで定義されてる。
他は知らん。
416:名無しさん＠お腹いっぱい。
08/05/15 09:27:37
>>414
Linuxなら、mountコマンドを引数なしで実行したら表示されるだろｗｗ
一般ユーザーでも可能。
417:名無しさん＠お腹いっぱい。
08/05/15 09:34:42
>>415
ソースを見るんじゃなくて、稼働中のカーネルで実際にマウントされている時の
wsize/rsizeはわからないんですか?
418:名無しさん＠お腹いっぱい。
08/05/15 12:28:33
Solarisならman mount_nfsに書いてある。
419:名無しさん＠お腹いっぱい。
08/05/15 12:34:17
>>418
それだと、mount後に「現在の」rsize,wsizeを知ることができないじゃん。
420:名無しさん＠お腹いっぱい。
08/05/15 13:16:50
もうさ、tcpdumpでNFS WRITEのサイズ見ればいいじゃん
421:名無しさん＠お腹いっぱい。
08/05/15 14:50:09
>>418
デフォルト値がわかるからいいじゃんか。
422:名無しさん＠お腹いっぱい。
08/05/15 16:00:17
>>418
Solaris なら nfsstat -m でずらっと出てくるお
423:名無しさん＠お腹いっぱい。
08/05/15 16:28:26
Linuxでも nfsstat -m で rsize/wsize 他のパラメータもわかる。
manの情報は実際のカーネルとは合ってないことがあるし、
やっぱり現物で確認する方法がいいよね。
424:名無しさん＠お腹いっぱい。
08/05/15 21:08:45
その知見は現物でしか使えないけどね。
425:名無しさん＠お腹いっぱい。
08/05/16 16:38:33
mountコマンドが、
コマンドラインオプションで指定されなかったnfs mountオプションを、
mount(2)に渡す時に、
・0にしてkernelに任せる
・具体的な規定値を設定する
と二種類あるから気をつけて。
426:名無しさん＠お腹いっぱい。
08/05/20 07:44:06
server1 --- server2 -- cilent
server1は指定のディレクトリをNFSで公開します。
server2はserver1のディレクトリをマウントし、NFSで公開します
clientはserver2のディレクトリをマウントします
これはできる？
427:名無しさん＠お腹いっぱい。
08/05/20 07:58:47
>>426
Linuxなら可能。一般には不可能。
428:名無しさん＠お腹いっぱい。
08/05/20 08:33:56
>>427に追加
server2がLinuxなら～
429:名無しさん＠お腹いっぱい。
08/05/21 12:53:23
>>426
ちなみにserver2でsmbでマウントしたディレクトリを公開したら
書き込みできなかった
430:名無しさん＠お腹いっぱい。
08/05/22 00:34:19
>>420
便乗質問
NFS WRITE のサイズって、具体的にどこを見ればいいの？
431:名無しさん＠お腹いっぱい。
08/05/22 01:40:19
汎用性あるかしらんが、Linuxなら、
/proc/mount
NFS-SERVER:/home /home nfs rw,v3,rsize=32768,wsize=32768
432:名無しさん＠お腹いっぱい。
08/05/22 06:31:01
>>431
/proc/mounts だな
433:名無しさん＠お腹いっぱい。
08/06/30 10:19:33
マシンA,B,Cがあったとして
AからBへnfsマウントして、さらに
BからCへnfsマウントできますか？
つまりCからAのディスクをnfsを２回中継してマウントしたいです。
434:名無しさん＠お腹いっぱい。
08/06/30 11:26:07
>>433
>>427
435:名無しさん＠お腹いっぱい。
08/06/30 11:32:13
Linuxでもできない実装なかったっけ
436:名無しさん＠お腹いっぱい。
08/06/30 11:41:00
knfsdは不可
unfsdは可
437:名無しさん＠お腹いっぱい。
08/06/30 12:01:58
いまどきunfsdなんて使われてないから、結局Linuxでも不可ってこと?
438:名無しさん＠お腹いっぱい。
08/06/30 12:10:00
あえてunfsd使えば可ってこと
439:名無しさん＠お腹いっぱい。
08/07/09 14:56:06
MACOSXServer10.4のフォルダをエクスポートして、Solaris9でNFSマウントする。
その環境で、Solaris9上でMacのフォルダの容量を取得したい。
そこで質問＞＞
Solaris9上でNFSマウントしたMacのフォルダをdu -skの値と、
Mac上でdu -skの値に差がある。
Solaris9：2676
Mac：892
NFSマウント方法や、他に容量の取得する方法があれば教えてほしい。
お願いします。
440:名無しさん＠お腹いっぱい。
08/07/09 15:28:30
>>439
つ du -sB 1 filename
441:名無しさん＠お腹いっぱい。
08/07/14 05:04:45
>216 >218 と同じことやってた。
NFS でマウントしたディレクトリ以下で、
mkdir した場合は、強制的に permission 775 に
するようにできないのかな。
exports しているディレクトリは 2775 にセットしているから、
直下に 755 なファイルを作られても、group ユーザは消せる
けど、directory を 755 で掘らて、その下に 755 なファイルや
ディレクトリを作られると、消せなくて不便。
anonymous にすると、group で共有ディレクトリを制御
できないし。
442:名無しさん＠お腹いっぱい。
08/07/14 06:43:05
>>441
クライアント側で mountする時に、-o grpid オプションを付ければ、
ディレクトリのgidはサブディレクトリに伝播するよ。
443:名無しさん＠お腹いっぱい。
08/07/14 23:59:16
ありがと。ただ、それは、export 元で permission
を 2775 の 2 (setgid) を立てておくのと同じです。
結局、 全員に permission 775 (umask 002) 以外に
設定することを禁止し、その代わり /usr/home 用に、
uid ごとの個別のgid を用意して、運用することにしました。
NFS をグループ別に共有することができるようになったけど、
なんか、車輪の再生産をした気分。
444:名無しさん＠お腹いっぱい。
08/07/15 11:32:01
君は何も生産してないよ。
445:名無しさん＠お腹いっぱい。
08/07/21 14:23:42
ちょいと質問。すべて同じOS・同じバージョンです。具体的にはCentOS5.1のx64版。
NFSで/usr/localを共有するのと、/usrを共有するのってどちらの方が運用上賢いでしょうか？
yum upgradeとかしたときに全てのサーバマシンに影響するのかな。
446:名無しさん＠お腹いっぱい。
08/07/21 19:54:13
CentOSとやらがどこまでNFS共有を想定しているのか知らんが、
NFSで/usrを共有すると、たとえばNFSサーバ上で何かパッケージをインストール
したとき、NFSクライアント側は、/usrが更新されて/varが更新されていないという
不整合な状態になると思われ。
パッケージシステムを使うなら、複数ホストのパッケージ管理を1操作で
できるようにするのが筋ではないかと。
447:名無しさん＠お腹いっぱい。
08/07/21 19:58:22
/usr/localが吉
448:名無しさん＠お腹いっぱい。
08/07/21 20:30:09
>>445
system-config-netbootで全部
449:名無しさん＠お腹いっぱい。
08/07/21 23:36:11
>>447
そんなの初耳なんだが
450:名無しさん＠お腹いっぱい。
08/07/22 07:24:50
>>446
NFS 鯖と心中という障害ポイントを作る以上のメリットがない。
そんな程度なら定期的に rsync とかで同期した方が安定かつ高速。
451:名無しさん＠お腹いっぱい。
08/07/22 08:16:30
>450
定期的にrsync、というのはどの程度の間隔が良いのでしょうか？
ていうか、障害ポイントを発生させたとしても、管理ポイントが共有によりひとつに
まとまるNFSの方が楽じゃない？ NFS鯖を極力落ちないよう準備しておけばいいだけだし。
あくまで確率論だとは思いますが。
452:名無しさん＠お腹いっぱい。
08/07/22 08:23:43
>>446は読んだんか?
パッケージ管理の整合性という本質的な問題が理解できてないように思うが?
453:名無しさん＠お腹いっぱい。
08/07/23 09:13:30
どんなに暗くても、明けない夜はない。
NFSサーバだってきっと落ちるさ。
454:名無しさん＠お腹いっぱい。
08/07/23 14:40:53
>>451
マスターサーバを更新したときに手動で実行するとか、
もしくはクライアントがマスターサーバに何らかの方法で問い合わせて、
更新フラグが立ってたら同期するとかね。
455:名無しさん＠お腹いっぱい。
08/07/23 17:53:21
/varも共有してしまえばOK。
456:名無しさん＠お腹いっぱい。
08/07/23 18:04:07
/var共有ということは、ほかにも/etcも共有するのですね、わかります
457:名無しさん＠お腹いっぱい。
08/07/23 18:17:14
素直にディスクレスクライアントにしてしまえ。
458:名無しさん＠お腹いっぱい。
08/07/23 18:28:45
ディスクレスクライアントにしてるよ。
パッケージアップデートとか、
NFS鯖上で各クライアントディレクトリにchrootしてやってる。
クライアントPCが電源OFFでも、NFS鯖上だけでアップデートできるので管理すごく楽。
459:名無しさん＠お腹いっぱい。
08/07/23 18:43:02
>>458
クライアントごとにインスタンス作ってるの？
すごく無駄な気が...
460:名無しさん＠お腹いっぱい。
08/07/23 18:48:04
>>459
クライアントごとにあるのは / (/var /etc /sbin等)のみ。
/usrは共有してる。共有後にパッケージ管理もしてる。
あ、/sbinのバイナリは個別にハードリンク共有してる。
461:名無しさん＠お腹いっぱい。
08/08/07 14:41:19
賢い人はyumを使うような環境で/usrをmountしたりはしない
462:名無しさん＠お腹いっぱい。
08/08/07 23:56:53
aufs+NFSで/ごとマウントしてマウント先で個別にyumしてもいいし、
逆にyumは一切しないで元ツリー側でのyumに任せる運用をしてもいいぞ。
463:名無しさん＠お腹いっぱい。
08/08/13 08:19:45
CentOS5.2入れて、mount -t nfs したんだけど
flock()使ってるPerlのCGI動かすと1分くらい無反応になって終了しちゃう
ファイルロックかからなくていいから、flock使っても無視するmount方法ってないかな?
ちょっと前のLinuxだと、ふつーにmountしてflockつかっても問題ないんだけど
464:名無しさん＠お腹いっぱい。
08/08/13 08:43:04
>>463
mount -o nolock
465:名無しさん＠お腹いっぱい。
08/08/13 11:17:26
>>463
ちょっと前っていつ頃？
466:名無しさん＠お腹いっぱい。
08/08/13 11:38:34
おれが夕焼けだったころ
467:名無しさん＠お腹いっぱい。
08/08/13 13:00:34
a)flockが動かないのに、なぜ動かないのか調べない
b)ファイルロックかからなくていい
c)スクリプトの方を書き換えようとしない
d)デフォルトでNFSマウントされたディレクトリでflockしようとする
いずれも俺には理解できない発想の集合体だ。
a)システムが正常に動いてないんだから、まずどこが異常なのか調べてくれ。
statdとかlockdとか動いてないんじゃないのか。他のアプリケーションの動作にも
支障があるだろう。
b)競合すればデータが壊れる。同時実行しないという仮定でCGI運用したって
必ずいつかどこかで隙を突かれる。
c)なんのためのスクリプト言語なんだ
d)たとえhomeとかNFSマウントしてても、CGIを実行するホストが単一なら
/varのようなローカルマウントしてるディレクトリ上のファイルに対する
ロックで排他するのが筋。
468:名無しさん＠お腹いっぱい。
08/08/13 14:12:26
cとdは連鯖なら普通だろ。
aはNFS鯖がFreeBSDとかじゃねーの？
469:名無しさん＠お腹いっぱい。
08/08/13 14:23:57
>>468
> cとdは連鯖なら普通だろ。
動かない規定scriptがあるレンタルサーバが普通なのか?
> aはNFS鯖がFreeBSDとかじゃねーの？
（ ﾟдﾟ）ﾎﾟｶｰﾝ
470:名無しさん＠お腹いっぱい。
08/08/13 14:30:07
>>469
おまいさんは客のスクリプトを勝手に書き換えるのか？
>（ ﾟдﾟ）ﾎﾟｶｰﾝ
このすれを>>1から読んでこい
471:名無しさん＠お腹いっぱい。
08/08/13 14:43:34
質問に回答して、解決すればそれでいいんだよ。
質問主からの結果報告がないようだけど。
>>464 の回答で解決でしょ。
472:名無しさん＠お腹いっぱい。
08/08/13 16:08:43
「苦しいんです。いっそ殺して楽にしてください」って患者に言われて、 言われるままに青酸カリを処方する医者は薮なんだぜ。
473:名無しさん＠お腹いっぱい。
08/08/13 16:15:24
たとえになってない。
ハイ次。
474:名無しさん＠お腹いっぱい。
08/08/13 16:19:56
>>472
Linuxの -o nolock オプション付でmountした場合、
rpc.lockd経由の異ホスト間のロックがかからなくなるだけで、
同一ホスト上だと、(たとえロック対象ファイルがNFS上でも)ちゃんとlockがかかるよ。
なので、-o nolock が質問者に対する適切な回答と思われる。
475:名無しさん＠お腹いっぱい。
08/08/13 17:08:08
「まず壊れているものを直す」これが問題解決の原則。
この場合、壊れているのはロック要求に応えないNFSサーバであり、
ロックの必要がないのに獲得しようとしているスクリプトだ。
-o nolockは逆に、壊れていないNFSクライアントを壊してしまう。
(ネットワークワイドでのlockを無効にし、アプリケーションにエラーも返さない)。
そのサイトで動作するアプリケーション全体に影響が及ぶことを考えれば、
他で対処できないときの次善の策と考えた方がよい。