【NFS】Network File System

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/23 20:04 / Filesize : 235 KB / Number-of Response : 968
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/28(火) 11:42:41 ]: nfsに関する話題を扱うスレ
148 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/23(火) 11:01:42 ]: symlinkとかアホくさいことしなくても、
シングルホストなら/varか/tmp以下でlockfすりゃいいじゃん。
マルチホストなら排他制御プロセスいっこ用意すれ。
149 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/23(火) 11:35:04 ]: >>148
lockfが使えるならそれで良い。

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

で、シングルホストの話なんか最初から誰もしてない。
マルチホストだからこそ問題になる点の議論。
150 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/25(木) 10:50:37 ]: NFSを想定したコードばかりとは限らない状況で
NFSを使うことになる、なんて話もあるだろう。
そういうときにハマるかハマらないかの差は大きいと思うんだよなあ。
151 名前：名無しさん＠お腹いっぱい。 [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のコードを走らせて経過を観察する、でいいのかな？

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

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

symlinkだのmkdirだのは排他制御の方法としてlockf以上に「お話にならない」。
書類審査で落とされる。
157 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/29(月) 15:42:43 ]: >>156
でも、(少なくとも)Solarisだと、symlinkもmkdirもしっかりロックとして
機能するんだよ。
158 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/29(月) 15:56:52 ]: FreeBSDはlockfがダメだからNFSが使いものにならない
↓
NFSでlockfなんか使うのは運用が間違ってる(mkdirやsymlinkを使えば良い)(>>by 141)
↓
symlinkだのmkdirだのはお話にならない(by >>156)
↓
FreeBSDではNFSは使えない。

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

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

-rw-r--r-- 1 hogehoge admin 2253 10月 10 15:36 .nfs002d56600000001
165 名前：名無しさん＠お腹いっぱい。 mailto:sage [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越しのファイル操作で排他が保証されないことを
前提に、それでも衝突することがないように(排他できなくてもよいように)
工夫して書かれている。
166 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/30(火) 13:16:18 ]: >>164
UNIXでは、プロセスが開いているファイルでも削除できる。
そのとき、ファイルはすでに削除され見えないのだが、
オープンしたプロセスだけはファイルにアクセスし続けられる。

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

クライアントが削除を怠ると(=クライアントのOSが落ちると)
.nfsはストレージ上に残されたまま放置される。
167 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/30(火) 13:51:42 ]: >>165　なんでNFSで出来ない排他制御をやりたがるのか。
だってNFSと銘打ってるのにそれが出来てる(ように見える)OSがあるんだもんよー。
FreeBSDで出来ないのは悔しくね？　という話だと思っていた。
168 名前：164 mailto:sage [2007/10/30(火) 19:31:59 ]: >>166
ありがとうございました。
169 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/31(水) 02:24:25 ]: 出来ているように見えるだけで
本当に出来ているのかは定かではないｗ
170 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/31(水) 12:47:49 ]: >>165
>逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
>前提に、それでも衝突することがないように(排他できなくてもよいように)
>工夫して書かれている。

えー。
嘘書いちゃ、だめだよ。
171 名前：170 mailto:sage [2007/10/31(水) 12:53:50 ]: ああ、プロトコル上だけで実現できるかどうかの話をしてるのか。
symlinkはロック機構じゃないんだから、symlinkの使い方を工夫しないで
実現できないのは当然じゃん。
172 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/10/31(水) 15:00:03 ]: たとえばqmailのmaildir。
NFS環境下で安全にメッセージを配送するために、
ユニークなファイル名で衝突しないようにしている。
cr.yp.to/proto/maildir.html を見ると先頭に書いてあるのは、
> Two words: no locks.
173 名前：名無しさん＠お腹いっぱい。 [2007/11/12(月) 14:19:39 ]: 実家 in 四国にあるマシンのディスクを
俺んち in 大阪にあるマシンから nfs でマウントするのは無謀？
セキュリティ面はおいといて（ VPN 張るので）、
速度的にとか、ファイルの書き換えしてると不意に
ファイルがロストしちゃったりとか、そういうことってある？
174 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/12(月) 14:53:17 ]: 俺は東京にいるんだが普通にSan Joseのファイルサーバをマウントしてるぞ。
175 名前：名無しさん＠お腹いっぱい。 [2007/11/12(月) 15:07:04 ]: >>174
そんな無謀な・・・
そういう時って TCP ベースの nfs 使うの？
それとも VPN 張った上でいつもの UDP なやつ？

そもそも NFS で TCP って聞いたときには
うへぇ、と思ったものだが。
176 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/12(月) 17:38:36 ]: > NFS で TCP うへぇ
何で？
177 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/12(月) 19:10:29 ]: >>176
NFS側にリトライ処理が付いてるのに
TCPにする事でTCP側の再送制御が増えるからではないかと。

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

エラーフリー環境で使うなら、
TCPよりUDPの方が速いベンチ結果にはなるね。
178 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/13(火) 17:31:15 ]: > 1000/100Mbps混在でイーサネットスイッチが
> バッファ溢れしてデータをポロポロこぼすような環境だと

まてまてIEEE802.3xのフロー制御あるんだからいまどきそんな環境ありえんだろ。
そんなとこでNFS使ったら再送発生するたびにどれだけつっかえるんだよ。
先にまずネットワーク直せよ。
179 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/13(火) 23:07:09 ]: >> 1000/100Mbps混在でイーサネットスイッチが
>> バッファ溢れしてデータをポロポロこぼすような環境だと
>まてまてIEEE802.3xのフロー制御あるんだ>からいまどきそんな環境ありえんだろ。

普通そうだよな。
でも、そんなスイッチが半年前まで現行機種でな。
営業が安さにつられて構成勝手に変えて、
そのゴミスイッチ相手に格闘する羽目に orz
180 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/14(水) 00:33:23 ]: flow controlで送信止められちゃうとnicの送信ディスクリプタが
足りなくなってOS内でパケット捨てることはあるかもしれない。
181 名前：173 mailto:sage [2007/11/15(木) 19:26:23 ]: なんかうまくいかなかった原因がわかりました。
PPTP で Linux - Linux で VPN 張ってたんですが，
PPP での MTU のネゴシエーションがうまくできてなかったみたいで
1500 になってたのが原因でした．
思い切って 1400 にしたら問題なくなりました．
うむむ，NTT西日本のフレッツとケイオプティコムの
eo光の間の VPN なんですが，結構ヘッダついてるんだなぁ．
最適値は 1408 のような気もするけど面倒なので 1400．
普通は自動的にネゴってくれますよねぇ？
182 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/19(月) 13:13:21 ]: www.linux.or.jp/JF/JFdocs/Adv-Routing-HOWTO/lartc.cookbook.mtu-discovery.html
183 名前：名無しさん＠お腹いっぱい。 [2007/11/20(火) 11:13:29 ]: NFSに強いスイッチを探してます。クライアントは６４台くらいです。
構成としては、クライアントとサーバを１つのスイッチに集約するのではなく、
２４ポートを数台使ってツリー型の構成にし、ツリーの上流にサーバを置く
形を想定しています。ネストは２段くらいです。

そのものずばりのお勧めより、こういう用途のときにスイッチに必要な機能は
どういうものかを教えていただけると、品定めするときに参考になるのですが、
お知恵を拝借できますでしょうか？
184 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/20(火) 11:39:49 ]: 普通にCatalystで良いジャン
185 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/20(火) 11:56:43 ]: ワイヤースピード、ノンブロッキング
低レイテンシ
広帯域スイッチファブリック
186 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/20(火) 12:54:06 ]: >>184
そこをもうちょっと安めでお願いできますか……
187 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/20(火) 20:32:18 ]: NICは全てIntelで揃えるのが吉。

あと、サーバに極端な負荷がかからないよう、アップリンクだけ1Gにして
クライアントは全て100Mにするのが吉。
188 名前：名無しさん＠お腹いっぱい。 [2007/11/21(水) 08:56:03 ]: Broadcom はだめですか？
AMD Opteron なサーバと Intel の NIC の
相性が悪いとかないかな？
189 名前：187 mailto:sage [2007/11/21(水) 10:09:53 ]: >>188
> Broadcom はだめですか？
Broadcomは評価した事が無いので知らない。
190 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/22(木) 23:36:32 ]: intelもだめだよなあ。相性悪すぎ。ギガビットは総じてダメ。
191 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/23(金) 01:10:20 ]: 蟹ギガ。これ、素人にはお勧めしない
192 名前：名無しさん＠お腹いっぱい。 [2007/11/23(金) 11:57:03 ]: >>190
ちょ、んなこといったら使うものないじゃん。
193 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/23(金) 12:16:00 ]: 10Gbとか?
194 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/23(金) 12:18:50 ]: >>192
Broadcomでいいじゃん
195 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/23(金) 23:24:06 ]: broadcomは悪くないがvariantが多すぎて一口に語れないのが問題。
196 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/24(土) 00:21:00 ]: なるほどね
197 名前：名無しさん＠お腹いっぱい。 [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サーバにとって義務なのかな？
198 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/24(土) 14:11:09 ]: >>197
当然義務。
読取専用かどうかは、creatまたはopenの際のみに有効な属性で、
一旦open(ハントル取得)してさえしまえば、
ファイル自体の読みとり専用かどうかに関係なく、
O_WRONLYとかでopenされたのなら書き込みができなければならない。
199 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 14:11:38 ]: >>197
プログラム中のfclose(fd)はclose(fd)の間違いです
200 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 14:17:29 ]: >>198
おー、こんなピンポイントで回答が来るなんて凄いです流石unix板
ちなみにこれはCVSが実際にやってくれる操作です
201 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/24(土) 14:19:25 ]: ちなみに、わざわざ C言語でプログラムしなくても、
シェル上で同じことができる。

umask 777
echo hoge > file

とやれば、fileは読み込みも書き込みも不許可で作成されるが、
echo hogeの内容はちゃんとfileに書き込まれる。
fileがNFS上にあっても当然動作しなければならない。
202 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 14:21:35 ]: なるほどumaskはそうやって使うんですね
203 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 17:34:17 ]: >>198
RFC1813, 4.4 Permission issues の第3段落に書いてありました
204 名前：名無しさん＠お腹いっぱい。 [2007/11/25(日) 15:06:35 ]: RPC でつかうポートが変化するから、
NATルータ越しのNFSは㍉？
VPN 通すしかない？
205 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/25(日) 17:00:41 ]: Intelの82573L で2.4系カーネルでNICのリセット多発した。
結局、NICのROMのアドレス1部変更で直った。
2.6カーネルでは解消された。
206 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/06(木) 13:41:08 ]: >>204
実装によってはポート固定も無理ではないが、
ここで聞かないとわからないレベルならお薦めしない。
あと、WebNFSという選択肢もある。
207 名前：名無しさん＠お腹いっぱい。 [2007/12/19(水) 02:30:55 ]: NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
NFSサーバに10GBのファイルがあって、それをNFSクライアントで読み込むときに
10GB全部をクライアントでリード・ライトしなきゃいけないとかそういうことなんでしょうか？
208 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 09:08:58 ]: >>207
> NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
どこであるいは誰に聞いた？
209 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 09:21:46 ]: >>208
google: NFS iSCSI ファイルブロック

itpro.nikkeibp.co.jp/article/COLUMN/20060407/234778/
＞データ転送の単位は，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 名前：名無しさん＠お腹いっぱい。 [2007/12/19(水) 09:58:18 ]: SCSIの復活キター？
211 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 11:14:58 ]: って事はiSCSIの方が巨大ファイルでは優位って事なの？
212 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/20(木) 16:46:40 ]: 何を持って優劣の指標としているのか明快に述べよ
213 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/20(木) 16:58:19 ]: 何を持って誤字の書込みをしているのか明解に述べよ
214 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/27(木) 14:42:36 ]: NFSとiSCSIではファイルシステムの層が違う。

ファイル操作システムコール(API)
VFS
個々のファイルシステム(ext3,xfs,reiserfs,fat16,iso9660)
ドライバ
ハードウェア

NFSってのはファイル操作システムコールに相当、ファイル単位でも扱えるし、
バイト単位で読んだりもできる。VFSから下は考えなくてよい。

iSCSIってのはドライバに相当、ファイル単位では考えないで、
ハードウェアとのやりとりの最小単位(ブロック単位)で考えなければならない。
システムとして利用するには、ファイルシステム、VFS、システムコールも備えていなければならない。
215 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/27(木) 14:48:10 ]: >>212-213
以って？
216 名前：名無しさん＠お腹いっぱい。 [2007/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 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/28(金) 05:39:34 ]: /opt/share のファイルシステムのマウントオプションのumaskしだいでは?
NFSサーバの実装によってはそういうのもありえるかもしれないけど、
NFSサーバでumaskを強制させてもあまり意味がないのかも。roかrwくらいだろうし…
218 名前：216 mailto:sage [2008/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 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 11:20:48 ]: そもそも論になるけど、NIS使えば?
220 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 21:59:39 ]: えーマジNISー？ｗ
NISが許されるのは10人未満のLANまでだよねーｗｗｗ
221 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 23:17:07 ]: >>220
じゃあなんNISればいいんですか？＞＜
222 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 17:17:43 ]: 複数台のサーバ環境（自宅サーバ郡）でNFS使って共有するときって、どのディレクトリをシェアするのが効率的なんでしょ
みなさんの運用方法で「これはおすすめ！」っての、教えてもらえないでしょうか。
ちなみにうちはCentOS5の6台構成（Web 3台、Db1台、開発用1台、DB＆NFS＆Samba鯖機1台）
223 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/08(土) 17:39:30 ]: WebサーバでNFSなんて使わないでくださいネ。
224 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 17:43:03 ]: >>223
え、そうなの？
/usr/local/libならシェアしてるけども。
225 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 23:39:09 ]: NFSっていらんやろ
226 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/08(土) 23:47:11 ]: >>222
/homeのNFS共有は当然として、
OSのバージョンが同じなら /usr以下をすべてNFS共有する。
updatesとか、OSのバージョン管理が一元化できる。
ホストを1台増やす時でも、OSをインストールする必要はない。
もともとインストール済の/usrをNFS共有して、
ホスト毎に必要な/etcや/varなどを個別に用意するだけで済むから。
227 名前：名無しさん＠お腹いっぱい。 [2008/03/09(日) 13:46:30 ]: >>223
ロードバランサーでWebサーバ束ねているような場合、コンテンツの
directoryをNFSで共有って、良くやるパターンだよね？
セキュリティの事を気にして言っているの？
だとしても、その対処法はあるわけで。
228 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/09(日) 21:25:20 ]: たいていのパッケージシステムは、/usrのNFS共有を想定してないんじゃないかな。
少なくとも、ベンダやメンテナによるテストはあまりされていないよね。
そもそも今はパッケージシステム(と安くなったディスク)のおかげで、/usrを共有する必要性って薄くない?

ロードバランサで分散しなきゃならないWebトラフィックって、CGI(CPU bound)なやつで、
その場合はRDBを共有するんじゃないかな。NFSサーバではなく。

NFSに限らず、ネットワークは不確かで、トラブルの発生源の代表格。
厄介なホスト間の依存性も発生するし、ホストローカルで完結するならその方がいいに決まってる。
このシステムにNFSって本当に必要なの? って自問してみるのは、管理コストを減らすのに役立つと思う。

個人的な感覚では、システムのメンテナンスのためにNFSをスポットで利用するのは便利だと思う。
(一般ユーザの/homeや/usr/portsみたいなのを共有するということね)
229 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/09(日) 22:31:09 ]: Solarisでは、/usrはNFS共有することが前提で、
パッケージは SUNW**u が /usr用、SUNW**r が /usr以外用と、
きちんと分けて考えられてるね。
なるべく共有できるバイナリを増やすため、
/binを廃止して /binを /usr/binへのsymlinkにしてるくらいだし。
230 名前：名無しさん＠お腹いっぱい。 [2008/03/09(日) 23:41:52 ]: つ、つまり共有すべきなのは/usr, /homeの二つが鉄板ということでおｋ？
ていうかNFSで共有してる時点でかなりアクセスのパフォーマンスが低下することは避けられないですよね、うーむ。
LAN内で共有してるのであればそんなに気にスンナってか。
231 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 10:44:40 ]: いまどきNFSなんて使ってるのか？
232 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:13:09 ]: >>230
日本語が読めてないな。

Solarisは/usrを共有することを想定して設計されているから共有できる。
おまえが使うOSはSolarisなのか?
233 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:36:11 ]: *BSD方面では、NFSは「無かったこと」にしたいんだろうなｗ
234 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:42:27 ]: よく知らんけど、Linux方面のNFS実装ってマシになったの?
235 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 13:58:02 ]: 数年前にzero copyな実装になって今ではNFSv4まで対応してます。
236 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 14:41:03 ]: NFSでマウントしたディレクトリってやっぱりアクセス速度が低下するんですか

ってことはデータベース（MySQL)のデータ領域をNFS共有して運用するなんてしちゃだめですね。
でもなんでWebならいいんだ？
237 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 14:53:29 ]: 書き込まないなら良いんじゃない？遅いけど。
238 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:02:19 ]: OracleみたいにNFS向けに最適化されているならともかく、
通常のデータベースはNFSファイルシステム上に置いてはいけない。

> でもなんでWebならいいんだ？
Webでもよくはない。NFSで複数のWebサーバがコンテンツを共有するのは、
導入費用も管理コストも高くつくアプローチだ。
239 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:05:35 ]: しちゃだめって言うより
意味なくね？
240 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:08:35 ]: >>238
> OracleみたいにNFS向けに最適化されている

そうなんか。
Windows 用のだとネットワークストレージ上に DB 作成するのは
やめとけ、みたいな感じだったけど(実際ごにょごにょしないと
作成出来ないし)。
241 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:20:33 ]: 一万個の小さいhtmlファイルが1分ごとに更新されるとかの変なwebサイトで無い限り
NFSなんて使わないほうがいい
242 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:36:32 ]: >>236
>>227のことと合わせて考えると、Webの場合はCPUがボトルネックになりやすいから、
ロードバランサを導入する意味はある。ただし、変更されるデータの一貫性維持は
どこかで考えておかないといけない。ありがちなのは、そういうデータはDBサーバに
置いて、一貫性維持はアプリケーションとDBの合わせ技でまかなう感じ。

で、Webサーバと同じ理屈で、DBサーバのデータ領域をNFS上に置いて並列運用すると
どうなるかは…
243 名前：名無しさん＠お腹いっぱい。 [2008/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 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 17:01:22 ]: >>238
WEBサーバの場合、どういう手法が良いんですかね？
rsyncとか？
245 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 17:05:01 ]: >>243
rsync3.0が出て速くなった(らしい)よ
246 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 20:38:04 ]: >>243
ここでそれを質問するということは、NFS環境下で障害を起こすアプリケーション・
ユーザコードの有無を検証できる人があなたの組織にはいないと見るけど、どうかな。

ならばrsyncで各サーバにファイルを配布するスクリプトを書いた方が安全だと思う。
コマンド1発で出来るようにしておけば管理の手間も生じない。
(バージョンに依存したアプリケーションが置かれているとかの理由で)共通化できない
特定のホストを個別に対応することも容易。

一般論として、すでに動いているサーバの構成を変えるのは上策じゃない。
NFSを入れるなら、運用を開始する前にテストするべき。
247 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 21:37:33 ]: NFSはもう古い、って広告、昔あったよね
248 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 21:38:39 ]: >>247
どんなん？

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef