gjournal と time stamp ( その2 )

cyrus-imap の reconstruct を実行すると、"timestamp mismatch" のエラーが大量にでる。
reconstruct を 繰り返しても、エラーがなくならない。

gjournal の問題なのだろうか？ それとも、ハードディスクが壊れている？

この状態だと、ちょっと使えないので、近いうちにディスク検査 & 通常の UFS2 に変更だな。

gjournal と time stamp

FreeBSD6.4のufs2 File System と、FreeBSD 8.2 のgjournal File System の間で、rsync すると、time stamplが正しく設定されない。
--modify-window=2 (1はまだ試していない)を指定すると、正しく転送されるようなので、たぶん両者のtime stampの精度に違いがあるのだろう。

FreeBSDのバージョン違いのせいなのか、ファイルシステムの問題なのかはよくわからない。

東電は経費節約、政府は金銭感覚マヒ

なんだか、政府のばら撒き政治がはじまったみたいね。
「安全だ」で通せばいいのに、そのうち風評被害まで補償の対象に含めてしまいそうだね。

一方で東電はといえば、どうしたら安上がりに解決できるか、そればかり考えているように見える。

何をするにも、政府の干渉が多くて即決できないのかな。船頭多くして... の典型なのかも。

データの退避 (その2)

下り方向の速さを測ってみると、チャネル一つで約20Mb/s、チャネル二つだと約25Mb/s くらいの数字になった。もっともチャネル二つの場合は、こちら側のネットワーク機器が律速になっている可能性が高いので、きちんとした設備で測れば 35～40Mb/sは出るのだろうと思う。

これだけの速さが出ているのであれば、30GBでも2時間もあればダウンロードできる計算になるので、まあバックアップストーレッジとして使えるかもしれない。
転送量としては、プロバイダの方で、「快適に使えるのは 100GB/月程度まで」と制限を掛けているようなので、月に何度も丸ごとダウンロードを試すわけにはいかないが。

「危険だ」と言ってもらいたい症候群

どうも、今の日本人は、「直ちには害を及ぼさない」とか、「乳児には危険」とか、そういう表現をすると、『じゃ、安全なのか、それとも危険なのかはっきりしろ』みたいな反応を返したくなる人が多いみたいね。

たぶん、「危険だ」と言って欲しいのだろうな。そうすれば、不安がなくなってすべてを東電や政府のせいにできて安心できる。

例えば、放射線のせいで、今まで一億人に一人の発病率だったものが、一億人に二人の発病率になったとして、じゃ安全でなくなったのか？といえば、「従来よりは安全ではない」としか言えないでしょう。じゃ危険なのか？といえば、「大抵の人にとっては、気にするほどの危険じゃない」。当たり前のこと。

備忘録: phpのアップデート

php5.3.5 → 3.5.6 のアップデートをしたら、Segmentation fault を起こすようになった。
いろいろ検索してみると、どうも、phpの問題ではなくて、一緒にアップデートした libxml2 が問題らしい。

とりあえず、fixらしいのが、
http://forums.freebsd.org/archive/index.php/t-8965.html
こちらは、files//patch-configure から

*freebsd*) THREAD_LIBS="";;

の行を取り除けとのこと。

phpの設定で、threadを有効にするのが正しい、というのが
http://forum.nginx.org/read.php?23,149976,151169,quote=1

そろそろディスクの追加を

最後にサーバーのディスクを追加したのが２年前で、そろそろ窮屈になってきた。
もう PATAのディスクを追加するのはコスト的に見合わないし、SATAのディスクに移行するべきなのだろうけれど、そうするとマザーボードごと全取替だ。
いつもだと、比較的新しい機械を増強して、それのあまったパーツをサーバー用に転用するというパターンなのだけれど、今回は世代間の仕様のギャップが大きくて、うまくドミノ移植できるパターンが見つからない。

あまり消費電力の大きいCPUをサーバーに回したくない、というのが最大のネックかな。