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ればいいんですか？＞＜