以前サーバとともに(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旅行の写真と日記を上げました。写真がいっぱいあるとめんどくさいのねー。
そうだ 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 を新規にインストールすればうまくいくと思います。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)