2013年8月4日日曜日

ZFS on Mac (4) ZEVOの問題点

前回までにMac向けZFSとしてZEVOの紹介や簡単な検証を行ってきたわけですが、何もかもうまくいくわけではなく多少の問題があることもわかってきました。
これまでの記事を読んで「ZEVO使えるかな?」と思って導入したら困った、という人が出ないようにZEVOのダメなところも気付いた範囲でまとめてみようかと思います。

その中でも特に大きかったのが前々回の更新から半年以上浦島太郎していたことによるZEVOを取り巻く状況の変化です。これについては後半に書きます。

まず手近なところで、使ってみて気付いたこと。

・HFS+で許容される長いファイル名が扱えない
ZEVO(というかZFS)におけるファイル名の最大長が255byteに制限されているため、最大255文字のファイル名が許容されるHFS+で扱えてZEVOでは扱えない長さのファイル名が存在します。

これはZFSがUTF-8によってファイル名を管理していることに由来していて、UTF-8では1byteで扱えない文字が多数存在するためです。というより、英数字や一部の記号を除いてほとんどの文字がUTF-8では2byte以上で表現され、カナや漢字は3byte(極一部4byte)で表現されます。
つまり、ほとんど日本語で構成されるファイル名の場合、90文字前後でも255byteに達してしまうためHFS+では見かけ上問題無いようなファイル名でもZFSでは扱えないことがあります(それでも255byteあれば問題となるようなファイルはほとんど無いでしょうが・・・)。

Mac、Windows由来でないファイルシステムの多くが255byte制限となっていることも考えると、そもそも255byteを超えるようなファイル名を付けないことが賢明でしょう。


ちなみにHFS+のファイル名を最大255文字までと書きましたが、正確にはUTF-16の1ユニットが最大255個です。つまり、Unicode上では合成によって表現するNFDな文字は複数ユニットとして計算されます(「か+゛」の「が」など)。また、Unicodeコードポイント上は一文字であってもUTF-16の1ユニットで表現できないサロゲートペア文字は2文字としてカウントされます。
サロゲートペア文字がファイル名に使われることはほぼ無さそうですが、HFS+がNFD(もどき)を利用する関係上、カナの多いファイル名は必ずしも見かけ上255文字未満で制限に達することがあります。


・フォルダのカスタムアイコンがFinderで表示されない
結構痛い問題として、ZEVOボリューム上ではフォルダに適用したカスタムアイコンがFinder上で表示されないという問題があります。クイックルックでは表示されます。また、cmd+Iでは名前の横には表示されず、プレビューには表示されます。
ZEVOボリューム自体のボリュームアイコンや、ファイルに適用したカスタムアイコンは問題無く表示されます。そのため、つい最近まで気付きませんでした(前回のテストはファイルにアイコンを適用していた)。恐らく原因はそれぞれのカスタムアイコンの表示方法の違いだと思います。

まず、ファイルに適用したカスタムアイコンは前回説明したとおりリソースフォークに格納されます。一方、ファイルではない(リソースフォークを持てない)フォルダやボリュームは別の方法でアイコン情報を保持する必要があります。そこでボリュームではルートフォルダに「.VolumeIcon.icns」というファイルを配置し、フォルダでは「Icon^M」(^Mは表示される文字ではなくU+000Dのコントロール文字CR)というファイルを配置しています。なぜボリュームとフォルダで仕様が違うのかは正直わかっていないのですが、このIcon^Mが問題のようです。

.VolumeIcon.icnsは、先頭にドットを配置することで不可視にしているだけで通常のアイコンファイルです。しかし、Icon^Mはアイコンファイルではなく、リソースフォークに(通常のカスタムアイコン適用ファイルのように)アイコン情報を持っている空の不可視ファイルです。
本来はこのIcon^Mファイルのリソースフォークを読んでアイコンを表示するはずなのですが、ファイル名にコントロール文字が含まれているのがまずいのか、非HFS+のボリュームなためFinderがAppleDoubleの「._Icom^M」を探しにいってしまうのか(ちなみに手動で置いても無駄でした)、ZEVOの問題かFinderの問題かはわかりませんが表示されませんでした。

というわけで対策は不明。カスタムアイコンを多用する人にとっては致命的かと思います。


ここから後半です。しばらく見ないうちにZEVO、というかZFS on Macを取り巻く状況が(主に好ましくない方向に)変わってきているようなのでわかった限りでまとめてみます。
ここ半年ほどの間にここまで色々変わっているとは正直思っていなかったので、以下に書くことを知ったのも昨日の今日といった感じだったりする。

率直に言って、ZEVOの開発は停滞しているようです。
まずZEVO CE自体が昨年(2012年)9/23にリリースされた1.1.1からアップデートされていません。とってもstableだからというよりは開発が止まっているようです。初期バージョンの1.1が2012/9/15リリースなので、リリース直後の細かいbugfix以外何もされてないと言える状態です。

元々、Ten's Complementで開発中のまま死に体となっていたZEVOがGreenBytesに買収されてZEVO CEがリリースされたわけですが、リリースからしばらくすると公式フォーラムでも中の人は音沙汰が無くなり、今ではGreenBytesもZEVOの買い手を探しているような状況らしく、もはやGreenBytesはZEVOに興味を持っていないように思えます。あまりちゃんと調べられてませんが、Ten's Complement時代からのメインの開発者も既にGreenBytesを離れているらしい。

恐らく、ストレージ屋さん?のGreenBytesとしてはエンタープライズ市場にMac+ZFSというパッケージを売り込むことを目論んでTen's Complementを買収したのでしょう。この時点でTen's ComplementによるZEVOのリリースは(ほぼ使い物にならないSilverのみで)止まっており、このまま店じまいとなると「ZEVO is dead」と喧伝される恐れがありました(というか実際そう言われていた)。そのためGreenBytesは取り急ぎ買収時点での成果物(のうちZFSとしてのコア部分)をCommunity Editionとして公開したんじゃないかと思います。

公開時点ではCEのフィードバックを元に信頼性を製品レベルに向上させ、いずれは管理ツールなども含めたパッケージとして売っていく目論見があったのでしょうが、CEへのフィードバック・市場動向などを鑑みてZEVOがビジネスにならないと判断されたというところですかね(妄想)。
ともかく、新たな買い手が見つからない限りZEVOのアップデートは行われないでしょう。このシリーズの最初の記事ではソースが公開されたと書いてしまいましたが、どうやらライセンスに従いつつもOS Xへのportに関わる肝心な部分が巧妙に分離されたソースだったようで(要はゴミ)、このソースを元にしたコミュニティベースでの開発には期待できません(というか、それならMacZFSがある)。

更新の無いソフトウェアとは嫌なものですが、とりあえずちゃんと動いているならまだなんとかなります。しかし、重大な問題としてZEVOはOS X 10.9 Mavericksでは動かないらしい。これは致命的。
しかも10.9から導入されるKext Signatureの問題ではなく、かなりちゃんとした修正が必要なレベルのようです。せめてGreenBytesが10.9に対応させたZEVO CEをリリースしてくれれば当面の問題は回避できますが、現在のGreenBytesのやる気と開発者がいるかもわからない状況を考えると望み薄です。つまり現時点でZEVOを導入するとMountain Lion以降にアップグレードできない恐れがあります。

となると座して死を待つしか無いのか、というともしかしたらそうでもないかもしれない。
どうやら長らく更新の無かったオープンソースのMacZFSの開発が最近活発化してきているようです。stableは依然非常に古いバージョン8ですが、alpha版としてZFS on Linuxのコードを利用(?)し最新のv5000(後述)となったZFSが開発中のようです。こちらは既に10.9でも動いているようですし、OSSなのである程度の継続性は期待できます(まあ、以前のMacZFSのように長期停滞に入る可能性もありますが・・・)。
stableのMacZFSではZEVOで作ったv28のプールはimport不可ですが、v5000対応のalpha版MacZFSならZEVOのプールも恐らくimportできるはず。
alpha版MacZFSに関しては今後(今度こそ近いうちに)また検証したい。
10.9への移行期までにこちらがstableになることを祈りたい。

ちなみにv5000という大きなバージョンについてですが、これは本家Solarisとの複雑な関係によるモノです。
まず、本家SolarisのZFSはv28を最後にそれ以降はクローズドソースになってしまったのでv29以降のZFSは他のOSへ移植することができません。しかしv28のまま停滞してしまうとまったく機能追加ができないという問題があります。
かといってそれぞれの移植プロジェクトが勝手にv28ベースで機能追加をしてしまうとそれぞれのプール間で互換性が無くなってしまう(=ZFS「風」の非互換なファイルシステムが複数乱立してしまう)ので、OSS版のZFSはv5000という適当なバージョンに統一して旧来のZFSバージョン管理を捨て、feature flagsという別のパラメータを導入して個々の新機能(feature)を独立して扱うようになりました。
feature flags導入により、プール作成時に個々のfeatureを個別に有効/無効化できるので、それぞれのZFS実装で対応しているfeatureに差があっても無効になっていればimportできるようになりました(多分)。
もちろんfeature flagsはOSSオリジナルの仕組みなので、本家Solarisとは互換性はなくなりますが仕方ないでしょう(相互運用する場合は双方v28でcreateすれば良い)。
長い余談でした。

とまあ、随分ネガティブな内容になってしまいましたがおおむね現状はこんな感じです。
それでも、現時点で新しくてstableなZFSはZEVOになるので、ZFSを使うならばZEVOを導入してv5000対応のMacZFSがstableになるのを待つことになりそうです。
私自身結構大きなストレージをHFS+からZEVOに移行したりして後には引けなくなっているのでw、これからも色々と戦って(?)いきたいと思います。

0 件のコメント:

コメントを投稿