2011年3月19日土曜日

データの退避

危機管理が...と言われるのもいやなので、データを遠隔地に退避中。
今のところインターネットは輻輳を起こすような状態ではないようなので、転送速度もまあ上限付きで(というか、実際には対向側のサーバーが制限をつけている様子)転送している。

実質3Mb/s位しか速度がでないので、30GBだと一日がかり。まあ一度fullのバックアップをとっておけば、後は差分の転送ですむので、最初はしかたがないか。

でも、単純なファイル転送でなく用途に応じた転送方法を選択しないと、実際には気休めにしかならないね。復旧に1日掛かるとなると、ないよりまし、としか言えない。

2011年3月16日水曜日

μSv/h (地震 その3)

放送を聴いていると、マイクロシーベルトとマイクロシーベルト毎時 が、なんだか意図的に混用されているような気がする。

一回のレントゲンで受ける量が40μSv ... これは /h 無しの値なのかな、せいぜい数秒間にこれだけ受けるとすると、毎時換算だと、mSv/h 単位の被爆になるし、一回の飛行機旅行で 200μSv というのも /h 無しの値なんだろうか? 5時間の飛行なら、40μSv/h 位の計算になる。

で、比較対象となっているのは、明らかに 10μSv/h が 40μSvより量が少ないから心配ない的な表現をするわけだけれど、一日にすれば、240μSvで、毎日5回もレントゲン撮影をするのと同等レベルの話で、まったく安心しろとは言いにくい量だ。逆に、最大値の方も 40mSv/h の方も、それが一時間も継続するならともかく、数分間のピーク値なら取り立てて気にするほどのことでもない。

大本営発表が「安全だ」と強調しはじめるのは、安全でないことの裏返しなのだろうけど、どうなのかな。情報開示が遅いとか言われているけれど、東電は良くやっていると思うよ。素人への説明に専門家を割りあてるよりはその間に本来の仕事をしてもらった方がいい。
たぶん、判断の間違いがあるとすれば、被害を最小にすることを優先して最悪のケースの被害を減らすことを優先しなかったことかな。

[追記:3/17] 平時の 100μSv/h の漏れは「避けなければいけない大変な異常事態」だけれども、緊急時の100μSv/hは、避けなければいけない量ではない ... 緊急時には、平常時の基準値を一時的に超える結果を招くことが明らかな処置をあえてすることを避けてはいけない ... ということ。結果がうまくいったときには、あとで(もっと別の方法があっただろうと)批判されることになるだろうけれど。

2011年3月13日日曜日

地震... (その2)

地震でルータが壊れるなんて考えていなかったけれど、その後の瞬間停電のせいだと思うけれど壊れてしまったみたい。他にも壊れてしまったらしいHUB多数。

HUBの故障は通信ができないことですぐに判別がつくけれど、ルータの故障ってのは随分変な壊れ方をするのだね。繋がったたり繋がらなくなったり、最後まで判定に困るような壊れ方だった。結局はルータ交換で症状が収まったのでルータの故障ということになったわけだけれど。

[追記: 3/20] ルータは電源を完全に落としてから再起動したら復活した模様。再起動そのものは試したらしいから、暴走していたのかな。まあ、もう少し連続運転してみないと現場復帰というわけにはいかない。

2011年3月12日土曜日

地震...

なんとか、自宅にたどりつきました。

電話はほとんど使えなかったけれど、ネットがほぼ通常通り使えたのが救いでしたね...

2011年3月9日水曜日

USBブート

USBメモリからのブートを少しばかり試している。
手持ちの実験用のPCが、USBブートに対応していない古い機械が多い(って一体何年前の機械だ...)ので、あまり試せなかったのだけれど、ハードディスクの容量がテラバイト単位になってきて、データとシステムは分離したいと考えると、USBスティックからのブートも試しておかないと時代に遅れてしまう。

で、最初は無難にFreeNAS8.0betaをUSBメモリにインストールしてみたのだけれど、これがうまく起動してくれない。どうも機械との相性が結構あるみたい。
似たような条件ということで、CDROM起動を試してみると、これはすんなりといく。特に設定をしたわけでもないのに、/var や /tmp が メモリ上のファイルシステムとして確保されたのには少し驚いた。
あまりUSBメモリを何度も書き換えたくないので、USBメモリの容量分のファイルイメージを作ってそちらにファイルシステムイメージを作って作業。
で、USB1.1の転送速度 1MB/sec を考えると、4GBだとイメージ転送に1時間以上かかる計算になるので、最終的には小さいパーティションを切って dump/restoreで転送することにした(ま、何のこっちゃ..だけど)。
こちらも、/etc/fstabを編集した他は、まったくのGENERICな状態。で、挿して起動してみると、普通に起動してくれる。起動時間は3~4分(USB1.1)といったところか。たまにしか起動しないのならなんとか実用になるかも、といったところ。

で、もう少し速くならないか?というと、まずはGENERICカーネルが12MBほどあるので、これをカスタマイズしてスリム化、gzip圧縮も効果があるかもしれない、といったところか。
あとは、読み書きされる部分の分離。/var や /tmp はメモリ上に取るにしても、/root や /home をどうするか。

loaderのオプションで、ルートファイルシステムをメモリ上にとるオプションがあるのだけれど、こちらを利用した方がいいのかもしれない。linuxのinitrdは圧縮が掛かっているようだけれど、FreeBSDで圧縮されたファイルシステムイメージは使えるのだろうか?

2011年3月8日火曜日

platexが... (その4)

大体のところはうまくいっているみたいなのだけれど、ルビの処理が少し変。
ルビの幅が漢字の幅より長いのが続くと、ルビが重なってしまう。
『[最(いと)小(ちひさ)き』だと、「と」と「ち」が重なってしまうので、「ちひさ」を八分の一画分後ろに下げないといけないのだけれど、これができていない。

使っている rubyマクロが古いとか、そんな理由なのだろうが、ルビ付けの決定版的なマクロは何なのだろう。

2011年3月2日水曜日

platexが... (その3)

latexって、改行2つと改行3つとだと意味が違うのだっけ?
xml → tex の変換で、改行を気にしない形式と改行を気にする形式間の変換をすると、微妙に空白が予期しない副作用を引き起こすなぁ。

xsl:strip-space で明示的に入力から空白を取り除いて、xsl:text で明示的に書き出せばよい話だけれど、ソースがちょっと見づらくなるのが難点かな。