特集
» 2006年07月31日 08時00分 UPDATE

Linuxの最新動向が一目で分かる:Ottawa Linux Symposium3日目:NFS、USB、AppArmor、LSBの話題 (1/5)

OLSの3日目は、NFSが最悪な理由、というセッションにはじまり、AppArmor対SELinux、LSBの最新動向など、注目のトピックが多く存在した。

[David-'cdlu'-Graham,Open Tech Press]
SourceForge.JP Magazine

Ottawa Linux Symposium:1日目

Ottawa Linux Symposium2日目:ユーザー空間は最悪、ほか

Ottawa Linux Symposium3日目:NFS、USB、AppArmor、LSBの話題


 4日間にわたる第8回オタワLinuxシンポジウム(OLS)の3日目、特に興味深かったセッションとしては、各種ファイルシステムを比較してそれぞれの利点を詳しく語った「NFSが最悪な理由」という講演、USBデバイスのリバースエンジニアリングに関するチュートリアル、SELinuxのライバルであるAppArmorの紹介、Linux Standard Baseの近況報告があった。

NFSが最悪な理由

 オラフ・キーチ氏による「NFSが最悪な理由(Why NFS sucks)」は、NFSとそれにはおよばないが競合するファイルシステムの多くを取り上げたもので、そのタイトルは今年のOLSの講演タイトルのパターン「〜が最悪な理由(Why ... sucks)」に従ったものである。

 最初に彼はこの発表のテーマは間違いなくNFSであり、ここではNFSがいかに素晴らしいファイルシステムなのかを紹介する、と講演タイトルと同様に大まじめに説明した。

 誰もがNFSに不満を抱いている、とキーチ氏は語り始めた。そのことを証明するために、NFSが優れていると思う人は手を挙げてください、と彼が出席者に向かって言ったところ、100人以上の出席者のうち3人だけが手を挙げた。SUSE LinuxディストリビューションのBugzillaには、さまざまな問題をまとめて表したバグとして「NFS sucks」というものがしばらくあったが、最近になって削除された、と彼はコメントした。

 続いてキーチ氏はもう少しまじめな口調でNFSの歴史を説明し始めた。1980年代前半、SunのもとにあったのはRFSという制限のあるネットワークファイルシステムだった。1985年、Sunは、NFSバージョン1の存在を公にすることなく、SunOS 2とともにNFSバージョン2をリリースする。1986年には、カーネギーメロン大学とIBMがAFSを開発。1988年、NFSバージョン2にキャッシュを整合させたSpitely NFSが登場する。その後の6年間は大きな進展がないまま過ぎた。1994年、Spitely NFSにクラッシュリカバリ機能が導入され、同じ年にリック・マケレム氏が4.4BSDとともにNot Quite NFS(NQNFS)をリリースする。1995年には、一般的な問題の除去版としてNFSバージョン3がリリースされる。1997年、SunはHTTPに匹敵するほど大きな扱いでWebNFSをリリースしたが、始めから相手にされなかった。そして2002年にリリースされたのが、「インターネットファイルシステム」と銘打ったNFSバージョン4だった。

 引き続き、キーチ氏はNFSバージョン2の基本的な点について説明を行った。NFSバージョン2はステートレスプロトコルである。これにより、クラッシュしてリブートまたは再起動した後も、サーバ、クライアントとも何事もなかったかのように処理を継続することが可能だ。NFSサーバがクラッシュした場合、クライアントはNFSサーバが再び動作するまで待ち続けるだけでよく、その後は元の状態で処理を継続できる。これがステートフルプロトコルだと、すべてのクライアントについて状態の記録および追跡をサーバが行う必要がある。ステートレスプロトコルはスケーラビリティの点で優れているのだ。

 NFSは、ほとんどどんなファイルシステムでもネットワークファイルシステムとしてエクスポートできる。これはNFSの大きな強みであり、特定のファイルシステムに固有のものでもない。

 ファイルには、その存続期間全体にわたって有効なファイルハンドルが必要になる、とキーチ氏は説明する。このやり方はinodeテーブルではうまく機能するが、新しいファイルシステムはもっと複雑である。ディレクトリは、その親ディレクトリ(..)のエントリを使って一連のエントリを再構築することができる。ファイルはinodeおよびディレクトリへのポインタになっている。なお、NFSの場合は、これらの識別子が変わる可能性がある。

 NFSは2049番ポートの監視を行う。NFSでは、ディレクトリマウント用のファイルハンドルの取得にはmountdへの通知が、接続するポートの取得にはportmapへの通知がそれぞれ必要であり、ファイルのロック、ステートレス状態でのエラー回復、クラッシュ後のロックの回復にもそれぞれ別のプロトコルへの通知が必要になる。新しい機能ごとに別のプロトコルを必要とするバージョン3以前のNFSの考え方に対して、キーチ氏は憤りを露にしていた。ただし、NFSバージョン4では大部分が改善されているという。

       1|2|3|4|5 次のページへ

Copyright © 2010 OSDN Corporation, All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ