OpenZFS on OS X (6) ファイル名関連の挙動

「ZFS on Mac」というタイトルで続けてきたこのシリーズですが、OpenZFS on OS Xの正式リリースに対応して改題しました。
本命中の本命ですし、ZFS on Macに「次」は多分無いでしょうから・・・

しかし長い名前ですね。長いのでOpenZFS on OS X＝OoO X＝O3Xという略称が提唱されています。
MacZFSの後継として名前を継承するか、OpenZFSの一味として名前を付けるかで若干モメたっぽいですが、OpenZFSを採ったようです。
（英語の微妙なニュアンスもわからない上、一番活発なircを見ておらずMLだけ斜め読みした感覚なので完全に余談ですが、旧来のMacZFSを開発してきた人達とZFS on Linuxベースで開発を進めてきた人達はあまり仲良くなさそうな気がします。まあMacZFS側からすると黒船襲来っぽい感じで（違うか）わからないでもないけど・・・）

さて、今回からはOpenZFS on OS X（以下O3X）について検証していきたいと思います。
思いつく範囲だと
・HFS+との差異
・ZEVOとの相互運用性
・ZFS on Linux等他のZFS実装との相互運用性
・netatalk+ZFS環境との相互運用性
こんなところでしょうか。

一番気になるのはZEVOとの相互運用性です。
というか、（一方通行な）ZEVOからの移行問題ですね。移行できればもうZEVOに戻ってくることはないので。

その他の相互運用性は蛇足ですが、トラブル時のデータ復旧などでは他のプラットフォームでマウントできた方が嬉しいことが多いです。
netatalk動いてるサーバーが死んだ際に取り急ぎHDDだけMacに繋いでデータが読めれば便利ですし、本家たるillumosで読める状態で運用できれば安心感が増します。
実際、ZFS on Linuxでresilverが延々繰り返されるトラブルに遭遇した際、OpenIndianaでimportしたら何事もなく完了した、なんてこともあったし。
このあたりについてはillumos・FreeBSD・ZoL・O3Xは共にOpenZFS陣営なのでfeature flagsの対応/非対応だけ注意してれば容易にimportできます。
-o version=28でzpool createしておけばSolaris11でも読めるはずです。

とりあえず今回の話題は（大して問題のなさそうな）ファイル名についてです。



ZEVOのときと同じようにcasesensitivityとUnicode normalizationについて見ていきたいと思います。
気を付けることは大体ZEVOと同じです。
結論から書くとcasesensitivity=insensitive、normalization=formDにしておこうということです。

まずcasesensitivityについてです。
ZEVOとの違いは本来のZFSで設定できてZEVOでできなかったcasesensitivity=mixedが可能になっているという点くらいです。
デフォルトはZEVO（というか通常のZFS）と同様にsensitiveです。HFS+を前提としたアプリ等で問題が起こる可能性を考慮すると、Mac専用データセットであればinsensitiveにしておいた方が良いと思います。

mixedについては正直よくわかりません。ZFSをファイルサーバーにするならmixedにしとけみたいに書かれているのを見たことはあります。
ファイル生成時の振る舞いはsensitiveと同じように思える（つまり、aaa.txtとAAA.txtの両方を作成できる）し、Oracleのガイドを見てもピンと来ません。mixedにした際、insensitiveな照合要求が来たとき、insensitiveにマッチするうちの1つを返すということなんでしょうか？（じゃあsensitiveではどうなるの？）
ちなみにO3Xで「aaa」と「AAA」というフォルダを作って試した結果、sensitiveであろうとmixedであろうと「aaa」でのFinder検索では両方マッチしました。しかしFinder検索とファイルシステムへの照合要求というのは別物の気がします。ファイルコピー/作成/変更ではsensitiveに振る舞うとして、insensitiveな照合要求とはどういうときに起こるんでしょうね？ファイルシステム・OSに詳しくないので残念ながらわかりません。
sensitiveなファイルシステムで起こる問題がinsensitiveな照合要求に由来しているとすると、mixedで解決する可能性もありますが、手軽に試せそうな例が思い浮かばないので断念。
Macで使うなら素直にinsensitiveにすべきでしょう。一方Unix/Linux界隈ではsensitiveが通常なので、それらとの相互運用を念頭においたデータ倉庫ならsensitive/mixedでも良いかもしれません。
「そもそもHFS+もsensitiveにしてるけど困ってないぜ！」って人ならsensitiveで。



次はnormalizationについて。
以下わかりやすさのためにNFC正規化後の文字を「が」、NFD正規化後の文字を「か＋゛」と表記します。
こちらも結論から書くと「noneはNG、formCとformDの差は見つけられず。とりあえずMacならformDでいいのでは？」ということくらいです。
なので以下主にformDで検証しています。



以前、「Macのターミナルはデータ的には正規化前の文字を保持するものの、表示上は全てNFCに正規化されてしまう」と書きましたがこれはMountain Lionでの仕様みたいで、Mavericksではそうではないみたいです。Lion以前でどうだったかはわかりませんが。
「が・か＋゛・神」のように記述したtxtをcatで表示した場合、Mountain Lionでは「が・が・神」ととなりましたがMavericksではそのまま「が・か＋゛・神」となり、どちらにも正規化されませんでした。というわけで、今回はlsした結果をいちいちtxtに書き出したりはせず直接見ています（書き出しても結果は同じ）。

今回もロクな論評ができません。
色々触ってみてわかったのが、「OS Xはチャンスがあればファイル名をNFD風に正規化しようとするっぽい」ということで、同じファイルを同じ手順で読んでもさっき「が」だったものが「か＋゛」になってるという具合であまり有用な結果が得られませんでした。

まず、Finderからファイルを作った場合ですがこれは問答無用でNFD風に正規化されるので検証不要です。またターミナルから「mkdir か＋゛」のように作ったファイルも当然そのまま格納されます。
そういったNFDで格納されたファイルは、HFS+と同じ挙動になるので問題ないでしょう。
normalization=noneだとNFCなファイル名にmvできるかも、という問題がありますがそもそもMacでnoneは推奨できません。

netatalkなら純粋なNFDではなくMac独自のNFD風正規化を行った上で格納してくれるらしいので、MacではなくUnix/Linux系のサーバーでnetatalkを動かす場合ならnoneでもいいかもしれませんが、その場合そのようなプールをO3Xでimportする際はreadonly=onとした方が無難かな？と思います（まあ鯖から引っこ抜いたディスクを繋ぐなら何にせよreadonlyでマウントした方がいいですが）。

NFCなファイルが作成されるのはターミナルから「mkdir が」のようにした場合です。
Finderからファイル名を取得（ファイル選択状態でcmd+C）すると他の場合と違いNFCな文字列が取得できるので、NFDに正規化されず格納されていることがわかります。
ただ、ZEVOと違ってlsではNFDな文字列が返ってきます。更に、Mavericksではlsを行った後Finderで再度ファイル名を取得すると今度はNFDな文字列が返ってきます。え？？？

ZEVOはMavericks環境で動かないため、同じMountain Lionで比較した場合、
Finderからのファイル名取得：O3X、ZEVO共にNFC
ls結果：O3XはNFD、ZEVOはNFC
という違いがあります。この挙動はちょっと謎です。O3XはそのままNFCで格納した上で、Unixなシステムコールに対してはNFD正規化して返しているのか？とも思いましたが、「が神」のような互換漢字入りのファイルは「か＋゛神」として互換漢字を維持して出力されます。これは純粋なNFDではなくMac仕様のNFDの挙動なので、OS X側の仕業だと思えるのですがそれだとO3XとZEVOで挙動が変わる理由がわからない・・・もしかしたら検証手順に不備があるのかもしれません。

更にMavericksではlsを行った結果Finderの取得結果も正規化されますが、これはMavericksになってからlsなどでファイル名を扱う度に積極的にNFD（風）正規化を行っていく仕様になったのだと思います。

ともかく、ターミナルから日本語ファイル操作を行わなければ問題はなさそうというのはZEVOから変わっていません。
ただ、normalization=noneだとターミナルからNFCなファイルを作った際にFinderから見えない、あまつさえターミナルからrmできない（＝OS X上で消す手段がない）というとんでもない問題が起こったので、formC/formDに設定しておくべきだと思います。


次回は拡張属性や相互運用性について。
予告しておくと、ZEVOでマウントしたデータセット上で設定したアイコン・ラベル等の拡張属性はO3Xからだと見えなくなるっぽいです・・・どうしよう。