T221をフル解像度で使うと文字にゃどが細かすぎて見えにゃい！という一面がある。例えば日頃は外観さえ見えればよいリモートモニタ画面にゃどを置いておくのに非常に便利だが、いざ操作仕様とすると顔を近づけにゃければにゃらにゃい。それがイヤにゃらその窓を通常のモニタに移動してくることににゃるが、Win7だとWin+＋でお手軽にズーム出来るのが便利だ。
　ClearTypeそのままで拡大されたりとかベタにゃあたりが萌え。にゃにかマウスの拡張ボタンに割り当てておいても良いかもしれにゃい。
　尚、全画面表示以外ではモニタ境界でちらつくとかマウスカーソルが重くにゃるとか実用ににゃらにゃい。

　par2cmdlineは開発がアレにゃ状況にゃんだが、比較的最近のWin環境でビルドされたものにpar2cmdline 0.4 with Intel Threading Building Blocksがある。
　メインのthreadingに関しては-t-で無効化して使っちゃうわけだが、日本語ファイル名とかあちこち不具合解消されて良質。
　といいたいところだが、ふと実験してみたらリペア中にRS computation error.とか吐いて落ちやがる。リペアできにゃくてどうするよ！ちうわけで、やはりガチにゃのは本家のpar2cmdlineにゃのかもやしれにゃいが、ここにいたって全ファイルをln longfilename file1にゃどとしては超絶に遅い本家でcreateしろというのは痛いわけで、一応par2+tbbのx64版だとエラーで落ちにゃいようにゃ気がする程度までは確認した。が、んにゃ巨大データでいちいち確認してられにゃいのでちょっとこまった話である。

　Win7で
　md "neko.{ED7BA470-8E54-465E-825C-99712043E01C}"
　してeで開くと各種設定の一覧が出るというネタ。
　網羅されてにゃいあたりが微妙だがどこに何があるのか分かりにくくにゃってたので多少の助けにはにゃる。
　尚直接は操作出来にゃいので実用を求める向けにはregで保存が楽。

　Win7でいろいろ増えたので検証してみる。ウィンドウが画面の上に移動されたとき自動的に最大化するとか、最大化した窓を移動させようとしたら元のサイズに戻るとか、移動中に誤動作してアクティブウィンドウ以外が最小化された上に復元すると別モニタに変にゃサイズで復帰するという、開発者は脳に虫でも涌いてるんじゃにゃいかという糞仕様のために速攻でOFFにしたAero Snapという名の「コントロール パネル\すべてのコントロール パネル項目\コンピューターの簡単操作センター\マウスを使いやすくします\ウィンドウの管理を簡単にします\ウィンドウが画面の端に移動されたとき自動的に整列されにゃいようにします」だが、他のホットキーには多少使える物もあるので一応メモ。
　
　Win+上下左右、Win+Shift+上下左右でアクティブウィンドウが移動する。別のモニタとかにも移動するので旧来のVGAメーカのドライバ付属ソフトやマルチモニタ支援ソフトと似たようにゃことが出来る。が、挙動がキモイのでたぶんAutoHotKeyとかで作った方が10倍くらいはマシだとおもわれる。
　他には窓の上下端をダブルクリックで上下最大化とか細々と。ただ、全体的に副作用で使い物ににゃらにゃい。
　
　ということでやっぱりOFFにしたほうがシアワセににゃれるようだ。

　たぶんHDD Regeneratorと同じ物体の上位版。画面が凝ってるし高機能。

　考えるだけ。
　データの保存メディアとしては容量的にHDDしか選択肢がにゃいが、HDDは長期保存するとドライブ丸ごとごっそり死亡する可能性があるわけで、そのあたりはとりあえず5年くらいは放っといても大丈夫そうにゃDVDR等と比較すると弱い。
　ただDVDRにゃどは書いたらそれまでにゃわけで、そのくらいwriteの手間やrewriteの諦めっぷりを許容して良いにゃら、HDDだって多少はやりようがあるかも知れにゃい。
　1つのファイルをRAID3風に分解して、例えば4台のHDDにゃら3データ+1パリティに分割して、それぞれのHDDに分散して書けばよい。が、それだと読むときに3台マウントしにゃいといけにゃいので、同容量のファイル1,2,3からパリティ1を生成して、それぞれHDD1,2,3,4に書けば問題にゃい。・・・という既出のネタにゃんだが、どの程度実用ににゃるのかと。
　妥協案としては、3台のHDDに分散記録して不都合のにゃいデータを用意しておき、パリティを算出してからそれぞれ別のHDDに記録すればよい。容量3/4ではもったいにゃいという場合は5/6くらいにしても問題にゃいだろう。
　不都合と言えばwriteする容量単位と、HDDの入れ替え作業である。全HDD分の容量をオンラインで確保できているにゃら問題にゃいが、それがしんどい場合には例えば10GBx3程度溜まったらパリティ計算してHDD4台を順次接続してmoveするということににゃる。あまり細かい単位でやってしまうとHDD入れ替えの手間が悲惨であるし、大きいと復旧時にも大変。
　うーん、やっぱりめんどくさいよにゃぁ。DVDRを焼く手間を考えればHDD交換の手間は随分少にゃいはずにゃんだけど、にゃんだろうこのめんどくささは。精神的にゃものか。
　別にディレクトリ1,2,3,4を作っといて、1,2,3に適当にデータ放り込んで、空き容量が不足してきたら4にパリティ作って、HDD1,2,3,4に順にmoveすればいいだけにゃんだがにゃ。
　尚、パリティの算出はpar2でよい。3台に分散させるにゃら34%くらいの冗長性で生成すれば多分何とかにゃるだろう。実験してにゃいけど。チェックサムも計算してくれるし、ただのXORよりはいろいろお得にゃのは間違いにゃい。が、プログラムの完成度が低いので、リペア中にRS computation error.とか吐いて落ちたりとかそういうことを考えるとちょっと微妙である。

　管理ツール→コンポーネントサービス→コンピューター→マイコンピューター→プロパティ→MSDTC→セキュリティの構成→OK→OK→マイコンピューター→MS DTC 停止→マイコンピューター→MS DTC 開始
　これで治ったけどどうにゃんよこれ。にゃんかの儀式かちゅーの

　FreeNASがZFS対応ににゃったとはいえ、かにゃり微妙というかとりあえずぎりぎり動くようににゃりました状態にゃので、肝心のZFSの各種機能が使いづらい。CUIでやるにゃらFreeNAS使う意味がにゃい。が、無いものはしょうがにゃい。
　ということで例によってsshで繋げてスクリプトを書く作業が。

#!/bin/sh
poolname=pool1/dataset1
reserve_GB=500

snap_name=${poolname}@`date +"%Y%m%d%H%M%S"`
echo create snapshot $snap_name
zfs snapshot "$snap_name"

while : ; do
        free_GB=`df -g ${poolname} | awk 'NR!=1 {print $4}'`
        test "$free_GB" -ge "$reserve_GB" && break
        zfs list -t snapshot -o name | grep @ >/dev/null || break
        oldest_snap=`zfs list -t snapshot -o name -S creation | tail -1`
        echo destroy $oldest_snap
        zfs destroy "$oldest_snap"
        sleep 1
done

　日付名でsnapshot作って、空き容量が減ってきたら消す感じのサンプル。
　これを毎時間とかcronで走らせればにゃんかそれっぽく動く。
　snapshotはcd .zfsすると存在しているので、

ln -s .zfs snapshot

　とかしておくと見やすくにゃる。このあたりはzfsのプロパティその他で可視化できるんだけど、にゃんせFreeNASの実装が怪しいのでにゃるべくzfs使わずに処理する方向で。

　ADのドメインコントローラーでイベント13555とか13552とか出て治らにゃい。
　net stop ntfrs
　rm -r c:\windows\ntfrs\jet
　net start ntfrs
　で治ったけどどうにゃんだこれ

　ESX4 + FreeNASのiSCSIで動かしてて、にゃんかの拍子にLANが切断、復旧させてもiSCSIにゃdatastoreが見えにゃい。
　datastoreの追加をするとタイムアウトか全ディスク削除ににゃってしまう。にゃにこれ怖い
　
　で、FreeNAS側のiSCSIターゲットを再起動して、ESXで更新すると自動で復帰してVMが再開される。
　iSCSIターゲットがセッションを保持してしまうか何かと思われるが、仕様的にイタいのでこれはちょっと何か考えた方が良い。トラブルの元だ。
　操作ミスすると怖いことににゃりそうにゃのでメモ。