iPod セントリックなオーディオ環境の構築
iPod/iTunes を中心としたオーディオ環境の構築がやっとひと段落ついたので、経緯等をまとめておこうと思う。
ちなみに、色々試行錯誤した過程に関しては、うろ覚え／記憶違い／調査不足等で嘘を書いてしまっているかもしれないので、参考にする場合は要注意ということで。
仮想マシンの起動／停止契機
元々の目論見は、バックアップとかの利便性を考えると、仮想マシン上の Solaris から ZFS を CIFS 共有させて、その上に音楽 CD のリッピングデータを格納するのが良かろう、というモノ。
iTunes は:
- フォルダ名／ファイル名に空白文字とかも使う
- 曲名／アルバム名／アーティスト等の設定を変更 (ネット経由で取ってくるデータの品質は結構アレなので....) すると、フォルダごと改名される
という挙動なので、tar とかのオールドスクールなツール類でのバックアップはちょっと心配なのだ。
で、諸々の手間を考えると、Windows へのログイン時点で仮想マシンを起動しておきたいところ。
一番簡単なのは、「スタートアップ」に起動用バッチファイルを放り込んでおく方法なのだけど、この方法だと「ログアウト時に仮想マシンの状態を保存して終了」に相当する契機が無い。
あ、「電源断」ではなく「状態保存終了」にしたいのは、次回ログイン時の起動を短時間で済ませるため。流石に毎度毎度ブートシーケンスを律儀に実行するのは馬鹿らしいので。
で、色々調べてみたところ、「ログイン」「ログアウト」契機での処理の自動実行は、グループポリシー機能を使って実現出来るらしいとのこと。
仮想マシンの起動／状態保存終了を行うバッチファイルを、それぞれ「ログイン」「ログアウト」時挙動として登録し、早速ホスト (＝ Windows) にログインしなおしてみると....おぉ！立ち上がってくる！ ＞ 仮想マシン
次にログアウト挙動も確認すべく、もう一度ホスト側でログインしなおしてみると .... おぉ！仮想マシンの状態が復旧 .... あれ？状態復旧じゃなくて、これ、完全に電源再投入相当の挙動じゃねぇ？色々確認してみたが、やっぱりゲスト OS がリスタートされているっぽい。
自動実行の挙動を色々調べた結果:
- 「ログアウト」時処理は、実行中アプリケーションに「終了要求」イベントが通知された後で実行されるので、「終了要求」契機で電源断処理を実施してしまう仮想マシンには、「ログアウト」時処理での状態保存は間に合わない
- 「ログイン」時処理における環境設定 (環境変数やプロファイル設定等) が、ログイン後のそれとは微妙に異なるらしく、「ログイン」時処理で起動した仮想マシンの状態が、管理コンソールからは正しく認識できない
という感じで、かなり散々な状況。
前者に関しては、自動停止を完全にあきらめるしか手は無いなぁ。「終了要求」イベントに対して「状態保存」を選択するようなオプション指定が VirtualBox にあれば良いのだけど、パッと見た限りでは見当たらないし....
後者に関しても色々手を尽くしてみたのだが、やっぱり駄目そう。
環境変数操作等に関してはバッチファイルだと埒があかないっぽいので、ウェブ上の情報を頼りに PowerShell とかにも手を出してみたけど、結局上手く行かない。下手に HOME 環境変数設定を無効にすると、子プロセスどころか、システム全体の HOME 設定が無効化されてしまうし....
ちなみに、「スタートアップ」経由で仮想マシンを起動した場合も、極稀に管理コンソールから仮想マシン状態が正しく認識できない事があったので、Windows の起動プロセスにタイミングクリティカルな部分があるのかも？
＃ 環境変数とかプロファイル設定周りとか？
っつーことで、ホストへのログイン時の仮想マシン起動は「スタートアップ」経由、ログアウト時の状態保存終了は手動で行うことに。なんか格好わりーなー、もう！
リッピングデータの格納先変更
iTunes は「マイミュージック」配下に作成した iTunes フォルダの下にリッピングしたデータやアルバムアートワークを保存するので、出来ればこのフォルダ配下を丸々 CIFS 共有領域に移動してしまいたいのだが、iTunes の設定で格納先を変更できるのはリッピングデータだけ。
楽曲情報とかアルバムアートワークとかがローカルにしか置けない＝バックアップしようとするとワンクッション必要なのは、ちょっとよろしくないなぁ。ということで、何か上手い方法は無いものかと、ネットの海を彷徨うこと暫し。
どうやらフォルダリダイレクトなる機能を使って、マイミュージックとかを丸ごと別な場所に「リダイレクト」してやると良いらしい、という情報を得る。
試しに適当なローカル領域に対して、マイミュージックのフォルダリダイレクト設定をした上で、iTunes でリッピングしてみると....おぉ！リダイレクト先に書き込んでるっぽい！これ、いいんじゃない？ ＞ フォルダリダイレクト
じゃぁ、ひと段落付いたところで今日はログアウトするか .... あれ？「同期中」とか表示されるって事は、ひょとしてファイルシステムの flush がこのタイミングで実施されてる？
ぎゃー！それ駄目じゃん！ログアウト契機で書き出しの可能性があるなら、ログアウト前に仮想マシンを停止させられないじゃん！
Solaris ホストで Windows ゲストなら、Windows 側ログアウト時点でも CIFS サービスが動いているんだけど、その構成は使い物にならないことがわかっているからなぁ .... orz
しかも、色々試してみた限りでは、リダイレクト先のデータの増加に伴って、ログアウト時の同期に要する時間がグングン増えている感じ。
ファイルシステム実装者として想像するに、それってメモリ上にがっつりキャッシュしてる＝空きメモリを食いつぶしているってことじゃねぇの？っつーか、同期遅延によって性能を担保するのは良いのだけど、それにしたってバックグラウンドでよしなに書き出しておいて欲しいんだけどなぁ。
ひょっとしたら、キャッシュ内容とリダイレクト先との間で、所謂 stat 情報の突合をやっている (NFS とかは size/mtime 属性で改変の有無を判定したりする) だけで、「同期」とは言ってもデータの書き出しは発生していないのかもしれないけれど、それにしたってファイル数が増えた状況におけるログアウトに要する時間の増加は、ちょっと耐えられないレベルだ。
ということで、あきらめてリッピングデータのみを CIFS 共有領域に格納することに。
ちなみに、今回 450 セットほどの CD をリッピングしたのだけれど、半数近くはアルバムアートワークを手動で設定 (主に amazon.com/co.jp から入手) ＆ CIFS 領域に保存したので、まぁ、リッピングデータの格納先変更だけでも良かったのかも？(笑)
仮想マシンの状態復旧タイムラグと、iTunes の保存挙動
先述した通り、仮想マシンは「スタートアップ」経由で立ち上げることになったのだが、CIFS 領域を「ネットワークドライブ」として恒常的にマウントする設定にしてあると、「ログイン → 仮想マシンの状態復旧」のタイムラグがそこそこあるため、ログイン時には概ね「ネットワークドライブのマウントに失敗」する事に。
かといって、ログインの度に、いちいち手動で再マウントする、という運用はちょっとあり得ないので、恒常的なマウントにせざるを得ない。
今、この文書を書いていて思いついたけど、実は iTunes 側での "iTunes Media" 設定 (＝ リッピングデータ保存先設定) に UNC パス表現が直接使えたりする？あぁ、それは素敵な話だけど、今になって変更の可否を試すのは勘弁して欲しいなぁ (^ ^;;;;)
話を戻すと、仮想マシンが立ち上がってしまえば、その後のアクセスに問題は無いので、NFS 的に言えば「hard マウント」(＝ 成功するまでひたすらアクセスし続ける) してくれれば良いのだけれど、Windows は (「iTunes は」？) そのようにはなっていない模様。
「ネットワークドライブのマウントに失敗」した状態で、iTunes でリッピングを実施すると、明示的に設定した格納先である CIFS 共有領域ではなく、デフォルトの格納先である「マイミュージック\iTunes\iTunes Media\Music」配下にデータを書き出し始めてしまう。
その一方で、例えば仮想マシン起動後にエクスプローラ経由で明示的に CIFS 共有領域をアクセスするなどして、「ネットワークドライブのマウントに失敗」状態が解消された後でリッピングを行うと、CIFS 共有領域配下にデータが書き込まれる。
つまり、CIFS 共有領域配下とデフォルト格納先の２箇所にデータが分散してしまう、というイヤーンな状態に .... orz
この状況に気が付いたのが、100 枚単位でのリッピング作業を済ませた後だったので、流石に「正しい手順でもう一度最初から」という気分にはなれない。
なんとか格納先を移動させる算段を考えよう、ということで、メニューやら設定ダイアログやらを眺めていると、「編集 → 設定 → 詳細」の先に「ライブラリの追加時にファイルを iTunes Media フォルダにコピーする」なる設定項目が！
これだ！ということで、この項目をチェックしてから、件のデフォルト格納先に対して「フォルダをライブラリに追加」を実施 .... おぉ！CIFS 共有領域にどんどんファイルが取り込まれて行く！
で、取り込みが完了したなら、「マイミュージック\iTunes\iTunes Media\Music」を別な場所に移動 → Windows を再起動した上で、後から移動させたデータを iTunes が正しく認識していることを確認してみる。Windows ごと再起動したのは、裏で iTunes 関連のプロセスが動いていて、変なキャッシュ等が働くのを予防するため。
「マイミュージック\iTunes\iTunes Media\Music」配下にデータが無いことを確認した上で、iTunes から移動させたアルバムの表示＆再生をしてみると .... よし！上手く行った！各曲のプロパティを見ても、ファイルの位置が CIFS 共有領域になっているから大丈夫っぽい。
ということで、iTunes 起動前には必ず CIFS 領域がアクセス可能になっていることを確認する手順を実施することに。自分で環境設計しておいて言うのもなんだけど、ホント、面倒臭ぇなぁ〜。
ZFS バックアップ
音楽 CD の取り込み過程で、適宜 ZFS のバックアップを実施してみる。
基本的には、仮想マシン上の "zfs send" と、バックアップ用のディスクサーバ上での "zfs receive" を ssh で繋いでやるだけの簡単な作業。
「簡単」とは言っても、仮想マシンが稼動しているホストマシンとディスクサーバ間は、無線 LAN 接続なので、転送完了までそれなりに待つ必要がある。
今回は最終的に 120GB 弱のデータ格納が必要だったので、都度丸ごとバックアップしてたら、最後のバックアップデータの転送に要する時間はちょっと想像したくない。ZFS ではスナップショット間でのインクリメンタルなバックアップ (＝ 差分データのみの転送) が可能なので、随分と救われる。
ちなみに、ネットワークデバイスとして USB の 802.11n WiFi アダプタを使用しているのだが、ガチでデータ転送している際には、USB 接続しているマウスの即応性が話にならないレベルまで低下。どちらの機器もハブを経由せずに PC 本体に直結しているのだが、やっぱり別コントローラに分けてやった方が良かったのか、はたまた、既にバス幅があふれているのか。「CD を焼いてる最中はマウスに触るの禁止」的な 20 世紀を思い出してしまった(笑)。
ユーザ ID の統一
ZFS でのバックアップが完了してから、ディスクサーバ側でデータの確認をする事に。
.... あれ？「権限が無ぇ」とか言われるぞ？
あ！しまった！仮想マシン上のアカウントと、ディスクサーバ側のアカウントでユーザ ID がずれてるんだ！ギニャー！失敗した〜！
.... root 権限を使って、バックアップの妥当性も一応確認できたから、まぁ、いいか。これから設定を弄くりまわすのも面倒だし....
とりあえず、ファイルやディレクトリそのものに対するアクセス権限が無くても、ファイルシステムとしてのバックアップは実施できてしまう ZFS スゲー！的な感じ(笑)。
環境構築を終えて
リビングに ND-S1 + デジタル入力付きのアンプ、寝室に MXSP-2200 を置いた事で、所有している全音楽 CD を何処ででも再生できる環境が完成。
いやぁ、ディスクを入れ替える必要が無いってのは便利だね。iPod 使用が前提になるから、メディアを「再生機器の近辺」に置いておく必要も無くなるし。
CD 時代と比較して、唯一使い勝手が落ちるのが、アルバムの参加メンバーをその場で確認出来ないことぐらいかな？
お金持ちのオーディオマニアなら、「iPod を持ち歩くのは面倒」とか言うことで「メディアサーバマシンを立ち上げておいて、全ての部屋で AirPlay による再生」なんていう環境を構築するのかもしれないけれど、音響的にアレな木造アパート暮らしの身としては、そんな過剰を投資しなくても、これぐらいの環境で十分ということで(笑)。
ちなみに、週一ぐらいの頻度で classic iPod がフリーズするんだけど、これってどうにかならないんでしょうか？ ＞ apple
