NFSに見る古いコンピューター観
昔はネットワークというと、高価な専用ハードウェアで構成される、主に企業内の、ローカルネットワークのことであり、今のインターネットに見られるような、グローバルでオープンでパブリックなネットワークというものは、多くのコンピューター関係者が想定しなかった。
パーソナルコンピューターとその汎用OSが生まれたときも、そうである。
そして、それから半世紀経とうという今日においても、いまだに、“一般的なネットワーキング”は、業界、学会、ユーザー世界等々のコンピューター観において、そのほかの主要成分（中央演算装置、メモリ、ストレージ、各種I/O装置など）と完全に同列同格の一級市民と見なされていない。やむを得ず対応を要する、あとからやってきた、便利だけど厄介なよそ者、である。
この事情をもっと一般化していうと、コンピューターやOSの設計のベースとなる基本的なコンピューター観において、コミュニケーションがトップクラスの第一級市民と見なされていない、待遇されていない、となる。
それにまたインターネットと呼ばれる今日の圧倒的にデフォルトのコモンネットワーキングは、広域的なコミュニケーションを、今の自動車や航空機（物理的高速移動）以上に人類社会の重要な第一級機能インフラと見なそうした場合、その仕様はあまりに粗略すぎる。たとえば、これほどまでに毎日のように、セキュリティが大きなそして一般的な問題となりつづけているようなネットワーキングは、明らかに欠陥品である。車や列車や航空機は、ときどき大事故に遭遇するにもかかわらず、日常的にはまあ安全なものとして利用されている。そのレベルの安心感すら、今のインターネットにはない。
コモンネットワーキングのアーキテクチャは抜本的に再設計すべきであり、すでにそういう試みは各所にある。
ほんで、設計時点でネットワーク、ネットワーキングがハードディスク等と並ぶ第一級市民的要素と見なされていないために、今の広義のパーソナルコンピューターとそのOSは、ネットワーキングとコミュニケーションが大々的に一般化すべき近未来社会から見ると、きわめて、化石的に古く、不具なものなのだ。
というわけで、急に、話題はNFS(UNIX/LinuxのNetwork File System)に移ってしまうのだけど、これが実に、古めかしいクライアント/サーバシステムなのだ。そしてこれを、古めかしいクライアント/サーバシステムと呼ぶならば、今隆盛をきわめるWebも、そう呼ばざるをえないことに気づく。
最近はこのブログ上で、Ubuntu 16.04 LTSの再インストールの話、それに伴う、再インストールする前の旧HOMEのコンテンツに新インストールからアクセスする方法を、話題にしてきた。それは、旧HOMEのあるデバイスをetc/fstabに記述しておいて、その上の必要なディレクトリやファイルには、それらのリンク（UNIX/Linuxのシンボリックリンク）からアクセスする、という結論だった。
今回の話は、同一マシン上ではなく、先日引退していただいた、Ubuntu 14.04 LTS搭載機のHOMEにアクセスしたい、という話だ。ご想像通りこれはまさしく、ネットワーキングの話だ。
その、6年間使ったマシンのHOMEは、jオプションでtarした圧縮tarファイルでも20GB近くあるが、最初に考えたのは、それをDropboxに上げて、今のマシン上にダウンロードする、というアイデアだ。
しかしDropboxは、「アップロード終了まで9時間」と表示し、しかもその9時間表示が全然減らない。アップロードに9時間なら、おそらくダウンロードも9時間だろう。計18時間ではないか。しかも最初の計算通り行って、その時間だ。もっとかかる可能性の方が大きい。
そこでDropboxの利用はやめて、次は、splitコマンドで複数のファイルに小さく分割したのを、USBメモリスティックという小型トラックに載せて今のマシンに運び、catコマンドで再結合する、というアイデアを試みた。
しかし、それら、一つ一つが数GBある分割ファイルは、メモリスティックの容量に十分収まるサイズのはずなのに、「ファイルが大きすぎる」といってコピーを拒否される。3GBぐらいにまで小さくすると、やっとコピーは可能になったが、その“輸送”は、かなりの時間と手間になりそうだ。
そこで、最終的には、NFSの利用に落ち着いた。それは典型的なクライアント/サーバアプリケーションだから、ファイルをサーブする側（旧マシン）上にサーバーをインストールし、受ける側にクライアントをインストールする。
そしてサーバー上では、/etc/exportsファイルで、サーブするディレクトリを指定する。それはもちろん、問題の圧縮tarファイルのあるディレクトリだ。サーバーは、単純なアプリケーション名だけでは起動しない。rc.dなどによるシステムレベルの起動を、しなければならない。ネット上のいろんなページを見て、それらをお勉強した。
もちろん、旧機をしょうっちゅう動かしっぱなしにするなら、圧縮ファイルの作成〜ダウンロードなどせずに、単純に必要なファイルにNFSでアクセスすればよい。今回、引退機の常時稼働はなし！。
クライアントは、旧機がexportしたディレクトリを、こちらの適当なディレクトリへmountすることによって利用可能になる。mountコマンドのファイルタイプオプション-tはnfs、マウントターゲットデバイスは旧機のIPアドレスとexportディレクトリ名で指定する。-t nfsオプションでmountを起動したときの、エラーメッセージが正しい形を教えてくれる。
というわけで、1台のマシン上でなく、ネットワーク上の別のマシンとなると、その上のファイルへのアクセスが、急に面倒な作業になるのである。Webも、サーバーソフトとクライアントソフト（ブラウザー）が、内部で相当複雑な仕事をしている。その複雑さの規模たるや、（比較的単純な?）UNIX NFSの比ではない※。
※: Ubuntuのnfsパッケージは関連ソフトやそれらの構成・設定をインストール時に勝手にやってくれるので、見かけ上の単純さが実現している（参考ページ１、２）。「Ubuntu NFS」ではなく、「Linux NFS」で検索すると、NFS本来のややこしさが分かる。…今回の私の場合、NSFサーバーはUbuntu 14.04機だ。
どうして、ネットワーク上となると、急にこんだけ面倒になるのか？
ネットワークが、コンピューターシステムの第一級市民、ストレージなどと同格に、デフォルトの標準構成要素だったら、どうなるか。以下、読者には“1を見て100も1000も知る”ことを強制する、超簡単な骨格的書き方をしてみよう。
(1)クライアント/サーバシステムは要らない。たとえばメールなら、CPUとハードディスクの配線の長さが10センチなら、友だちのアキオくんのコンピューターまでの配線は数百〜数千キロメートルだ、と単純に考えればよい。xxxというファイルを、自機のmydirディレクトリに置きたいときはたとえば
cp xxx mydirだが、xxxファイルをアキオくんへのメールとして送りたいなら、
cp xxx /akio/mailでよい。cpは、Linux/UNIXのコピーコマンドである。ここでは実装詳細にはいっさい立ち入らないが、もちろんアキオくんは、あなたからのメールを拒否することもできる。このように単純なファイルアクセスですむならば、送るメールと並んで、取り寄せるメールも可能だ。
要するに特定のサーバーはいっさい不要で、ネットワークの構成員各自が、どんな形態の通信でも、まるでローカルのファイルアクセスなみに簡単に、できることになる。
(2)今みたいに私企業が社会ネットワーク（ソーシャルネットワーク）を名乗っているのは、ちゃんちゃらおかしい。人間のほぼ全員が参加している、グローバルでオープンでパブリックなネットワークそのものが、さまざまな社会的機能をもつ本物の社会ネットワークでなければ、ナンセンスである。
（つづく）
| 固定リンク | コメント (2) | トラックバック (0)
最近のコメント