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

【NFS】Network File System

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/03/28(火) 11:42:41
nfsに関する話題を扱うスレ
0233名無しさん＠お腹いっぱい。2008/03/10(月) 11:36:11
*BSD方面では、NFSは「無かったこと」にしたいんだろうなｗ
0234名無しさん＠お腹いっぱい。2008/03/10(月) 11:42:27
よく知らんけど、Linux方面のNFS実装ってマシになったの?
0235名無しさん＠お腹いっぱい。2008/03/10(月) 13:58:02
数年前にzero copyな実装になって今ではNFSv4まで対応してます。
0236名無しさん＠お腹いっぱい。2008/03/10(月) 14:41:03
NFSでマウントしたディレクトリってやっぱりアクセス速度が低下するんですか

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

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

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

で、Webサーバと同じ理屈で、DBサーバのデータ領域をNFS上に置いて並列運用すると
どうなるかは…
0243名無しさん＠お腹いっぱい。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を導入したいと考えているのですが、
↑のお話だとパフォーマンスが悪いので辞めたほうがよいということですか？
詳しいから、お知恵拝借させてください。
0244名無しさん＠お腹いっぱい。2008/03/10(月) 17:01:22
>>238
WEBサーバの場合、どういう手法が良いんですかね？
rsyncとか？
0245名無しさん＠お腹いっぱい。2008/03/10(月) 17:05:01
>>243
rsync3.0が出て速くなった(らしい)よ
0246名無しさん＠お腹いっぱい。2008/03/10(月) 20:38:04
>>243
ここでそれを質問するということは、NFS環境下で障害を起こすアプリケーション・
ユーザコードの有無を検証できる人があなたの組織にはいないと見るけど、どうかな。

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

一般論として、すでに動いているサーバの構成を変えるのは上策じゃない。
NFSを入れるなら、運用を開始する前にテストするべき。
0247名無しさん＠お腹いっぱい。2008/03/10(月) 21:37:33
NFSはもう古い、って広告、昔あったよね
0248名無しさん＠お腹いっぱい。2008/03/10(月) 21:38:39
>>247
どんなん？
0249名無しさん＠お腹いっぱい。2008/03/10(月) 22:05:11
>>242
DBにデータを書き込むアプリなら良いけど、ファイルシステム上に
ファイル生成したり、書き換えたりする奴もあるよね。
そうした場合は、NFS置くのが定石。
NetAppみたいの使えば、パフォーマンスもそれほど心配無いだろう。
0250名無しさん＠お腹いっぱい。2008/03/11(火) 16:22:22
NetApp買えるなら、その金で1台に集約してNFS不要にする手もあるな。
0251名無しさん＠お腹いっぱい。2008/03/11(火) 16:32:41
>>249
アプリケーションがちゃんと並列動作まで考慮してくれてるならいいけど、
通常ファイル使うことからしてあまり期待できないような。

アプリケーションの中身知ってるものならいいけど、自分は定石とまでは言いたくないな。
0252名無しさん＠お腹いっぱい。2008/03/11(火) 23:07:04
いずれ結局中身を気にすることにはなる
0253名無しさん＠お腹いっぱい。2008/03/12(水) 00:42:22
>>251
ここで言っているアプリは、ロードバランサーで負荷分散できる様な
Webアプリだからね。DBだけじゃなくて、ファイルに書く奴あるじゃん。
そう言うのは、NFSファイルサーバ立てて使うよね？
0254名無しさん＠お腹いっぱい。2008/03/12(水) 08:27:40
まあそうだけど、それは「まずい設計をどうにか延命する方法」であって、定石と呼ぶのは抵抗あるなあ。

逆説的だけど、NFS環境を想定したコードが書ける人は、NFSに依存しないで済む方法も用意する。
NFSを使わざるを得ない、というのは、それが本当にNFS上で運用しても問題ないように出来ているのか、一沫の不安を感じるのだ。

NetAppまで導入してしまえば、バックアップ等の運用コストを下げられる余地がでてくるので、
NFSをデスクトップクライアント限定の技術だと考えるのは保守的な考え方かもしれないけどね。
0255名無しさん＠お腹いっぱい。2008/03/12(水) 12:59:40
すくなくとも DBのID/PASSはファイル持ちだと思うな。
0256名無しさん＠お腹いっぱい。2008/03/12(水) 13:04:17
アクセスをきっかけに変更されないデータならどうだっていいんだけどさー、
>>253はファイルに書くって書いてるじゃん……
0257名無しさん＠お腹いっぱい。2008/03/12(水) 13:30:05
>>256
アプリケーションの設計の話だ。
ストレージはファイルシステムだけじゃないだろ?
複数ホスト間で変更の共有が必要な情報を、安易にファイルシステムに格納するアプリケーションは、
トラブルを潜在している徴候だ。
02582562008/03/12(水) 14:56:34
>>257
いやまぁ、だからそういうことを言いたいわけで。
書き込みするのにNFS共有するのは危ないだろうと。
0259名無しさん＠お腹いっぱい。2008/03/13(木) 02:27:16
自宅で5台動かしてるCentOSサーバ（Webサーバ）それぞれにログインするのがめんどい…
/homeを一台でNFS共有して使いまわそうかなと思うのだけど、邪道かな
ついでに/usr/local以下も共有して、自作ライブラリやソースファイルをシェアするってのも検討中。

ガッコで教わったわけじゃないので、どういう風に使うのかが正道なのかわからず、すまんかった…
0260名無しさん＠お腹いっぱい。2008/03/13(木) 10:22:35
/homeは共有してもいいんじゃないか？
0261名無しさん＠お腹いっぱい。2008/03/13(木) 11:25:47
/homeやサイトローカルなディレクトリのNFS共有は真っ当だろう。
てか、自宅なら好きにやればいいと思うが、
システムのブートやデーモンの類はNFSサーバに依存させないのが吉。
ホスト間の依存関係が複雑になると管理がとてもとても面倒になるから。

あと卒直に言えば、ログインが面倒になるほどホスト増やす時点で
かなり間違った道を進んでいる。
0262名無しさん＠お腹いっぱい。2008/03/13(木) 12:16:40
>>261
ログイン簡単にするって、どうすればいいの？
うちの会社は100台弱あって大変… /usr/localをシェアするのっていいなあ
0263名無しさん＠お腹いっぱい。2008/03/13(木) 13:23:30
機械なんだから管理はどんどん自動化しろよ。
なんのためのUNIXだよ。
0264名無しさん＠お腹いっぱい。2008/03/13(木) 13:29:48
シェアはしないけどNFSにする、って方法もあるぞ。
クライアントの /usr/local他のデータを個別に NFS鯖側に持つ。
すると、NFS鯖にログインするだけですべてのクライアントのデータをいじれる。
シェアはしていないので、書き込み競合とかの問題もなし。
0265名無しさん＠お腹いっぱい。2008/03/13(木) 15:14:19
>>263
それ、俺もすげー興味ある。
どんな感じで管理してるの？ 参考にしたい。
0266名無しさん＠お腹いっぱい。2008/03/13(木) 16:38:40
NFSにちょっと関係があるかと思い便乗質問で恐縮ですが、
NISも導入した方がいいでしょうか？ ひとつのサーバにパスワードやグループなどを
一括管理できるようになるのはメリットかと思うのですが、逆にデメリットって実運用
ではどんなことがあるのかと思い。　よろしくおねがいしまんこ。
0267名無しさん＠お腹いっぱい。2008/03/13(木) 16:40:04
今更NISか？
LDAPで良いんじゃね？
0268名無しさん＠お腹いっぱい。2008/03/13(木) 18:19:01
>>266 UNIXだけで組んだシステムならNISでも悪くないよ。シンプルだし。
デメリットとしては、古臭いというぐらいだと思うｗ ある程度の規模になると
LDAP + NSS + nscd の方が安定性も反応性も高い希ガスです。

>>262 100台って少ないね・・・
>>263 激しく同意。人間様のプライドとして単純作業はすべて機械にやらせる。
>>265 cfengine とか Puppet とか？
漏れは自作フレームワークでインスコからメンテから全部楽々運用だな。
人海戦術の手作業で鯖管理してるような DQN を見てると悲しくなる。
0269名無しさん＠お腹いっぱい。2008/03/13(木) 19:14:31
自作フレームワークをオープンソースでうpしてくれ
0270名無しさん＠お腹いっぱい。2008/03/13(木) 19:17:46
NIS使うとshadow passwdの意味がなくなるんだよな。いや、別にいいんだけど
0271名無しさん＠お腹いっぱい。2008/03/13(木) 19:37:56
うちもNFS+NISだな。
/homeと/usrをNFSで共有。PXE Bootで/もNFS越し。

まあ、数値計算用でほとんど同じ構成だから、あまり凝ったことをしなくても管理は楽。
0272名無しさん＠お腹いっぱい。2008/03/13(木) 20:48:20
>>270 C2セキュリティのオプションONにすればok
ypcatで表示しなくなる。
それでも気になる人はNIS+をどうぞ。
0273名無しさん＠お腹いっぱい。2008/03/13(木) 21:16:38
NIS+はサポート終了だって
0274名無しさん＠お腹いっぱい。2008/03/13(木) 22:41:03
めでたしめでだし
0275名無しさん＠お腹いっぱい。2008/03/15(土) 01:07:04
NFSの転送速度って遅くないですか？
0276名無しさん＠お腹いっぱい。2008/03/15(土) 05:48:30
いやーそれほどでも
0277名無しさん＠お腹いっぱい。2008/03/15(土) 09:32:29
うちは50MB/secが限度だった
0278名無しさん＠お腹いっぱい。2008/03/15(土) 15:36:04
うちは75MB/sぐらい。
0279名無しさん＠お腹いっぱい。2008/03/15(土) 16:06:22
> UNIXだけで組んだシステムならNISでも悪くないよ。

悪いこといわんからLDAPにしとけ。
NIS/NIS+はobsolete technologyだ。

特に100台あると(>>262)、NISにはmap転送ストームの問題がある。
0280名無しさん＠お腹いっぱい。2008/03/15(土) 16:56:06
NFS自体
0281名無しさん＠お腹いっぱい。2008/03/15(土) 19:10:52
NIS+はobsolete technologyだが
NISは今も今後も現役。
0282名無しさん＠お腹いっぱい。2008/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かけると負担がかかるので
そのへんはばらけるように工夫する。
0283名無しさん＠お腹いっぱい。2008/03/15(土) 20:12:24
>>281
NISはレプリカが多い時に、
パスワードの同時変更が起きると悲惨。
まさにobsolete。
0284名無しさん＠お腹いっぱい。2008/03/15(土) 20:14:03
NISではレプリカとは言わん。批判するなら正しい用語で。
0285名無しさん＠お腹いっぱい。2008/03/15(土) 20:18:36
じゃあスレーブなw
0286名無しさん＠お腹いっぱい。2008/03/15(土) 20:21:16
ここでhesiodの出番だな
0287名無しさん＠お腹いっぱい。2008/03/15(土) 20:23:38
yppushが起きるだけだが? 何が悲惨?
0288名無しさん＠お腹いっぱい。2008/03/15(土) 20:30:30
NISがだめだとおもうならnetinfoを使えばいいのに
0289名無しさん＠お腹いっぱい。2008/03/16(日) 01:21:26
おっさんが多いスレなのかしら
0290名無しさん＠お腹いっぱい。2008/03/16(日) 14:43:57
エクスポートする、またはマウントするパスで、効率的なやり方を教えてください
0291名無しさん＠お腹いっぱい。2008/03/16(日) 15:30:25
/
0292名無しさん＠お腹いっぱい。2008/03/22(土) 05:02:33
高スペック機1台をNFSサーバにして　/export/各サーバ名/home　それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンのLinux（centos5.1 x86_64）同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
0293名無しさん＠お腹いっぱい。2008/03/22(土) 08:57:35
Linuxのネタをここでやろうとするのは変
0294名無しさん＠お腹いっぱい。2008/03/22(土) 12:13:28
高スペック機1台をNFSサーバにして　/export/各サーバ名/home　それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンの FreeBSD 6.3R同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
0295名無しさん＠お腹いっぱい。2008/03/22(土) 12:30:31
FreeBSDでNFSはヤツの召還呪文
0296名無しさん＠お腹いっぱい。2008/03/22(土) 19:51:32
NFSは激遅
0297名無しさん＠お腹いっぱい。2008/03/22(土) 20:56:27
>>294
そんなことしないでバックエンド側でファブリック組めばええんちゃう？
0298名無しさん＠お腹いっぱい。2008/03/23(日) 03:07:14
>>262
1000台以上あるけど、適当な認証鍵つくって、ループスクリプトでsshでttyつかんで...
ちょいshellscriptを汎用的に書いておけば、一気に全台同じコマンドじっこうできるよん
0299名無しさん＠お腹いっぱい。2008/03/23(日) 16:29:41
>>298 どの様に書くのでしょうか。教えていただけますか。ぜひサンプルを。
0300名無しさん＠お腹いっぱい。2008/03/24(月) 16:42:59
NISよりも優秀なのってなんだっけ？
0301名無しさん＠お腹いっぱい。2008/03/24(月) 19:57:40
>>300
Active Directoryです。
03023002008/03/24(月) 22:22:59
>>301
ありがとう、Active Directoryを導入しました
0303名無しさん＠お腹いっぱい。2008/03/25(火) 10:57:40
>>292
Web公開ファイルを/homeで共有するってこと？ アクセス数次第だなぁ。
スタッフアカウントを/homeで共有するのは良いアイデア。
/usrを共有するのは悪いアイデア。rsyncで同期しておけば良い話だから。
0304名無しさん＠お腹いっぱい。2008/03/25(火) 11:04:28
>>303
アクセスが多い場合、NFSの転送速度からするとよくないんじゃね？
/homeもrsyncかｗｗｗ
0305名無しさん＠お腹いっぱい。2008/03/25(火) 12:13:21
Webコンテンツならローカルに置くだろうけど、
EtherもCPUも速くなった今の時代、単純にNFSだから遅いとはいいきれない。
ローカルの単体SATAとリモートのNetApp、どちらが平均アクセス速度が速いか。
実運用ならバックアップも考えないと。
0306名無しさん＠お腹いっぱい。2008/03/26(水) 02:15:23
CODAも、AFSもどこ行っちまったのだろ。
教えてくれ。
0307名無しさん＠お腹いっぱい。2008/03/26(水) 02:49:23
Webアプリのこの時代に分散ファイルシステムってもの…
Satyanarayananのページに久々に行ってみたら、
Internet Suspend/Resumeってのやってんのな。
これもGoogle Gear辺りと比べるとかなり低い階層でやってるな。
0308名無しさん＠お腹いっぱい。2008/03/26(水) 08:48:24
W
S
I
こ
0309名無しさん＠お腹いっぱい。2008/03/28(金) 01:17:22
ttp://lists.freebsd.org/pipermail/cvs-src/2008-March/089241.html
0310名無しさん＠お腹いっぱい。2008/03/28(金) 14:26:06
nfsでマウントしているディレクトリに、100byte程度のデータを
細かく書いていくプログラムを走らせると、そのクライアント側の
ホストでnfsディレクトリにかなり長い時間アクセスできなくなるのですが
この現象の解決策に関する情報はありませんか？
OSはRedhatlinux4.6 64bit
カーネルは2.6.9-67.EL でも2.6.24でも起こります
同じことをRedhatLinux3.0 の64bit版でやっても起こらないのですが・・
0311名無しさん＠お腹いっぱい。2008/03/28(金) 18:18:40
a) 100バイトずつ投げるな
b) ELなんだからベンダのサポートに投げろ
c) Linuxなんぞ投げ捨てろ
0312名無しさん＠お腹いっぱい。2008/03/28(金) 18:42:22
どうでもいいが、RedHat4.xって、1998年かそれ前後頃、
3.xは1997年頃? すげー古いOSだよね?
0313名無しさん＠お腹いっぱい。2008/03/28(金) 19:01:45
RHLに4.6なんてない。
0314名無しさん＠お腹いっぱい。2008/04/01(火) 02:59:21
>>310
NFSをasyncにしてみたら?
0315名無しさん＠お腹いっぱい。2008/04/01(火) 04:09:49
cacheも増やすべき。acdirmax辺り。
mountオプソンで指定。
0316名無しさん＠お腹いっぱい。2008/04/01(火) 07:49:06
時間割くなら、try&errorの厨ニングよりプログラム直した方が幸せになれると思われ。
NFSだろうがなかろうが、バッファリングせず100byteずつwrite(2)ってのは頭おかしい。
データの整合性を維持する意図でそうしてるならasync mountで動かすのは本末転倒だしな。
ソースがないならご愁傷様。
03173152008/04/01(火) 08:49:29
あれ? 小さいファイルをたくさん作るのかと思ったよ。
どっちとも取れるけど、一つのファイルに少しづつ書くなら、
ディレクトリがアクセスできなくなるのはおかしいなあ。
0318名無しさん＠お腹いっぱい。2008/04/02(水) 01:41:55
>>310
現状のマウントオプション晒しなYo!
0319名無しさん＠お腹いっぱい。2008/04/05(土) 13:20:26
まあrhelなら4.6はあるけど板違いだしなあ
0320名無しさん＠お腹いっぱい。2008/04/09(水) 09:41:04
NFSv3 で同じLANにつながっているマシン同士ではサクサク
ファイル公開できているんだけど、セキュリティ上の理由から
TCPしか通してくれないL3スイッチ越しの隣の部屋のNFSサーバの
ディレクトリを NFSv4 でマウントしたら ls に引っかかる。

ファイルの読み書き、でっかいファイルの転送速度に関しては
たいした違いも無いんだけど、 ls で引っかかる。数秒。
何が原因なんでしょうか？

当然 portmap なんかも通らないんですが、それが原因
なんでしょうか・・・でも NFSv4 だしなぁ。2049/tcp
だけで使えると思うんだけど。
0321名無しさん＠お腹いっぱい。2008/04/09(水) 09:47:49
>>320
L3が糞
0322名無しさん＠お腹いっぱい。2008/04/09(水) 09:55:21
>>321
id でも引っかかるんで、nsswitch.conf 見てみたら、
hosts に wins が指定されていた　orz
samba とか使ってねぇのに。
0323名無しさん＠お腹いっぱい。2008/04/09(水) 10:36:20
NFSv4のクライアントは何?
Solaris以外でまともに使えるのある?
0324名無しさん＠お腹いっぱい。2008/04/09(水) 10:46:04
>>323
>>322 で自己解決したようです
>>321 ハズレ
03253232008/04/09(水) 11:58:15
いや、トラブルとは関係ない質問
0326名無しさん＠お腹いっぱい。2008/04/09(水) 12:51:31
まともに使える=俺の環境・俺の使ってるアプリケーションが動く、だから
基準が人によって全然違うんだよな。
クライアントは1台なのか100台なのか、
テキストエディタでファイルが開けばいいのか、データベースが置けないとダメなのか。
03273232008/04/09(水) 13:09:20
基準は>>320の基準でいいや。
「〜をこう使っていてトラブルなし」ってんで。

ちなみに俺は自宅のファイル共有で使うことしか想定してない。
v3→v4の移行するかどうか。

仕事ならクライアントサイドはSolaris以外でv4使わないし。
0328320=3222008/04/09(水) 13:28:11
server Ubuntu 6.06.2 LTS / kernel 2.6.15
client CentOS 5 / kernel 2.6.18
0329名無しさん＠お腹いっぱい。2008/04/13(日) 03:40:27
質問です、自宅のLANにCentOS5.1のマシンが4台入る予定なのですが、なるだけ
少ない台数で集中管理したいと思っています。
1台の/homeを他3台でシェアしようと思うのですが、自宅LANのような小規模な環境
だとあまり意味の無い方法でしょうか？
それか、みなさんの書き込みを読んでいると人気の、rsyncをつかって1台のデータを
共有しようかと思ったのですが、リアルタイムに同期してる訳じゃないですよね。
03303232008/04/13(日) 09:05:07
>>328
Linuxかあ。今度トライしてみるわ。
ちなみにサーバはOpenSolaris。
0331名無しさん＠お腹いっぱい。2008/04/13(日) 09:08:15
>>329
全部、デスクトップ機なの?
ノートにNFSホームは良くないと思うけど、
デスクトップならオフライン利用考える必要ないしNFSでいいと思うよ。
0332名無しさん＠お腹いっぱい。2008/04/13(日) 12:01:06
>>331 サンクスっ！
NFSでシンプルに構成しようと思います。
よく考えてみりゃ/homeだけってのももったいないから他のも共有マウントしよう
かと思うのだけど、みんなどんな感じでマウントしてるんでしょう？定石ってあるのでしょうか。
マウントする側（3台の方）のHDDって８０GBもあるんだけど、マウントしちゃうと余計HDD領域が余っちゃう
よね、なんだかもったいねえ。
0333名無しさん＠お腹いっぱい。2008/04/13(日) 12:20:52
クライアントはHDD外してディスクレスだよ。
ネットブートして、/ 全体すべて NFSだよ。
LANが速いと、かえってローカルHDDより速い感じがするくらい。
■ このスレッドは過去ログ倉庫に格納されています