【NFS】Network File System

**名無しさん＠お腹いっぱい。** · 2006/03/28(火) 11:42:41

nfsに関する話題を扱うスレ

**名無しさん＠お腹いっぱい。** · 2006/03/28(火) 11:53:37

　 /'　　　　　　　　　　!　　　━━┓┃┃
-‐'―ニ二二二二ニ＞ヽ､　　　　┃　　　━━━━━━━━
ァ　　 /,,ｨ=-;;,,, , ,,＿　ト-､）　　 ┃　　　　　　　　　　　　　　　┃┃┃
'　　 Y　　ｰ==j 〈,,二,ﾞ !　　)　　　　｡　　　　　　　　　　　　　　　　　　┛
ゝ.　 {､　　-　,.　ヾ "^ }　　}　ﾟ　｡
　　　）　　,. ‘-,,'　　　≦　三
ゞ,　∧ヾ　ゝ'ﾟ　　　　　　　≦　三　ﾟ｡　ﾟ
'=-/　ヽﾟ｡≧　　　　　　　　　三　＝=-
/　|ヽ　＼-ｧ,　　　　　　　　　　≧=-　。
　　!　＼　　ｲﾚ,､　　　　　　　　　＞三　　｡ﾟ　･　ﾟ
　　|　　＞≦｀Vヾ　　　　　　　　ヾ　≧
　　〉　,く　｡ﾟ　/｡･ｲﾊ､､　　　　　｀ミ　｡ﾟ　｡･

**名無しさん＠お腹いっぱい。** · 2006/03/28(火) 16:30:12

nfsの利用は危険です。

**名無しさん＠お腹いっぱい。** · 2006/03/28(火) 20:44:11

玄箱をNFSサーバとして使ってる。

**名無しさん＠お腹いっぱい。** · 2006/03/30(木) 16:55:01

NFSで接続したディレクトリをsambaで公開することはできないのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/03/30(木) 16:58:35

OSによるんじゃね

**名無しさん＠お腹いっぱい。** · 2006/03/30(木) 17:18:29

NFSマウントしたディレクトリをSambaで公開することなら、
OS関係なしにできる。
同じNFSディレクトリを、複数のホストでSamba公開すると
ファイルのロックが問題になるので、その点だけ注意すればいいだけ。

**名無しさん＠お腹いっぱい。** · 2006/04/02(日) 17:42:54

nfsdのCPU使用率が異常に高いのですが、考えられる原因を教えてください

**名無しさん＠お腹いっぱい。** · 2006/04/03(月) 00:49:53

マシンのスペックがしょぼい。

**名無しさん＠お腹いっぱい。** · 2006/04/03(月) 16:24:43

NFSﾏﾝｾｰ

**名無しさん＠お腹いっぱい。** · 2006/04/23(日) 16:17:54

mount -t nfs 192.168.0.18:/usr/pkgsrc /usr/pkgsrc
とやったら
mount_nfs: rpcbind to nfs on server: RPC: Port mapper failure - RPC: Timed out
といわれるんですけど、何が原因かわかりますかね？

サーバ側のexportsには
/usr/pkgsrc -maproot=root:wheel 192.168.0.0/24
を記述しています

**名無しさん＠お腹いっぱい。** · 2006/04/23(日) 16:20:50

>>11
それは、NFS鯖でportmapまたはrpcbindが起動していない時の症状。

rpcinfo -p 192.168.0.18
の結果貼ってみろ。

11 · 2006/04/23(日) 16:27:34

>>12
ありがとうございます
rpcinfo -p 192.168.0.18
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
になります。

すいませんがよろしくお願いいたします

11 · 2006/04/23(日) 16:45:31

うぅーーむ・・。
mountd
rpcbind
nfsd -tun 4
を起動しなおしたら

mount -t nfs 192.168.0.18:/usr/pkgsrc /usr/pkgsrc
mount_nfs: can't access /usr/pkgsrc: Permission denied
こうなりました・・。
どこのパーミッションを直したらいいんですかね・・・。 orz

**名無しさん＠お腹いっぱい。** · 2006/04/23(日) 17:21:16

貼れっていったんだから最後まで面倒見てやれよ

**名無しさん＠お腹いっぱい。** · 2006/04/23(日) 18:00:54

>>14
rpcbindの問題は解決したようだね。

次の問題としては、NFS鯖側から見て、クライアントのIPアドレスが
逆引き出来てなくてPermission deniedになってる可能性がある。

あと、クライアントのOSにもよるが、
ソースポートがroot特権ポート以外からのmount要求になってる場合は、
NFS鯖側でinsecureまたはmountdに-nオプションとか、OSによって違うが
そういう設定が必要。

**名無しさん＠お腹いっぱい。** · 2006/04/29(土) 15:57:08

>>14
LinuxでNFSやっているかも？と仮定してちょっとフォロー

１．NFS鯖でexportfs -a を行っているかチェック。
２．シンボリックリンクが存在し、リンク先が/etc/exports に記述されていない。

**名無しさん＠お腹いっぱい。** · 2006/04/29(土) 16:26:47

>>17
>>14 ではrpcbindって言ってるからLinuxじゃないね。(Linuxはportmap)

**名無しさん＠お腹いっぱい。** · 2006/04/29(土) 17:40:19

一般に、返事がない場合はすでに解決済みとみなして良い。
何日も前の、しかも不備な質問に、わざわざエスパーして回答してやるこたぁない。

**名無しさん＠お腹いっぱい。** · 2006/05/05(金) 15:43:58

NFSのshareオプションでanon=0と言う物がありますがroot=ホスト名との違いが今一つ
分かりません。
と言うのは、匿名ユーザからのNFSマウントと言う場面を実機で作り事が出来ないで
いるからです。UNIX機では、どんなUIDを用いても匿名ユーザ扱いされないように見え
ます。
anon=0を使用した場合、匿名ユーザからroot権限でmountするにはどの様にすれば良い
のでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/05/05(金) 18:20:28

>>20
それ、完全に勘違いしてるね。
NFSでは、セキュリティ上、rootで直接マウントできないように、
rootのNFSクライアントを匿名ユーザに置き換える。
で、この置換えを辞めてrootのままマウントさせるオプションが、
anon=0(匿名ユーザのUIDを0にするという意味)や
root=ホスト名、なわけ、root=ホスト名、の方が、
特定のホストにのみ許可できるから安全。

で、質問の、「匿名ユーザからroot権限でmountするには」
ということは普通はできない。UIDをマップするようなオプションを使えば
できるOSもあるが、一般的ではないし、そもそもそういうことをするのは危険。

**名無しさん＠お腹いっぱい。** · 2006/05/05(金) 18:55:22

>>21
anon=0,rw=ホスト名とroot=ホスト名はセキュリティ上、等価と考えて良いのですか？

**名無しさん＠お腹いっぱい。** · 2006/05/05(金) 19:36:50

>>22
なんでやねん。

**名無しさん＠お腹いっぱい。** · 2006/05/05(金) 20:41:35

>root=ホスト名、の方が、特定のホストにのみ許可できるから安全
anon=0でも、アクセス可能なホストを制限すればセキュリティ的に等価になるかなと
思ったのですが。
気になっているのはroot=ホスト名ではなく、anon=0を使用した場合のセキュリティ上の
リスクなんです。

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 22:11:03

NFSv4 って使ってる人いる？　もしいたら、OS とかストレージ名とか
使用感とか漠然とだけど聞きたいな。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 13:57:02

すんません、NFSのファイルのロックに関して教えてください。

サーバーがexportしている１つのディレクトリに対して、
２台のnfsクライアント（A,B）がマウントしています。
その２台のマシンから、exportされているディレクトリ以下にある、
ファイルに対してflockをかけるのですが、
Aでflockをした後、Bでもflockできてしまいます。

NFSで１つのファイルに対する排他制御って、flockでは
できないのでしょうか？それとも、NFSの設定がおかしいのでしょうか？

よろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 14:10:38

>>26
NFSv3以前では無理と思うべき。NLMとかlockdとかあるけど、
あんなもんじゃ複数クライアントからのまともなロックはできん。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 14:15:18

>>26
NFSのロックはflock()じゃできない。
lockf()を使うこと。（またはfcntl()）
常識中の常識。

あと、動いてるとは思うけど、lockf()が動作するには
(rpc.)lockdと、(rpc.)statd相当のデーモンが必要。
詳細はOSによって多少違うが。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 14:50:33

fcntlでも複数クライアントはできないんじゃない？

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 15:07:01

>>29
lockf()は実はフロントエンドであって、
内部でfcntl()を呼んでるわけだが。
lockf()の関数は互換性のため残ってるだけ。

なので、fcntl()で当然排他制御ができる。
なお、NFSはv2であってもOKだよ。

29 · 2006/08/07(月) 15:37:30

>>30
ん？　なんか論点が食い違っているような・・・
flock, lockf, fcntlとNFSの関係に関しては漏れも理解しているつもり。

fcntlを使えばロックができることも知っているし、経験的にもそれが
出来てはいるんだけど、ただ、複数のクライアントのときにうまく
行かなかったのよね。サーバとクライアントが仕様通りの実装に
なっていれば、ちゃんとfcntlでロックできるもんなの？
２台のクライアントからすさまじく高速にロックルーチンを回す試験を
してて、たまにファイルがぶっ壊れてましたけどｗ

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 15:52:53

皆様レスありがとう。

>>30
了解です。
で、fcntlでロックをしようとすると、今度は
「No locks available」のエラーになっちゃう・・・
ローカルディレクトリで、同じプログラムを動作させると、
ちゃんとロックするんですが。
教えてくんですみませんが、原因などご存知でしたら教えてください。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 16:09:28

>>32
>>28 が書いてるとおり、lockd statdを起動していないからだと思われ。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 18:19:04

>>33
rpc.statdと、lockdはクライアント側、サーバー側で、
rpcinfo -p
で、statusとnlockmgrもいます。
クライアント側から、rpcinfo　-p サーバーIPで、
サーバー側も見れます。

なにか設定がおかしいんでしょうかね・・・？

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 18:49:45

>>34
fcntl()の、引数指定間違えてない?
一度 lockf()使って呼んでみれ。

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 18:59:09

"No locks available"って、errnoに ENOLCKがセットされた時のエラーで、
ロックが多過ぎてロックテーブルがオーバーフローした状態なわけだが。
テストプログラム起動し過ぎてるとかない?

**名無しさん＠お腹いっぱい。** · 2006/08/07(月) 19:29:22

皆様、何度もご協力ありがとうございます。
>>35
実は、もともとの問題は、PHPのセッションファイルは、NFSマウントしたディレクトリに置いて、Load balancer配下のサーバーで
共有できるか？というところだったりします。んで、PHP4のセッションファイルを作成しているところのｌソースを参照して、
そのロックの手法を抜き出して、そのままテストプログラムにしてます。
テストプログラムは以下のような感じで、
呼び出し側は、php_flock(fp, LOCK_EX)で、
関数は↓
int php_flock(int fd, int operation) {
　　struct flock flck;
　　int ret;
　　flck.l_start = flck.l_len = 0;
　　flck.l_whence = SEEK_SET;
　　if (operation & LOCK_SH)
　　　　flck.l_type = F_RDLCK;
　　else if (operation & LOCK_EX)
　　　　flck.l_type = F_WRLCK;
　　else if (operation & LOCK_UN)
　　　　flck.l_type = F_UNLCK;
　　else {
　　　　errno = EINVAL;
　　　　return -1;
　　}
　　ret = fcntl(fd, operation & LOCK_NB ? F_SETLK : F_SETLKW, &flck);
・・・・
}
です。
>>36
テストプログラムは、数多く起動はしていないです。テストプログラムをコンパイルした、
a.outを手動で起動しているだけなので。

**名無しさん＠お腹いっぱい。** · 2006/08/08(火) 11:43:37

lockd/statdが使用してる(RPC登録してる)ポートを
ファイアーウォールとかで閉じてるんじゃない?
ポート番号は変化するので大変だけど。
rpcinfo -pだと、111ポートだけが開いてればstatus/nlockmgrが
表示されるけど、それだけだと確認にならない。

**名無しさん＠お腹いっぱい。** · 2006/08/19(土) 12:20:18

最近出来たスレなんですね。
お詳しい方がいらっしゃるので、私もこれから勉強していきたいと思います。

私はあまりNFSに詳しくないのですが、
以前からNFSROOT好きです。

Solaris/x86をNFSROOT化したり、
「Fedora Core Linux ディスクレス化キット」を開発したりしています。

昨日ホームページを開設しまして、「Fedora Core Linux ディスクレス化キット」
を公開しました。
http://wikiwiki.jp/disklessfun/?disklessfc
Fedora Core をカーネルリコンパイルせずにNFSROOT化するキットです。

また、http://dl-x86solaris.sourceforge.jp/では
Solaris/x86をNFSROOTでインストールしたり運用するキットを開発・公開しています。

非常にマイナーな世界の話ですが、もし興味があればいらして下さい。

**名無しさん＠お腹いっぱい。** · 2006/08/19(土) 15:38:47

>>39 GJ　あとで見ておく。

**名無しさん＠お腹いっぱい。** · 2006/08/20(日) 09:00:25

>>37
セッション管理をmysqlとかDBで行う様にした方が良いんじゃない？
確かPHPにそういう仕組みを実現する何かがあったと思うんだが。
外してたらゴメン。

**名無しさん＠お腹いっぱい。** · 2006/08/21(月) 02:00:54

>>25
遅レスだけど使ってるよ
鯖、蔵ともにFedora Rawhide、ハードは普通のPCだけど？

**名無しさん＠お腹いっぱい。** · 2006/10/09(月) 00:29:14

nfs4のidmapdで、uidの異なるマシン間でuidをマップする方法をご存じの方、教えていただけませんか?

**名無しさん＠お腹いっぱい。** · 2006/10/22(日) 22:29:03

今、NFSが一番安心して使えるOSはどれですか?

**名無しさん＠お腹いっぱい。** · 2006/10/22(日) 22:47:20

Solaris.

**名無しさん＠お腹いっぱい。** · 2006/10/23(月) 22:26:41

サーバーとクライアントを同じプラットフォームで統一して、
サーバー・クライアント間にFirewallを設置せず、
ハードウェア障害のケースを想定しないで
NFSv3を使うことにすれば、

何のOSでもたいていOK、多分ね

全部逆と想定したら、まず神頼みが必要かも

**名無しさん＠お腹いっぱい。** · 2006/10/23(月) 23:11:29

>>46
>何のOSでもたいていOK
ダウト。
FreeBSDでは未だにクライアント間でのNFSロックが効かない。

**名無しさん＠お腹いっぱい。** · 2006/10/25(水) 03:31:38

>>43
標準はnsswitchで決められて、あとはnisだとかldapだとかにid管理任せればいいんじゃないの?
http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html

うちはnfs4でもマシン数台なんで手動管理。。。

**名無しさん＠お腹いっぱい。** · 2006/10/25(水) 17:47:17

>>47
> FreeBSDでは未だにクライアント間でのNFSロックが効かない。

本当？

**名無しさん＠お腹いっぱい。** · 2006/10/25(水) 17:57:32

Yes

**名無しさん＠お腹いっぱい。** · 2006/10/28(土) 00:34:22

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

でも？

**名無しさん＠お腹いっぱい。** · 2006/10/28(土) 11:33:21

>>51
FreeBSD の rpc.lockdは動作がおかしい。
FreeBSD自身の lockf()は、flock()として動作してるｗ

よって、全然駄目駄目。

試しに、複数のFreeBSDクライアントから lock書ける実験をしてみるといい。
lock無視してファイル壊すから。

**名無しさん＠お腹いっぱい。** · 2006/10/28(土) 12:32:21

今年の5月か6月あたりに直ったんじゃなかったっけ。

**名無しさん＠お腹いっぱい。** · 2006/10/28(土) 13:18:50

>>53
rpc.lockdの件はともかく、
flock/lockfの件も直ったの?
直ったかどうかというより、これってFreeBSDの仕様の問題だから、
今までflockの動作をしていたのを急にlockfの動作にすると
別の部分で不具合が出るから、直しようがないと思うんだが、、

**名無しさん＠お腹いっぱい。** · 2006/11/10(金) 14:32:56

>>54
いつの時代の話？
lockf(3) は内部で fcntl(2) を呼ぶようになっていますが。flock(2) ではなく。

**名無しさん＠お腹いっぱい。** · 2006/11/12(日) 15:53:18

NFS over SSHのやり方を教えてください。

**名無しさん＠お腹いっぱい。** · 2006/11/12(日) 16:49:44

http://www.google.com/search?num=50&hl=ja&q=%22NFS%26%23160%3Bover%26%23160%3BSSH%22

**名無しさん＠お腹いっぱい。** · 2006/11/12(日) 22:45:01

結局ステートレスじゃないNFSに替わるネットワークを透過的に使えるファイルシステムなんてものは無いということなのか？

**名無しさん＠お腹いっぱい。** · 2006/11/12(日) 22:58:16

つ SMB

**名無しさん＠お腹いっぱい。** · 2006/11/13(月) 09:37:56

mjsk

**名無しさん＠お腹いっぱい。** · 2006/11/17(金) 15:36:58

NFSv4の立場は・・・・・・

**名無しさん＠お腹いっぱい。** · 2006/11/17(金) 16:18:12

FreeBSDの NFSv4対応はいつになりますか? Linuxでさえ対応してるのに、、

**名無しさん＠お腹いっぱい。** · 2006/11/17(金) 19:02:55

NFSって遠隔地、例えば東京大阪間のようなものでもグローバルIPさえあればつなぐことができるのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/11/17(金) 19:05:16

電子メールって遠隔地、例えば東京大阪間のようなものでもグローバルIPさえあれば送ることができるのでしょうか？

と聞いてるのと同じ。

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 01:13:20

同じかなー

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 04:22:47

なんか怖いな

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 05:58:43

20世紀の頃、某ISPのWebサーバの
ユーザ領域をNFSマウントしちゃえたことあるよ
28.8bpsで

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 06:04:12

電子メールによる比喩はちがう気がする
遠隔地でも出来るできないで言えば出来る
実使用上のいろいろな問題があるだろうけど

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 09:12:09

素の TCPでの接続か、RPCでポート番号が一定しない接続かの違いがあるだけで
IPレベルでは同じ事。NFSはポート番号が変わるため、ファイアーウォールで
NFSだけをうまく許可する方法が難しいという点は確かに違うが、、

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 09:17:21

いやほら電子メールならUUCPとかでも送れたりするじゃん？

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 09:27:39

そういうことか。じゃあ FTPでたとえた方がいいのかな。

**名無しさん＠お腹いっぱい。** · 2006/11/18(土) 10:19:58

RPCだって、本来はTCP/IP以外のプロトコルスタック上にも実装できるように
設計されたものなんだが、、実際はTCP/IP版以外は使われていないけど、、

**名無しさん＠お腹いっぱい。** · 2006/11/19(日) 23:19:20

>>67
めちゃくちゃ遅いじゃん。TCPパケットヘッダ送るだけで
2秒以上掛かるのか。

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 14:43:05

NFSのベンチ結果やlinux iSCSI Targetとの比較結果をまとめているサイトってありませんか？

NFS v4 VS iSCSI

でどっちが早いのか・・・

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 22:03:41

比較にならないものを比較しようとしてませんか？
私の勘違いでしょうか

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 22:17:01

AoEの圧勝

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 23:07:52

AppleShare over Ethernet?

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 23:33:46

Age of ...

74 · 2006/11/21(火) 23:42:49

>75
難しいかな・・・

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

>76

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

**名無しさん＠お腹いっぱい。** · 2006/11/21(火) 23:46:39

AoEデバイスって国内でどっか買えるの？

**名無しさん＠お腹いっぱい。** · 2006/11/22(水) 00:47:30

>80

金物屋で売ってたよ

**名無しさん＠お腹いっぱい。** · 2006/11/22(水) 00:59:43

「金物屋 AoE」でググった。

鉱床からの金貨収集速度が20%上昇した

**名無しさん＠お腹いっぱい。** · 2006/11/22(水) 21:48:00

「金物屋 AoE」でググった。

「オスマン金物屋使った後、スペイン・オスマン金物屋は使用できない」

**名無しさん＠お腹いっぱい。** · 2006/11/22(水) 22:51:59

誰も売ってないという事は俺がCoraidを輸入して売れば儲かるという事ではないだろうか

**名無しさん＠お腹いっぱい。** · 2006/11/23(木) 14:16:32

>84
ttp://www.coraid.com/products.html
これはいいSupermicroですね。

**名無しさん＠お腹いっぱい。** · 2006/11/23(木) 15:14:20

スーパーマイクロと聞くとSONY NEWSのことが真っ先に頭がよぎるのは私だけ？

**名無しさん＠お腹いっぱい。** · 2006/11/23(木) 18:21:32

社員乙

**名無しさん＠お腹いっぱい。** · 2006/11/29(水) 17:12:39

>>84
黒字になる前に、他の業者が販売し始めて、赤字決済。
いや、是非やってくれ。

**名無しさん＠お腹いっぱい。** · 2006/12/06(水) 14:56:58

>>58 RedHat だけど、GFS なんてどうなんだろうね。興味はあるけど暇がねぇ。

**名無しさん＠お腹いっぱい。** · 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は最近どうなった？

**名無しさん＠お腹いっぱい。** · 2006/12/10(日) 15:26:40

[AからZ]FSの全部が揃ってるという話は聞いたことあるよ。
しかも１９９０年代の時点で。
リストもらっておけばよかったなあ。

91 · 2006/12/10(日) 15:29:04

>>90は実用のものを挙げてあるけど、
>>91の[A-Z]の話は、特定の組織でしか使われないとか
論文になったことがある程度のものだったかも。

**名無しさん＠お腹いっぱい。** · 2006/12/10(日) 16:40:49

pvfs2 とか 9fs とか

**名無しさん＠お腹いっぱい。** · 2006/12/10(日) 18:36:42

afsとかwebfsとか

**名無しさん＠お腹いっぱい。** · 2006/12/27(水) 18:36:41

SFUを使ってNSFをWindowsにマウントしようと思うのですが、何か潜在的な問題はありますか？

**名無しさん＠お腹いっぱい。** · 2006/12/27(水) 23:10:03

National Science Foundation

**名無しさん＠お腹いっぱい。** · 2007/01/16(火) 20:01:18

板違いなのかもしれんが他に見当たらないので>>95に便乗。
SFU3.5でSolaris上のNFSをマウントしているのですが、
DOSコマンドのmkdirで存在しない中間ディレクトリの作成をするとこけてしまいます。
これってクライアント側の問題ですか？

**名無しさん＠お腹いっぱい。** · 2007/03/07(水) 11:19:31

>>97
こけかたを具体的に。

**名無しさん＠お腹いっぱい。** · 2007/03/07(水) 13:33:44

>>97
権限周りを調べるべし

**名無しさんお腹いっぱい** · 2007/03/08(木) 05:34:05

DOSのmkdirはしらないが、solarisならmkdirに -p オプションが必要

**名無しさん＠お腹いっぱい。** · 2007/04/08(日) 13:46:29

超早いNFSサーバ専用機を余らせており、
これをWindowsから使いたいと考えています。
NFSサーバはNFSv2/v3/v4を扱えますが、
とりあえずNFSv2は使わない方向で考えています。

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

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

特定のWindowsユーザだけにNFSサーバを使わせたいのですが、
うまい方法は無いでしょうか?

**名無しさん＠お腹いっぱい。** · 2007/04/08(日) 14:00:41

他の人が使ったら即刻解雇！
っていう社則を作ればＯＫ

**名無しさん＠お腹いっぱい。** · 2007/04/08(日) 17:12:23

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

MACアドレスとIPアドレスの1対1のリストを作ってIPアドレスを配布するか
MACアドレスグループに範囲内のIPアドレスを割り当てる設定にするような感じで
DHCPサーバを弄れば良い

**名無しさん＠お腹いっぱい。** · 2007/04/08(日) 18:14:48

>>103
その手法は確実そうなのですが
DHCPサーバは全く違う部署で管理している上、
在籍者全員に割り当てられるだけのアドレス空間の余裕がありません。
(離席者のIPアドレスを回収するためにリース期間を非常に短くしてある)

SFU使ってNFS/CIFSゲートウェイを立てるしかないんでしょうか...
性能ががた落ちするのは明らかなので、
何か別に巧い方法があればとは思うのですが。

**名無しさん＠お腹いっぱい。** · 2007/04/08(日) 18:25:39

多分IPアドレスに余裕無いだろうなぁと思って2番目のを提案したのですが
DHCPサーバの管理が別部門という条件も出てきた以上、仕方ないですね
性能には目をつぶってそうするしかないでしょう

**101=104** · 2007/04/08(日) 18:59:54

>>105
レスどうもです。
ゲートウェイに使えそうな機材余ってたかな...

CIFSのライセンスキーを購入すれば
こんな妙な事をしなくても済むのですが
3桁万円するので予算が(略

**106** · 2007/04/19(木) 10:24:22

セットアップしようとした矢先、
NFS鯖は他の事業所にドナドナされる事になりました。
少なくとも1.5TBは有ったのに orz

NFS/CIFSゲートウェイの件は機会があれば試してみようと思います。

**名無しさん＠お腹いっぱい。** · 2007/04/21(土) 05:59:15

1.5Tなんて、もうディスクが3台あれば冗長構成で組めるぜ。
たいした容量じゃない

**名無しさん＠お腹いっぱい。** · 2007/07/02(月) 17:15:30

それにクライアントは何台ぶらさがれるのか、という問題があるけど。

**107** · 2007/07/04(水) 10:05:17

使おうとしてたのはNetAppだった。
HDD4台程度のなんちゃってNASとは
比較にならないよ。
速度もだけど、容量単価も別世界w

FC接続の144GB HDDが21台搭載してあった。
冗長性に余裕持たせたり、
システム領域やsnapshot領域の関係で
物理容量の約半分がユーザ容量になる。
なので1.5GBが使える、と。

**名無しさん＠お腹いっぱい。** · 2007/07/04(水) 10:07:49

1.5GB
たいへんですね。業者にもってかれましたか？

**名無しさん＠お腹いっぱい。** · 2007/07/12(木) 00:51:22

昔のNetAppはそれくらいだったような

**110** · 2007/07/15(日) 00:30:53

ああ
単位間違えてたのか
1.5TBね orz

**NFSできない！** · 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

サーバー側の設定は以上で、その後リブートを実施いたしました。

**名無しさん＠お腹いっぱい。** · 2007/08/12(日) 19:11:03

FreeBSDでNFSがマトモに動いたのは4.xまで。それ以降は本気で使ってはいけない。

**NFSできない！** · 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

で確認をとり念の為クライアント側もリブートを行いました。

**NFSできない！** · 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識者の方、是非たすけてください。

**NFSできない！** · 2007/08/12(日) 19:19:15

>>115

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

そんな事情があったんですか。うちのサーバー5.4なんで無理っていう事ですかね。。

**名無しさん＠お腹いっぱい。** · 2007/08/12(日) 19:21:27

とりあえず、
mountd_flags="-n"
してみろ。

**NFSできない！** · 2007/08/12(日) 19:22:43

やってみます！

**NFSできない！** · 2007/08/12(日) 19:28:03

きたーーーーーーーーーーーーーーーーーーーーーー！
すげーーーーーーーーーーーーーーーーーーーー１

ありがとぅううう

**名無しさん＠お腹いっぱい。** · 2007/08/13(月) 12:33:45

>FreeBSDでNFSを実装しようとしているのですが

すげー
コード書き直してくれてるの？
超期待

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 12:08:45

>>115
これ本当？
もう6.2Rくらいまで行ってるんだけど未だに改善されてないの？

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 12:37:43

本当

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 14:44:28

今NFSv4が一番安定して使えるOSって何？

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 14:55:04

Windows

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 15:08:15

>>124-126
この流れを見るととても信用できないなあ
誰も検証してないんだろうか

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 15:20:12

>>127
せっかく回答もらって「信用できない」かよ。
FreeBSD 6.2で NFS鯖運用してみろよ。ドツボにハマルから。
ひとごとだから別に止めないよ。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 15:32:37

>>125
Data ONTAPの7.x系

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 15:44:27

NFSの話は FreeBSDにおいては禁句です。
多くの開発者が NFSと聞いただけで気分を害します。
分別ある大人なら、FreeBSDコミュニティにおいては
NFSの話はそれとなく避けるのがマナーと言うべきものでしょう。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 15:53:44

便所の落書き

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 16:59:31

本家のMLにはNFSがダメダメという投稿がない上に開発者用の
クラスタなど内部で利用されまくってたりする。
ここではNFSダメダメという書き込みがあるけど不具合の詳細
が全然ない。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 17:01:29

たかが2chの書き込みにそこまでの信憑性求めんなよ。
自分で検証すれ。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 17:07:50

>>132
FreeBSD同士のNFSだと問題が発覚しにくいんだよ。
異OS間のNFSでとたんに問題発覚する。
手元で試してみろよ。百聞は一見にしかず。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 17:12:55

まるでLinuxみたいなことを言うなあ

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 17:22:22

>>132
>ここではNFSダメダメという書き込みがあるけど不具合の詳細
>が全然ない。

他スレに不具合の詳細あったよ。探して見れ。

**名無しさん＠お腹いっぱい。** · 2007/09/21(金) 17:31:23

>>134
FUDに必死だな

**名無しさん＠お腹いっぱい。** · 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は鯖/クライアント両側で起動してる)

**名無しさん＠お腹いっぱい。** · 2007/09/27(木) 22:42:48

質問。
nohideなんてオプションがあるのはLinux(IRIX由来とmanに書いてあったか)だけ？
最近Solaris使い始めて使えるオプションが意外と少ないことに気付いた

**名無しさん＠お腹いっぱい。** · 2007/09/29(土) 00:40:41

>>138
> マウントされたファイルシステム内で(アプリケーションが)lockfしようとすると

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

つか, 今時, lockf とか flock なんて野蛮な排他制御を使ってんのかよ?

**名無しさん＠お腹いっぱい。** · 2007/10/18(木) 18:52:12

NFS mountしたファイルシステムでlockfするアプリケーションを動かすのは、運用が間違っとるよ。
FreeBSDに限らず、Solaris等含めて。

**名無しさん＠お腹いっぱい。** · 2007/10/18(木) 21:56:38

>>141
SolarisではNFS上のlockfは全く平気。
すべてのファイルシステムがNFSであるディスクレスクライアントを実現するため、
lockfを含め、NFSもローカルディスクも全く同じように扱えるというのが
大前提としてあるわけだ。

**名無しさん＠お腹いっぱい。** · 2007/10/19(金) 10:59:03

lockfの話は抜きにしても、

2つのNFSクライアントから同時に mkdir(2)またはsymlink(2)した時、
両方のクライアントが成功(戻り値=0)になってしまう事はないのかな?

**名無しさん＠お腹いっぱい。** · 2007/10/21(日) 20:06:01

そういう等羃でない操作はやらないのがNFSのココロ。

**名無しさん＠お腹いっぱい。** · 2007/10/22(月) 13:17:18

NFS上のmkdirやsymlinkが排他的に実行できることは、SolarisやLinuxでは保証されてる。
FreeBSDではコケるのかも知れんが。

**名無しさん＠お腹いっぱい。** · 2007/10/22(月) 15:37:09

一方的に信頼するのは自由だが、OSとプロトコルの方は「保証」などしとらんと思うがな。

RFC1813(RFC3530でもいいが)のCREATEの所を読んでみてくれ。

**名無しさん＠お腹いっぱい。** · 2007/10/22(月) 18:01:54

複数のホストがからむ話だから、誰が誰に対してどういうレベルで保証しているのかを
明確にしないと議論できないな。

**名無しさん＠お腹いっぱい。** · 2007/10/23(火) 11:01:42

symlinkとかアホくさいことしなくても、
シングルホストなら/varか/tmp以下でlockfすりゃいいじゃん。
マルチホストなら排他制御プロセスいっこ用意すれ。

**名無しさん＠お腹いっぱい。** · 2007/10/23(火) 11:35:04

>>148
lockfが使えるならそれで良い。

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

で、シングルホストの話なんか最初から誰もしてない。
マルチホストだからこそ問題になる点の議論。

**名無しさん＠お腹いっぱい。** · 2007/10/25(木) 10:50:37

NFSを想定したコードばかりとは限らない状況で
NFSを使うことになる、なんて話もあるだろう。
そういうときにハマるかハマらないかの差は大きいと思うんだよなあ。

**名無しさん＠お腹いっぱい。** · 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のコードを走らせて経過を観察する、でいいのかな？

誰かコード書いてくれないかな。

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 07:40:49

>>151
flockはもともと単一ホストでしか使えないのでここでは関係なし。
fcntlの(F_SETLKWなど)は、lockfと同じ(というか、lockfがfcntlを呼び出してる)
ので、lockfのみテストすれば桶。

ほか、lockfを使わずに mkdirや symlink や link がロックとして機能するかどうかの
テストができればいいかな。

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 10:41:18

>lockfがfcntlを呼び出してる
それは実装によって違うだろ

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 13:52:29

>>152
- 誰かがロック中にサーバが落ちた後のリカバリがまともかどうか
- ロックを獲得したままのクライアントが落ちた後のリカバリがまともかどうか
も必要じゃない？
実装が難しくなるのもそのあたりを考えなきゃいけないからだろうし。

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 15:02:09

>>154
それはどういう振る舞いをもって「まとも」と見なせばいいんでしょうか。
前者はサーバの落ち具合一つとっても、単なる回線障害なのか、
サーバ側のファイルシステムに絡む問題なのかで話が変わるだろうし。
後者はロックのタイムアウト処理が適切？か、とかですか？

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 15:33:42

>>149
> その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?

symlinkだのmkdirだのは排他制御の方法としてlockf以上に「お話にならない」。
書類審査で落とされる。

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 15:42:43

>>156
でも、(少なくとも)Solarisだと、symlinkもmkdirもしっかりロックとして
機能するんだよ。

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 15:56:52

FreeBSDはlockfがダメだからNFSが使いものにならない
↓
NFSでlockfなんか使うのは運用が間違ってる(mkdirやsymlinkを使えば良い)(>>by 141)
↓
symlinkだのmkdirだのはお話にならない(by >>156)
↓
FreeBSDではNFSは使えない。

結局こういうことになるじゃんｗ

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 16:02:26

symlinkとかではお話にならないとか言ってる奴は……お話にならないな。
メール関係のデーモンやツールをソースからコンパイルする時に
気づくことすら知らないわけで……

**名無しさん＠お腹いっぱい。** · 2007/10/29(月) 20:47:12

とりあえずポリシーとか仕様とか一切とっぱらいで、
ロックとして使えるもの、使われがちなもの、に対して、
各OSをサーバ、クライアントにしたときの動作相性表を書いてみろ、
ってことか？　横方向クライアントOS、縦方向サーバOSにして、
lockf, flock, fcntl, symlink, mkdir
で表が５枚出来る、と。

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 00:22:59

nfsv4だったらいいんじゃない。

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 01:21:29

>>161
http://pc11.2ch.net/test/read.cgi/unix/1012808941/643-652n

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 01:38:08

あるじゃんNFSv4
snowhite.cis.uoguelph.ca/nfsv4/

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 12:39:49

サーバNetApp, クライアントTurboLinux Fujiという環境で
たまに下記のように .nfs～で始まるファイルが出来ている
事あるのだけど、これはどういうタイミングで出来るのでしょうか？

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

-rw-r--r-- 1 hogehoge admin 2253 10月 10 15:36 .nfs002d56600000001

**名無しさん＠お腹いっぱい。** · 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越しのファイル操作で排他が保証されないことを
前提に、それでも衝突することがないように(排他できなくてもよいように)
工夫して書かれている。

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 13:16:18

>>164
UNIXでは、プロセスが開いているファイルでも削除できる。
そのとき、ファイルはすでに削除され見えないのだが、
オープンしたプロセスだけはファイルにアクセスし続けられる。

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

クライアントが削除を怠ると(=クライアントのOSが落ちると)
.nfsはストレージ上に残されたまま放置される。

**名無しさん＠お腹いっぱい。** · 2007/10/30(火) 13:51:42

>>165　なんでNFSで出来ない排他制御をやりたがるのか。
だってNFSと銘打ってるのにそれが出来てる(ように見える)OSがあるんだもんよー。
FreeBSDで出来ないのは悔しくね？　という話だと思っていた。

**164** · 2007/10/30(火) 19:31:59

>>166
ありがとうございました。

**名無しさん＠お腹いっぱい。** · 2007/10/31(水) 02:24:25

出来ているように見えるだけで
本当に出来ているのかは定かではないｗ

**名無しさん＠お腹いっぱい。** · 2007/10/31(水) 12:47:49

>>165
>逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
>前提に、それでも衝突することがないように(排他できなくてもよいように)
>工夫して書かれている。

えー。
嘘書いちゃ、だめだよ。

**170** · 2007/10/31(水) 12:53:50

ああ、プロトコル上だけで実現できるかどうかの話をしてるのか。
symlinkはロック機構じゃないんだから、symlinkの使い方を工夫しないで
実現できないのは当然じゃん。

**名無しさん＠お腹いっぱい。** · 2007/10/31(水) 15:00:03

たとえばqmailのmaildir。
NFS環境下で安全にメッセージを配送するために、
ユニークなファイル名で衝突しないようにしている。
http://cr.yp.to/proto/maildir.html を見ると先頭に書いてあるのは、
> Two words: no locks.

**名無しさん＠お腹いっぱい。** · 2007/11/12(月) 14:19:39

実家 in 四国にあるマシンのディスクを
俺んち in 大阪にあるマシンから nfs でマウントするのは無謀？
セキュリティ面はおいといて（ VPN 張るので）、
速度的にとか、ファイルの書き換えしてると不意に
ファイルがロストしちゃったりとか、そういうことってある？

**名無しさん＠お腹いっぱい。** · 2007/11/12(月) 14:53:17

俺は東京にいるんだが普通にSan Joseのファイルサーバをマウントしてるぞ。

**名無しさん＠お腹いっぱい。** · 2007/11/12(月) 15:07:04

>>174
そんな無謀な・・・
そういう時って TCP ベースの nfs 使うの？
それとも VPN 張った上でいつもの UDP なやつ？

そもそも NFS で TCP って聞いたときには
うへぇ、と思ったものだが。

**名無しさん＠お腹いっぱい。** · 2007/11/12(月) 17:38:36

> NFS で TCP うへぇ
何で？

**名無しさん＠お腹いっぱい。** · 2007/11/12(月) 19:10:29

>>176
NFS側にリトライ処理が付いてるのに
TCPにする事でTCP側の再送制御が増えるからではないかと。

1000/100Mbps混在でイーサネットスイッチが
バッファ溢れしてデータをポロポロこぼすような環境だと
NFS over TCPはそれなりに有効。
というかウチの社では推奨してる。

エラーフリー環境で使うなら、
TCPよりUDPの方が速いベンチ結果にはなるね。

**名無しさん＠お腹いっぱい。** · 2007/11/13(火) 17:31:15

> 1000/100Mbps混在でイーサネットスイッチが
> バッファ溢れしてデータをポロポロこぼすような環境だと

まてまてIEEE802.3xのフロー制御あるんだからいまどきそんな環境ありえんだろ。
そんなとこでNFS使ったら再送発生するたびにどれだけつっかえるんだよ。
先にまずネットワーク直せよ。

**名無しさん＠お腹いっぱい。** · 2007/11/13(火) 23:07:09

>> 1000/100Mbps混在でイーサネットスイッチが
>> バッファ溢れしてデータをポロポロこぼすような環境だと
>まてまてIEEE802.3xのフロー制御あるんだ>からいまどきそんな環境ありえんだろ。

普通そうだよな。
でも、そんなスイッチが半年前まで現行機種でな。
営業が安さにつられて構成勝手に変えて、
そのゴミスイッチ相手に格闘する羽目に orz

**名無しさん＠お腹いっぱい。** · 2007/11/14(水) 00:33:23

flow controlで送信止められちゃうとnicの送信ディスクリプタが
足りなくなってOS内でパケット捨てることはあるかもしれない。

**173** · 2007/11/15(木) 19:26:23

なんかうまくいかなかった原因がわかりました。
PPTP で Linux - Linux で VPN 張ってたんですが，
PPP での MTU のネゴシエーションがうまくできてなかったみたいで
1500 になってたのが原因でした．
思い切って 1400 にしたら問題なくなりました．
うむむ，NTT西日本のフレッツとケイオプティコムの
eo光の間の VPN なんですが，結構ヘッダついてるんだなぁ．
最適値は 1408 のような気もするけど面倒なので 1400．
普通は自動的にネゴってくれますよねぇ？

**名無しさん＠お腹いっぱい。** · 2007/11/19(月) 13:13:21

http://www.linux.or.jp/JF/JFdocs/Adv-Routing-HOWTO/lartc.cookbook.mtu-discovery.html

**名無しさん＠お腹いっぱい。** · 2007/11/20(火) 11:13:29

NFSに強いスイッチを探してます。クライアントは６４台くらいです。
構成としては、クライアントとサーバを１つのスイッチに集約するのではなく、
２４ポートを数台使ってツリー型の構成にし、ツリーの上流にサーバを置く
形を想定しています。ネストは２段くらいです。

そのものずばりのお勧めより、こういう用途のときにスイッチに必要な機能は
どういうものかを教えていただけると、品定めするときに参考になるのですが、
お知恵を拝借できますでしょうか？

**名無しさん＠お腹いっぱい。** · 2007/11/20(火) 11:39:49

普通にCatalystで良いジャン

**名無しさん＠お腹いっぱい。** · 2007/11/20(火) 11:56:43

ワイヤースピード、ノンブロッキング
低レイテンシ
広帯域スイッチファブリック

**名無しさん＠お腹いっぱい。** · 2007/11/20(火) 12:54:06

>>184
そこをもうちょっと安めでお願いできますか……

**名無しさん＠お腹いっぱい。** · 2007/11/20(火) 20:32:18

NICは全てIntelで揃えるのが吉。

あと、サーバに極端な負荷がかからないよう、アップリンクだけ1Gにして
クライアントは全て100Mにするのが吉。

**名無しさん＠お腹いっぱい。** · 2007/11/21(水) 08:56:03

Broadcom はだめですか？
AMD Opteron なサーバと Intel の NIC の
相性が悪いとかないかな？

**187** · 2007/11/21(水) 10:09:53

>>188
> Broadcom はだめですか？
Broadcomは評価した事が無いので知らない。

**名無しさん＠お腹いっぱい。** · 2007/11/22(木) 23:36:32

intelもだめだよなあ。相性悪すぎ。ギガビットは総じてダメ。

**名無しさん＠お腹いっぱい。** · 2007/11/23(金) 01:10:20

蟹ギガ。これ、素人にはお勧めしない

**名無しさん＠お腹いっぱい。** · 2007/11/23(金) 11:57:03

>>190
ちょ、んなこといったら使うものないじゃん。

**名無しさん＠お腹いっぱい。** · 2007/11/23(金) 12:16:00

10Gbとか?

**名無しさん＠お腹いっぱい。** · 2007/11/23(金) 12:18:50

>>192
Broadcomでいいじゃん

**名無しさん＠お腹いっぱい。** · 2007/11/23(金) 23:24:06

broadcomは悪くないがvariantが多すぎて一口に語れないのが問題。

**名無しさん＠お腹いっぱい。** · 2007/11/24(土) 00:21:00

なるほどね

**名無しさん＠お腹いっぱい。** · 2007/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サーバにとって義務なのかな？

**名無しさん＠お腹いっぱい。** · 2007/11/24(土) 14:11:09

>>197
当然義務。
読取専用かどうかは、creatまたはopenの際のみに有効な属性で、
一旦open(ハントル取得)してさえしまえば、
ファイル自体の読みとり専用かどうかに関係なく、
O_WRONLYとかでopenされたのなら書き込みができなければならない。

**名無しさん＠お腹いっぱい。** · 2007/11/24(土) 14:11:38

>>197
プログラム中のfclose(fd)はclose(fd)の間違いです

**名無しさん＠お腹いっぱい。** · 2007/11/24(土) 14:17:29

>>198
おー、こんなピンポイントで回答が来るなんて凄いです流石unix板
ちなみにこれはCVSが実際にやってくれる操作です