The TrueGrid NFS Server 技術的な問題点と回答 A Freeware NFS Server for Windows 95/NT COPYRIGHT (C) BY XYZ SCIENTIFIC APPLICATIONS, INC., 1998 ALL RIGHTS RESERVED. TrueGrid IS A TRADEMARK OF XYZ SCIENTIFIC APPLICATIONS, INC. XYZ Scientific Applications, Inc. 1324 Concannon Blvd. Livermore, CA 94550 無保証に関する規定 ------------------ 無保証。本ソフトウェア製品は「現状のまま」提供され、いかなる種類の保証も されません。適用される法律によって許される範囲内において、XYZ 社と製品の 提供者は、明示及び黙示の一切の保証をいたしません。これは、本ソフトウェア 製品について、商用性や特定目的適合性、第三者の権利の侵害に対する何らかの 保証を含みますが、それだけに限りません。これは、あなたに特定の法的な権利 を与える保証を制限しました。国または地域によりあなたは他の法的な権利を有 する場合があります。 お客さまへの賠償。XYZ 社の完全な賠償責任とあなたの排他的な賠償金額は、支 払われるソフトウェア製品の価格を超えないものとします。 損害のための責任。適用される法律によって許される範囲内において、XYZ 社ま たは製品の提供者は、仮に XYZ 社がそのような損害の起こる可能性のアドバイス を受けていたとしても（業務上の損害、業務の中断、業務に関する情報の損失、 または他のいかなる金銭的な損失に関する影響も含め、例外なく）XYZ 社の製品 を使った事による、または使えなかった事によるどんな損害も責任をとることは ありません。 ===================================================================== ここでは、私達は、PC ファイルシステムが UNIX ファイルシステムには完全に互 換ではないという事実から発生する技術的な問題のいくつかについて議論します。 IBM WORKSTATION： **** 警告 **** ＩＢＭワークステーションは、標準的ではな い動作に依存している部分があります。例えば、ＩＢＭワークステーシ ョンは、ディレクトリのサイズがディレクトリにあるエントリの数とそ れらの名前の長さに依存していることを仮定しています。PC のものは、 長さがないものとしてディレクトリを扱っています。そこで私達は 8192 バイトのサイズがあると通知することにしました。これはほとんどのデ ィレクトリには十分です。しかし、8192 がディレクトリの中身に対して 十分に大きくないならば、「cp -r」はＩＢＭのマシンではクラッシュす る事になります。この問題は簡単には解決されません。なぜなら、ディ レクトリの UNIX でのサイズはディレクトリ全体を読んだ後でなければ 計算できず、そしてそれは恐ろしく効率が悪いかもしれないからです。 パーミッション：UNIX のパーミッションは、読み込み、書き込み、実行に関する 権限をユーザ、グループ、及びその他にわけて付与しています。これは Windows とは異なります。それは NT では合理的に類似のことをさせる 事ができますが、Windows95 ではできません。だから、デフォルトで、 ユーザ、グループ及びその他に対し同じアクセス権を設定します。これ は、全てのファイルで同じ値に変更する事は可能ですが、個々のファイ ルに「umask=」オプションを使う事はできません。（exports ファイル を見てください） 私達は、すべてのファイルが実行可能属性を持っているように表示しま す。もし私達が Windows の実行形式ファイルのみに実行可能属性を割り 当てたならば、その時、UNIX 環境において、UNIX ファイルを実行する ことができなくなってしまいます。だから、私達は全てのファイルとデ ィレクトリが実行可能属性を持っているように表示します。 また、私達は、すべてのファイルの読み込み権があるように表示します。 Windows は書き込み禁止にする事は可能ですが、読み込み権で同様な事 はできません。 ユーザとグループ：私達は、Windows のユーザとグループを UNIX 形式のユーザ とグループにマッピングする事はしません。root ユーザと root グルー プによって所有されているものとみなして、すべてのファイルとディレ クトリを表示します。これは、exports ファイルの「uid=」オプション と「gid=」オプションで変更可能です。（exports ファイル参照）ただ し、この変更は、アクセスできるファイル全体におよびます。 Ｉノード：これは厄介な問題です。UNIX のファイルシステムは全て、ファイルの 識別子として「Ｉノード」を使っています。各ファイルとディレクトリ は、それぞれと関連付けられた、ユニークな「Ｉノード」を持っていま す。PC では、相当するものを使っていません。残念ながら「Ｉノード」 が使用されない場合、UNIX システムは適切に機能しないでしょう。仕方 がないので、ランダムにＩノードをファイルとディレクトリに割当てて います。NFS プログラムが動作している限り、これらのＩノードは同じ 値のまま変わりません。しかしながら、プログラムが一旦停止して再起 動すると、それらの値は全て変化してしまいます。その結果、サーバが 再起動されるときはいつも、すべてのファイルハンドルの「古くなって しまった」値を通知してきます。これは、これらのファイルをアクセス する UNIX システムがエラーを通知することを意味します（通常は、 「Stale NFS Handle」というメッセージが出ます）。もしこの表示を見 たならば、その時は公開されているファイルシステムのトップに「cd」 し、それから下層のディレクトリに戻ってください。UNIX システムは自 分自身をリフレッシュして、新しいファイルハンドルとＩノードに更新 されます。 リンク（ハードリンクとシンボリックリンク）：私達は、ハードリンクもシンボ リックリンクもサポートしません。あるファイルを別のファイルにリン クしようとしてもアクセス権エラーとなるだけです。多くの UNIX ワー クステーションは、ハードリンクが失敗する可能性を考慮していません。 したがって、それらではメッセージの表示すら行われません。ハードリ ンクはＩノードに関連しており、PC の世界にうまくあてはめる事ができ ません。 大文字・小文字の識別：Windows のファイル名は、大文字・小文字の識別をしま せん。これは UNIX にとっては小さい問題です。しかしながら、NFS サ ーバは大文字・小文字を無視した文字列比較ファンクションを使って、 簡単に名前を比較します。だから、「ls FileName」、「ls fileName」 及び「ls filename」は全て、UNIX 側で同じ情報を通知します。これは 危険な場合があります。例えば、「Makefile」と「makefile」が存在し ている UNIX ディレクトリがあるとき、NFS のマウントされた PC ファ イルシステムへそのディレクトリ全体をコピーすると、２つのファイル のうちの１つを破壊してしまうでしょう（最後にコピーした方が最初の ものを上書きしてしまうからです）。「．」（ピリオド）で名前が終わ るファイルでも、同様の問題が起こり得ます。Windows では「file」と 「file.」を区別する機能を提供しません。この点に注意してください。 可能であれば大文字・小文字を保存するので、少なくとも再帰的な前後 のコピーであれば大文字・小文字は保存されるでしょう。 メモリの使い方：NFS サーバは「Ｉノード」を保存しなければならないという事 実を除いて、かなり効率的です。それゆえ、ディレクトリシステム全体 が「Ｉノード」と共に格納されなければなりません。 必要メモリ量： 　　ファイル： ローカル名と１バイトのヌル文字 + 12 byte ディレクトリ： ローカル名と１バイトのヌル文字 + 28 byte 追加する作業領域の量は 250KB を越えません。メモリは必要の都度、動 的に割り当てられます。そして、ファイルやディレクトリが削除される とき、メモリは開放されます。 ファイルキャッシュ：ファイルをキャッシュしています。ファイルをキャッシュ せずにかなり効率的な NFS サーバを作ることはできません。ファイルの オープンとクローズに時間がかかるので、入出力操作が実行されるたび にファイルを開くという方式をとることは非実用的です（入出力要求バ ッファは、RPC の限界という理由で、サイズがおよそ 8KB に制限されま す）。そうすることは、恐るべき非効率を引き起こします。だから、私 達はファイルをオープンしたら、それらをオープンしたままの状態にし ておきます。最大３２個のファイルのオープンが保持されます。その数 が超えると、最後にアクセスされたファイルは閉じられて、新しいもの がオープンされます。あるいは、もしファイルの属性（アクセス権、サ イズ、オーナー）が変更されたら、そのファイルはクローズされます。 ファイルキャッシュもまた１分後に自動的にクローズしますが、いくつ かの NFS のイベントがサーバをチェックするためのトリガとなるように 提供されます（showmount でさえ、これを引き起こします）。これは問 題を生じさせることがあります。ユーザは、オープンされているファイ ルを削除することができません（UNIX 側を除いて）。もし、このような ことが起こるならば、UNIX 側で「touch」を使用するか、またはキャッ シュを閉じるのに PC 側で「showmount -e」を使用します。代わりに、 ユーザがファイルの最後のセクションを読むとき、ファイルを閉じるよ うにしてあります。だから、UNIX の「tail」はキャッシュを吐き出させ ます。これらの問題のどれかは特に影響があるという事はないでしょう が、あなたは困難が発生する可能性に留意しておくべきです。 書き込みバッファのサイズ：私達が注意を喚起したいことは、これらのファイル システムをマウントする時、１０２４バイトのサイズの書き込みバッフ ァを使うということです。いくつかのマシンでは、もっと大きいバッフ ァの方がよいでしょうが、１０２４という値で、すべてのマシンはかな りうまく動作します。バッファはクライアント側で設定されなければな りません。例えば、UNIX マシンでは mount -o wsize=1024 host:/c /usr/pc とした場合、ホスト名「host」のマシンの「/c」を「/usr/pc」にリモー トファイルシステムとしてマウントし、そして１０２４バイトのサイズ の書き込みバッファを使います。ＤＥＣの Alpha はこの設定に特に敏感 です。このオプションで、ＤＥＣではほとんど理論上の転送速度が出せ ます。それなしでは、再転送はシステムを速いモデムの速度ぐらいまで 遅くしてしまいます！ 属性のキャッシュ：ほとんどの UNIX クライアントが属性をキャッシュするので、 それらは、より少ししかサーバを呼び出さないようになっています。こ れは問題を生じさせることがあります。例えば、ＳＵＮのワークステー ションは、ディレクトリの変更時刻が変化したことが検出されるまでデ ィレクトリの再読み込みをしません。しかし、PC の場合、ディレクトリ の中のエントリが増えたり減ったりしても、ディレクトリの変更時刻は 変化しません。ＳＵＮワークステーションに強制的に属性キャッシュを 行わせないようにすることもできますが、私達は、ディレクトリの変更 時刻として現在の時刻が通知されるようにする方法を選びました。多く のクライアントは、NFS の「lookup」ファンクションが必要なものを返 すので、「getattr」を必要としません。だから、この奇妙な振る舞いに 気がつくことはありません。しかしながら、ＳＧＩのマシンは、両方の 機能を使います。（なぜなのか、だれが知っているのだろう）だから、 ＳＧＩのマシンはディレクトリの時刻が常に変化しているように表示し ます。しかし、いかなる重大な結果をもたらすようには思えません。こ うしなければ、ＳＵＮのクライアントは、キャッシュが掃き出されるま では、ファイルが追加されたか、あるいはファイルが削除されたか、と いうことを見る事ができません。後者の状況は前者よりもはるかに悪い のです。