コグノスケ

HDD増設

以前サーバとともに（2009年1月14日の日記参照）購入したHDDが5台入るケースですが、2台空きがあったので今回HDDを買い足して埋めました。

今までは1TB HDDが3台入っていました。
真面目にRAID-5を作成すると2TBの容量（HDD 1台1TB * (HDD 3台 - パリティ用HDD 1台) = 2TB）となりますが、私は4台構成（1TB * (4台 - 1台) = 3TB）のRAID-5を作成し、縮退モード（アレイからHDDが1台欠けた状態）で運用していました。

こうすると手持ちのHDDの容量がフルに使えます（1TB HDD 3台で3TBの容量）が、HDDが1台でも故障するとデータが飛んでしまう、耐故障性の低い状態になります。耐故障性のないRAID-5なんて意味がないので、今回2台買い足すに当たって5台構成（1TB * (5台 - 1台) = 4TB）に変更することにしました。

予想外の遅さ

買ってきたHDDを増設したはいいものの、RAIDの再構築には非常に時間がかかります。

縮退モードからRAIDを拡張するには「縮退モードの解消」と「アレイの拡張」の2つの作業が必要です。

まず縮退モードの解消をするため、4台目のHDDをアレイに加えます。すぐにアレイのrebuildが始まります。rebuildが終わると縮退モードが解消されて、4台構成のRAID-5となります。rebuildは20MB/sくらいで進みます（約14時間）。

次に5台目のHDDをアレイに加えます。その後、アレイの拡張を行います。すぐにアレイのreshapeが始まります。reshapeが終わると5台構成のRAID-5が完成します。reshapeは6MB/sくらいしか出ないようです（約48時間）。

以上の手順を踏めばrebuildとreshape 1回ずつで5台構成のRAID-5が完成するはずです。が、私はうまくないことに作業手順を間違え、5台目のHDDをアレイに追加せずにHDD 4台のままアレイを5台構成に変更してしまいました。そのせいで5台構成の縮退モードが構成されてしまいました。

そうすると何が悲しいかっていうと、5台目のHDDを追加するときに再びrebuildが必要になってしまうのです。やり直したくてもreshapeは途中で止められないし、もう待つしかない。む…無念なり。

ババロア

ホワイトデーにハンドミキサーを大下さんにプレゼントしたわけですが「普段はハンドミキサーが必要になる料理はしないんですが…。」なんて悲しいことを言われてしまいました。

そんなこと言わないで、せっかく買ったんだし使ってよってことで、ハンドミキサーを使うお菓子をリクエストしました。ババロアです。

私もお菓子作りを手伝いましたが、難しいことはできないので、私は主にハンドミキサー係に。やっぱり大下さんはハンドミキサーをあまり使わないまま、ババロアを作り終わってしまいました。

まあ、いいか。いつか役に立つだろう。うん。

できあがったババロアは冷やしが足りなくて若干ユルユルでしたが、おいしかったです。あと、どのお菓子にも言えるけど、調子に乗ってたくさん作ってはイカン。食いきれないから。

適当な投資＝投棄

昨今の投資ブーム（リーマンショック前ですね）に乗っかって投資したは良いものの、金融危機や日本経済のかつてない凋落に直面、今はもう涙が出るばかり…という方はたくさんいるんじゃないでしょうか。

私もその一人でして、調子に乗ってFXに挑戦してみたものの、失敗して15万くらい損を出しました。ここでやめておけば良かったのですが…。

リーマンショック後に「円高の今こそ外貨買いだ！！」と再挑戦したのが運の尽き。買った後も円高が進み（＝外貨が下がる）損は増えるばかり。50万以上の含み損をかかえました。

しかもロスカットを嫌って保証金を積み増したため、投資額が雪だるま式に増え、泥沼です。もう損切りする勇気も沸きません。

いい加減な投資は、金を捨てるに等しいですね。

昨今

そんなこんなで放置してたFXのポジションですが、株価が徐々に回復し為替も異常な円高から脱出したことで、やや風向きが変わってきました。

あれだけ真っ赤っかに大損こいてたFXのポジションも、なんとか見るに堪える金額になってきました。そろそろ処分すべきだろうなあ。いやはや高い勉強代であった。

同じはずの環境

サーバでプログラムをmakeすると、挙動が違うことに気づきました。

例えばsed-4.1.5ですと、デスクトップのVM上でコンパイルすると何事もなく成功するのに、サーバでコンパイルするとsed-4.1.5/po以下の *.poファイルを更新しようとして失敗し、コンパイルがコケてしまいます。

デスクトップ、サーバともにDebian GNU/Linux 5.0（Lenny）ですから、コンパイラを始めとしたツールの差はなく、環境変数も同じですし、全く同じソースを利用しています。にも関わらずコンパイルに成功したり、しなかったりするのはなんなのでしょうか？

違いを追え

どうやら使っているツールや環境変数、ソースコードまで同じなのに動作が異なるという現象が起きうるようです。

まずはオーソドックスな手順（※）でコンパイルを進めてみて、違いが出る場所を調べました。configureのログは違いなしですが、makeのログは一行目から既に違っています。

make  all-recursive
make[1]: Entering directory `/home/katsuhiro/build/sed-4.1.5'
Making all in intl
make[2]: Entering directory `/home/katsuhiro/build/sed-4.1.5/intl'
（... 以下、略 ...）

デスクトップではビルド用のディレクトリ（build/sed-4.1.5）に入って、コンパイルが始まります。

cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9 -I config
 cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run automake-1.9 --gnits
doc/Makefile.am:29: docdir was already defined in condition TRUE, which includes
 condition BUILD_HTML ...
（... 以下、略 ...）

対するサーバではソース用のディレクトリ（src/sed-4.1.5）に入って、configureやMakefileの更新が始まります。

なぜこんな違いが出るかというと、ビルドディレクトリのMakefile（build/sed-4.1.5/Makefile）にある、ACLOCAL_M4ターゲットが適用されるか、されないかが異なるためです。

（... 関係ない部分なので略 ...）

48: ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
49: am__aclocal_m4_deps = $(top_srcdir)/config/codeset.m4 \r（... 中略 ...）
60: 	$(top_srcdir)/config/strverscmp.m4 $(top_srcdir)/configure.ac

（... 関係ない部分なので略 ...）

92: ACLOCAL = ${SHELL} /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9

（... 関係ない部分なので略 ...）

260: $(ACLOCAL_M4):  $(am__aclocal_m4_deps)
261: 	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)

（... 関係ない部分なので略 ...）

一応補足しておくと260行目の定義は「ソースディレクトリのaclocal.m4がconfig/*.m4より古かったら、missing --run aclocal-1.9を実行してね。」という意味です。

つまりデスクトップではaclocal.m4が古いとみなされないのに、サーバではaclocal.m4が古いとみなされるという違いがあるのです。

（※）sedに限らずGNU autotoolsを使ったソースコードをコンパイルする際は、ソースを展開したディレクトリ（例: ~/src/sed-4.1.5）の他に、ビルド用のディレクトリ（例: ~/build/sed-4.1.5）を作成し、ビルド用のディレクトリでコンフィグおよびコンパイル（例: cd ~/build/sed-4.1.5 && ~/src/sed-4.1.5/configure && make && make install）ができます。

更新時刻が違う

どうやらデスクトップとサーバではファイルの新旧が異なるようです。

ではmakeがファイルの新旧をどう判断しているかというと、実はファイルの更新時刻を比較しているだけです。ですからデスクトップではaclocal.m4とconfig/*.m4が同じ更新時刻になっているが、サーバでは更新時刻が異なっていてなおかつaclocal.m4の方が古い時刻になっている、と考えられます。

ファイルの更新時刻はlsコマンドでわかりますが、より詳しい更新時刻を見るためにls --full-timeオプションをつけて調べます。

$ ls --full-time aclocal.m4 config/*.m4
-rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 21:59:07.000000000 +0900 aclocal.m4
-rw-r--r-- 1 katsuhiro katsuhiro   894 2009-04-08 21:59:07.000000000 +0900 config/codeset.m4
-rw-r--r-- 1 katsuhiro katsuhiro  1394 2009-04-08 21:59:07.000000000 +0900 config/getline.m4
（... 中略 ...）
-rw-r--r-- 1 katsuhiro katsuhiro   733 2009-04-08 21:59:07.000000000 +0900 config/strverscmp.m4

デスクトップではナノ秒の部分は全て0に設定されており、どのファイルも同じ更新時間です。

$ ls --full-time aclocal.m4 config/*.m4
-rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 22:00:53.953952850 +0900 aclocal.m4
-rw-r--r-- 1 katsuhiro katsuhiro   894 2009-04-08 21:59:33.965953865 +0900 config/codeset.m4
-rw-r--r-- 1 katsuhiro katsuhiro  1394 2009-04-08 21:59:33.977953882 +0900 config/getline.m4
（... 中略 ...）
-rw-r--r-- 1 katsuhiro katsuhiro   733 2009-04-08 21:59:34.005955390 +0900 config/strverscmp.m4

一方、サーバではナノ秒の部分にも数値が設定されており、どのファイルも異なる更新時間です。

ファイルシステムが違う

どうやらデスクトップとサーバではファイルの更新時刻が違うらしいことがわかりました。何が原因かというと、実はファイルシステムが違っていたのです。

デスクトップで使用しているReiserFSやext3では、更新時間のナノ秒部分に常に0を代入します。対してサーバで使用しているXFSでは、更新時間のナノ秒部分まできっちり時間を設定します。

結果、ReiserFSやext3上では同時刻と判断されmakeに無視されるようなファイルも、XFS上では更新時刻が異なると判断され、makeがあちこちのファイルを更新して回る現象が起きてしまうわけです。

おそらくtarなどはアーカイブの展開時にutimeで更新時刻を秒単位で上書きしているはずです。XFSに対して更新時刻を秒単位でいじると、同じ時刻に設定したつもりでも、ナノ秒部分が残ってしまって異なる時刻と判断される、なんてことが起きている可能性がありますね。これは追々調べたいと思います。

そもそも悪いのは

デスクトップとサーバではファイルシステムが違うせいでmakeの動作が変わることがわかりました。が、問題はそこではなくて、きちんとコンパイルできないのはsedが悪いのであって、ファイルシステムのせいではありません。本来、ReiserFSでもXFSでもコンパイルできないといけないはずです。

しかしコンパイルで問題が出るのは大抵GNU autotoolsやGNU gettextですから、100％sedが悪いとも言えません。こやつらはバージョン間で仕様がメチャクチャに変わりまくるので、ちょっとバージョンが違うとトラブルが起きます（※2）。

結局、悪いのは誰なのか良くわかりません。長々書いたわりに歯切れが悪い…。

（※2）バージョン間の差を理解してさっと直せれば良いのですが、GNU autotoolsやGNU gettextの激変する仕様について行くのは至難の業です。

定額給付金

ポストに定額給付金を振り込みました、というはがきが届いていました。はがきには4月16日と日付が打ってあります。

定額給付金の振り込み（※）

口座をチェックするとお金も入っている様子。4月21日に振り込まれたそうです。はがきの日付と全く合ってないが、まあいいか…。

（※）画像はネットバンクの画面キャプチャですが、残高を示す表が無駄にでかかったのでかなり端折っています。

旅行記

かなりいまさらですけど。

• 3月8日のラーメン博物館旅行（2009年3月8日の日記参照）
• 3月28日の飛鳥旅行（2009年3月28日の日記参照）
• 3月29日の嵐山旅行（2009年3月29日の日記参照）

以上3旅行の写真と日記を上げました。写真がいっぱいあるとめんどくさいのねー。

順番メチャクチャだけど

そうだ3月28日に書き損ねた話をここに書こう。

じょーと飛鳥に向かう前に、梅田スカイタワー地下のお好み焼き屋「きじ」に行きました。「きじ」ではメニューを店主のおっちゃんに注文して、おっちゃんが焼いてくれるのを待つというスタイルを取っています。

一応メニューは壁に貼ってあるんですが、店が混んでるので遠くてよくわからんのよね。そういうときは迷わず「おまかせでー！」っておっちゃんに言えばオススメ品を焼いてくれます。

何が出てくるかわかりませんが、好き嫌いのない人なら損はしないと思います。おっちゃんも「ネギは食えるか？」など好き嫌いを聞いてから焼き始めていたので、全く食えない物が出てくることはないはず。

僕らの後ろにいたカップルがミックスを注文していたのですが、おっちゃんに「ミックスはどこでも食えるよ〜？別のにしなよ〜、絶対うまいよ〜。」とかなんとか言って、別のお好み焼きに誘導されてました。なんか面白いおっちゃんだなあ。

親切設計

家ではVirtualBoxを使って、デスクトップに仮想Linuxマシンを作っています。

VirtualBoxはバージョンアップの際に設定ファイルを勝手に引き継ぐので、バージョンアップの際に再設定などは必要ありません。今使っている設定ファイルも1.xの時代から使ってきたものです。

使えたり使えなかったり？

しかし最近はネットワーク周りの変更で良く引っかかります。

以前VirtualBoxを2.2.0にバージョンアップした際に、どういうわけか今まで使っていたBridged Adapter（※1）が使えなくなってしまって、仕方なくHost-only Adapter（※2）に変更しました。

で、最近2.2.2にバージョンアップしたら、またBridged Adapterが使えるようになっていました。何でだろう。使えるのか使えないのか、良くわからん…。

（※1）VirtualBoxがホストのネットワークインタフェースと仮想マシンのネットワークインタフェースをブリッジする方法。Windowsのブリッジ機能とは違います。

（※2）仮想マシンのネットワークインタフェースと通信するためのインタフェースを新たに作成する方法。Windowsのブリッジ機能で、ホストマシンのネットワークインタフェースとHost-only Adapterをブリッジすると、Bridged Adapterでやっていたこととほぼ同等のことができます。

バージョンアップ

またVirtualBoxの話です。

VirtualBoxを2.2.0から2.2.2にバージョンアップした際に、何回やってもインストーラが失敗メッセージを出して終了してしまい、アップデートできません。症状を見るにRemoving Files... と出た後、何かが失敗してセットアップのRollbackが始まっているようです。

初めて役に立った

セットアップが削除したいファイルが使用中なのかなあ？と思って、Host-only Adapterを削除したり、Windowsの再起動直後にアップデートしたりしましたが、改善せず。何が悪いのやら？

もう2.2.0をアンインストールするしかないかなあと思いつつ、最後にダメもとでVirtualBox 2.2.0の修復セットアップを行った（私の環境ではWindowsの再起動が必要でした）後、2.2.2へのアップデートを行ったところ無事アップデートできました。

今までMicrosoft Officeくらいでしか修復セットアップを試したことがなくて、しかも大抵失敗するだけで何の役にも立たないイメージだったのですよ。今日、初めて修復セットアップが役立ったというか、きちんと動作したことに感動しました。

で、感動はさておき、古いセットアッププログラムが手に入らない場合は、素直に2.2.0をアンインストールしてから、2.2.2を新規にインストールすればうまくいくと思います。