先日、Adobe AIR Developers Nightに出席してきました。驚きあり笑いありの数時間で、終盤には開発者コミュニティを作ろうという話も。日本での盛り上がりが期待できそうです。

さて、今回はLeopardのファイルシステムについて。目新しい情報はないものの、周囲を見渡してみると……以前も紹介した「MacFUSE」を中心に、今後のOS Xにおけるファイルシステムのあり方/使い方を考えてみたい。

Leopardの胴体は羊で尻尾はヘビ?

キメラは、ギリシア神話に登場する想像上のモンスター。頭はライオンで胴体は山羊、しかも尻尾はヘビという動物分類学の範疇を超えた、というより常識ではありえない生物だ。筆者はキメラと聞くと、頭はハゲタカで胴体は蜂のようなドラゴンクエストのキャラクタを想像してしまうが、要は遺伝的に異なる生物が融合した生命体ということなのだろう。

振り返るに、我らがOS X。ここ数年、というよりMach ＋ BSD ＋ NEXTSTEP(OPENSTEP) ＋ Appleの技術の融合により誕生した経緯からすると、出自そのものがキメラ的といえなくもないが、一層その傾向が強くなっているように思える。

その理由として挙げられるのが、外部プロジェクトを利用した"接ぎ木"。LeopardにSolaris出自のファイルシステム「ZFS」の採用が取り沙汰されたことは、我々の記憶に新しい。RubyCocoaやRuby on Railsなど、Leopardでの採用が確定しているオープンソースソフトウェアも少なくない。印刷システムのCUPSに至っては、Appleにより買収されてしまった。

筆者が個人的に注目しているのは、ファイルシステムだ。Time MachineというLeopardの新機能は、おそらく高速なスナップショット(ある時点で存在したデータの集合)作成機能を必要とするだろうし、現在のHFS+を接ぎ木するにも限界があるはず。MacFUSEのように、ユーザランド上で動作するファイルシステムAPIも注目を集めている。Finderの機能が成熟した現在、ファイルシステムの強化がLeopard以降のシステムの課題なのではないだろうか。

ファイルシステムをキメラ化する「MacFUSE」

そのMacFUSEだが、Leopardに収録されるかどうかは別として、キメラ的に拡張可能という点がOS Xの路線と一致している。Spotlightの機能がFinderにマージされる「SpotlightFS」、NTFSを読み書きできる「NTFS-3G」など、実用性の高いプラグインも揃っている。MacFUSEの移植が始まってから日は浅く、速度面などクリアされるべき課題は多いが、OS Xに取り入れられたら便利なオープンソースソフトウェアの筆頭格だと思う。

実際、MacFUSEの機能を利用したファイルシステム(と呼ぶには若干語弊はあるが)には、ユニークなものが多い。以前取り上げたときに紹介しきれなかったものを、いくつかピックアップしてみよう。

iPodDisk

iPodDiskを利用してiPodをマウントしたところ。右のボリュームでは、サウンドライブラリが表示されていることが分かるはず

おもしろさでいえば、iPodDiskがイチオシ。iPodを接続した状態で起動すると、そのiPodに蓄えられたサウンドライブラリが、アルバム / アーティスト / プレイリストなどの基準で整理された状態でマウントされるのだ。もちろん著作権がらみで問題のないものを対象にすべきだが、iPod上の楽曲をMacにコピーしたいとき便利に使える。インストールも簡単、iPodDisk.appを適当なフォルダへドラッグ & ドロップするだけなので、MacFUSEを初めて使うユーザにお勧めだ。

UnionFS

複数のボリューム/ディレクトリを重ね、1つのファイルシステムとして扱えるUnionFSもユニーク。こちらで公開されているFUSE移植版「unionfs-fuse」は、そのままではOS Xでコンパイルできないものの、以下に示すとおりクイックハックを施せばOK。


$ curl -O http://podgorny.cz/unionfs-fuse/releases/unionfs-fuse-0.17.tar.bz2
$ tar xjf unionfs-fuse-0.17.tar.bz2
$ cd unionfs-fuse-0.17
$ vi unionfs.h

#define PATHLEN_MAX 1024
     ↓    ↓    ↓
#undef _POSIX_SYNCHRONIZED_IO    ←挿入する
#define PATHLEN_MAX 1024
$ make
$ sudo cp unionfs /usr/local/bin/

unionfs-fuseで2つの領域を重ねたところ。Windows的なフォルダ名とユーザフォルダの内容が入り交じっていることが分かる

unionfs-fuseの使い方だが、次のコマンド実行例を見てほしい。WINDOWSボリューム(/Volumes/WINDOWS)とユーザフォルダ(/Users)の2つを、～/IROIROフォルダを接続先にTEMPボリュームとしてマウントしているのだ。一見意味不明かもしれないが、読み取り専用領域と書き込み可能な領域を重ね、ファイルに対する変更があった場合は書き込み可能な領域に保存する、といった応用を想像してほしい。まさにキメラ的な使い方ができるファイルシステムなのだ。


$ unionfs -o volname=TEMP,ping_diskarb /Volumes/WINDOWS:/Users ～/IROIRO/