24日(木)おぉ、まったり
本原稿、扉カラー、全部アップ完了。
おつかれおつかれ。
ありがたいことにまた次お願いします、ということなので引き続き次回作を描く。
次もやはり時間が止まる時計らしい。
で、スポーツ選手関係でよろしく、だそうである。
うーむ……
というわけでやっとぼちぼちと暇になったので部屋の大掃除を久しぶりにちょっとだけした。
気持ちよい。
バンブル工作環境もなんとかしないといけないがおいおいやるとしよう。
ファイルサーバ機とThinkPadX300において、Slamd64とSlackware64と自家ビルドの混ぜ混ぜパッケージ環境だったのを Slackware64に統一。
kernel、Xorg、KDE4とgtk関係は先行しているので自家ビルドのまま。
移行による混乱で拒否反応が所々に出たが、なんとか収束できた。
これでslackpkgで楽々アップデート生活に復帰である。
DDR2 4GBモジュールがだいぶ安くなったのでファイルサーバのメモリを4GBx2の8GBにした。
その有り余らせたリソースをsshのX11フォワーディングやらTurboVNCを使ってX300からリモートで活用中。
TurboVNCのデスクトップ環境はLXDEにしておいた。
仮想PC上の saiでカラー扉絵600dpiをいじくるのにX300だとぎりぎりスワップが始まってしまうところ、余裕で編集可能であった。
しかし TurboVNCすごいネェー、ローカルで触ってるのとほとんど変わらない。
詳細は
VirtualGL参照。
元々はSunのカスタムVNC製品だったそうな。
Sun……。
唯一困る点はXvncが古いためにリモートでvmwareを起動する場合、キーボードのマッピングを自動で読んでくれないところだが絵を描く分にはあまり関係ないので放置のまま。
ZFS話。
およそ半年ほどzfs-fuseでファイルサーバを動かしてきたが、概ね良好である。
非常にごくまれにファイルアクセス高負荷時にシステム丸ごとハングすることがあるくらい。
……というのがタイミングによっては結構かなわんので、そろそろ別手段の実験をしてみようということでLinuxにおけるZFSの現状を調べてみた。
別手段は
zfs linux portか、仮想PC上でzfsが使えるOSを動かすくらいしかない。
zfs linux portは最新コードだとようやく通常のzfsのファイルシステムをマウントできるようになったらしく喜び勇んでインストールしようとしたが、よく gitwebを見ると危なっかしいコミットがいまだにあったり、プールのscrubが実質うまく動かない(KQStor版も同じらしい)、などという情報を見かけたのでやっぱり中止。
仮想PCの方ではFreeBSDは8.2R、9共にzfs-fuseよりもzfsバージョンが「そんなに低かったっけ?
(つか覚えとけ)」というくらい低かったので断念。
ということで今 OpenIndiana148テキストインストール版を仮想PCへインストール中……だが、ものっすごく遅い。
アヤシイ。
インストールが完了したので、早速実ドライブのプールをimportしてsmbshareで共有開始。
この辺はさすがに便利である。
仮想PCのネットワークはブリッジ。
しかし、収納してあるファイルをX300へ試しに転送してみると2〜3MB/sしかでない。
一旦 exportしてホストからzfs-fuseでいつも通りimportして、キャッシュ効果を避けるため別のファイルを同じく転送してみると5〜7MB/s出る。
過去の自分
メモ (deleted)によると、
Fileserver(FreeBSD-8.0) -> Linux@ThinkPad X300 4〜6MB/s
Fileserver(osol-dev-134) -> Linux@ThinkPad X300 5〜7MB/s
らしい。
少なくともLinux+zfs-fuseはOpenSolarisネイティブホスト時と同じ速度が出るようだ。
んー……仮想PCの場合の速度低下の原因は何か?……って調べるのも面倒だし、そもそもやはりホストLinuxが起動してから vmware起動させて、仮想PCのOpenIndiana起動させて……とかやってられんわな。
次回メジャーアップデートに期待しつつ、素直にzfs-fuseを使い続けよう。