2009/02/26(木)PCを新調するなら
PCヲタとしては:
- ファイルサーバを用意する
- Windows機はちっこくて静かなやつ。 AMD のグラフィック統合チップがいい
ノートは個人的な趣味に世間と隔たりがあるので割愛。
学生さんが持ち出しつつ論文とかで本気で文章を打つなら ThinkPad, Sony の B5 ノートが良いんじゃないだろうか。
メインにするのに 5〜6万の NetBook は絶対ダメ。
外に持ち出す事が多いなら Sony Style のワイド保証は安心。高いけど。
保証自体は内容と比べたら安いくらいだけど、直販なので量販店の割引がない価格になって本体価格が高い。
実際の買い換えは2年以上先の予定なので適当。
2009/02/17(火)宗教派閥
- C な人は定数マクロを好む
- C++ な人は enum や static const で定数を定義する
しかしこれはヒドイコードですね。マジックナンバーガツガツ入ってるし。
とりあえず、コンテンツの鮮度を表す enum 変数をビット演算できる形に定義しなおしたいと強く思った。
if (hoge < 200)... ってナンダヨ。そこはさー、if(hoge & FRESH) ... とかしたいだろ。将来的に FRESH と STALE だけじゃないステータスを追加したくなったらどうするんだよ。
大体 200 とかコードに書くなよ。ステータスコードの 200 OK かと思うだろ。
ていうか無名 enum なの？
関数の返り値をこの型で定義した方がナイスじゃね？
マジックナンバーバリバリなコードなので、そのうちマジックナンバーで値を返すバカが現れるかもよ？enum 型を typedef しとけばそんなバカの出現が防げるよ？
とってもバザールでござーるな体制がよく分かるコードですね。
2009/02/16(月)古い話だけど ZFS boot
x86 では GRUB が zfs を理解することでブートが可能になってる。
つまり、だ FreeBSD も zfs.ko をモジュールで持つんでなく、
- zfs をカーネルに組み込む
- GRUB で loader でなく kernel を直接引っ張りあげる
ってことにならないだろうか。
特にそんなことを言ってる人を見かけないのでならないんだろう。
2009/02/01(日)件のマザーが飛んだ etc...
別にワザと壊したわけじゃないよ？
オンボードのグラフィックを使い始めた。今までグラフィックカードを挿していたのは高性能な描画が欲しかったんではなく、RADEON だと画面がチラついていたのが理由。しかし、原因は変形ディスプレイの Mode Line 設定を間違えていたことらしい。設定を直したらチラつきは消えたので、オンボードのグラフィックで充分になった。
恐ろしきは DVI の規格を超えるデータ量を流し込まれても平然と処理する GeForce の底力よ。
グラフィックカードを外したのでファンも一つ止めたらスゴイ静かになった。
で、FireFox3 で大幅に改善されたはずのパフォーマンスが悪かったり拡大、縮小表示される画像が乱れて表示されていたんだけど、X.rog 7.4 祭りのついでに portupgrade -fa してみたところ、バグも消えてパフォーマンスも良好になった。何がいけなかったのかは不明。ついでに linux エミュレーション関連の ports を掃除したのでこの辺も微妙に影響してるかもしれないし、何かのライブラリに依存するものをリビルドする必要があったのかも知れず。
X.org 7.4 祭り:
dbus, hal が標準になった。moused とのバッティングは解消されたということだが、hal + dbus 環境で moused も動いているとクリックイベントがおかしくなるようだ。クリックがダブルクリックになってるようなので同じイベントが両方から 2個飛んでる？
で、dbus + hal 環境だと USB キーボードが動かない。cannot open /dev/ukbd0 らしい。デバイスファイルのパーミッション変えてみたりしたけど改善ならず。AllowEmptyInput オプションを有効にしても、hal が生きているとうまく行かないようだ。
まだ本腰を入れて調べれば何かわかりそうだけど、とりあえずは dbus, hald を止めて xkb と moused なレガシー環境で使っておくことにする。
2009/01/29(木)ZFS のステータス監視
今日、まさにサーバがゆっくり死んでいく場面に居合わせた。
ZFS が原因ではないらしい。少なくとも今回は。
ヤヴァイ！ってことで完全に止まる前にとりあえず再起動を掛けることに。
すると...
Jan 30 00:46:24 blues kernel: ad10: TIMEOUT - READ_DMA48 retrying (0 retries lef t) LBA=2930275872 Jan 30 00:46:33 blues kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE task queue timeout - completing request directly Jan 30 00:46:37 blues kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE task queue timeout - completing request directly Jan 30 00:46:41 blues kernel: ad10: WARNING - SETFEATURES ENABLE RCACHE taskqueu e timeout - completing request directly Jan 30 00:46:45 blues kernel: ad10: WARNING - SETFEATURES ENABLE WCACHE taskqueu e timeout - completing request directly Jan 30 00:46:49 blues kernel: ad10: WARNING - SET_MULTI taskqueue timeout - comp leting request directly Jan 30 00:46:49 blues kernel: ad10: FAILURE - READ_DMA48 timed out LBA=293027587 2 Jan 30 00:46:49 blues root: ZFS: vdev I/O failure, zpool=common path=/dev/ad10 o ffset=1500301246464 size=114688 error=5どうやらディスクが応答しないようです。
ちなみにディスクは今をときめく Seagateの不具合の影響はないとされているファームウェアのもの。(型番自体はヒットしてる)
ZFS はむしろ頑張っていてくれた様子。
とはいえ、このディスクに変える前から緩やかな突然死は発生していたのでディスクが悪いとは言い切れない。再起動すると何事もなく動くし。
マザーボード、ディスク共に割と新しいもので故障という線は考えにくいが、ディスクが変わっていることから一番ありうるのはマザーの初期不良だ。ディスクの S.M.A.R.T のエラーログにも何も記録されていないので、これを信じるならディスクではなく結線かディスクコントローラに問題がある可能性が高く、マザーの異常の線が濃くなる。
しかし、あえて言おう。
きっと Seagate がダメなんだ！
数日前からログが出てるのに気づかない俺がダメだ
RAID を組んで物理ディスクの状態を監視しないとダメだよ、といういいお手本ですね。
zpool status -x
の結果を見るようなスクリプトを仕込めばよさそうだ。