PX-Q3PEを使った録画サーバで1番の問題はdisk I/Oという考えに至りつつある。BSはわりときれいに録画できるんだが、地上波の方はdisk I/Oがノイズに影響している可能性が高い。録画領域をGlusterFSのSATAディスクから、OS領域に使っているM.2のSSD領域に移動させることを検討。ホストOSとゲストOSで、それほど大きくないSSDを切り刻むのは出来れば避けたい。ホストOSのファイルシステムをゲストOSに解放するため、VirtFSの設定を行うことにした。前回、ホストOS側の設定が終わったので、今回はゲストOS側の設定を進めていく。
ゲストOSはCentOS6.7。ホストOSから9pnet_virtioで解放されたファイルシステムを、9pでマウントしたい。9pのファイルシステムに対応していなければお話にならないので、kernelを対応させる。menuconfigを探すとFile Systems＞Network File Systems＞Plan 9 Resource Sharing Supportが見つかった。これだけのためにCentOS6の物理OSを準備してmakeしてみる。ごちゃごちゃエラーが出たので、幾つかのsignatureチェックを無効にして、ようやく成功。出来上がったkernel moduleをゲストOSに移動させて、insmodしてマウントしてみる。
insmod /usr/local/src/9p.ko
mount -t 9p -o trans=virtio data /data
mount: data: can't read superblock
まだ、うまくいかない。。。調べてみると『/sys/bus/virtio/drivers/9pnet_virtio/virtio/mount_tag』というファイルに、解放したファイルシステムのタグが記載されるらしいが、そもそもこのファイルが存在しない。悩んだ挙句、海外のフォーラムで最も成功例の多そうな方法を取る。githubにあるcentos6用のcentos-9pというドライバを使って見る。これはCentOS6.5限定のものらしく、試しにCentOS6.7でbuildしてみたが失敗。OSのバージョンを細かく限定されるのは不服だが、どうせPX-Q3PEのせいでCentOS6限定になっているので、あまり気にせずCentOS6.5にデグレード。以下の方法でドライバをインストールした。
cd /usr/local/src
wget https://github.com/antst/centos-9p/archive/master.zip
mv master centos-9p-2.6.38.5.zip
unzip centos-9p-2.6.38.5.zip
mv centos-9p-master /usr/src/centos-9p-2.6.38.5
yum install -y --enablerepo=epel dkms
dkms add centos-9p -v 2.6.38.5
dkms build centos-9p -v 2.6.38.5
dkms install centos-9p -v 2.6.38.5
dkms status
ここまで設定してOSを再起動する。起動後に先ほどのmount_tagファイルを確認すると、解放したファイルシステムのタグがきちんと記載されていた！期待に胸を膨らませてマウントしてみると・・・成功！何とかCentOSでもVirtFSが使えるようになった。が、ホストOS側で書き込んだファイルをゲストOSで参照することはできるものの、ゲストOS側からファイルを書き込むことができない。ホストOS側のlibvirtdサービスを起動しているユーザーに依存しているようなので、qemu.confでrootに変更。libvirtdを再起動してゲストOSを再起動すると、ゲストOSでもrootでなら書き込めるようになった。ゲストOS側でどんなにパーミッションを解放しても他のユーザーでは書き込めないのでphp-fpmもrootで動くように変更した。
ちなみにマウントしているにもかかわらず、dfの結果には入ってこない。全然使っていないにもかかわらず、なぜかディスク容量監視には引っかかってしまうし、どうにも癖のあるファイルシステムのようだ。ちょっと嫌な感じがしつつもゲストOS側でVirtFS領域に録画ファイルを書き出して、それをホストOS(skylake centos7.2)でQSVエンコードするという環境を実現できた。我が家の環境でSSDを使う仕組みにおいては、最もファイル移動を押さえられる構成だ。
しかし、肝心の地上波ノイズは完治には至らなかった。結局のところ、SSDからSATA領域にデータ移動させる必要があるため、そのI/Oが干渉してしまっているのかもしれない。データ移動を発生させないためには、最初から巨大なストレージに置く必要があるため、やはりGlusterFS上に録画するのが1番ということになる。しかし、localにbrickがあると、そのI/Oが干渉となってしまうため、GlusterFSサーバとは別サーバとして録画サーバを構築する必要がある。
結局またもSH67H3を引っ張り出して、録画環境はそちらへ移植。ファイルサーバと録画サーバを完全に分離することにした。それでも地上波ノイズは皆無とはならない。1時間の番組を見ていると何回かはノイズが入る。ファイルサーバ側の処理に影響を受けているからか、ある時間に集中してノイズが入るような状態も確認した。ストレージも含めて録画サーバ専用構成を取るのが最もノイズを抑えられるのかもしれないが、エンコード処理との兼ね合いもあって、うちではGlusterFSをストレージとして使い続けることにした。