BSD小僧の日記

URIがスラッシュで終わっているときにデフォルトでadiary.cgiを読ませてやりたいと思っていて、いままでうまく動かせていなかった。

Apacheの.htaccessに仕掛けをするんだろうなー、と思っていて、これまではDirectoryIndexを使っていました。

DirectoryIndex adiary.cgi

これでスラッシュで終わってもちゃんとadiary.cgiを実行してくれます。でも、これだと次のページのリンクなどがうまく動いてくれません。

つまり、ブラウザのURIを表示するところにhttp://www.tokuda.net/diary/と表示するのではなくて、http://www.tokuda.net/diary/adiary.cgiと表示されなければならないということです。

Redirectすればいいじゃん、と思い

Redirect permanent / http://www.tokuda.net/diary/adiary.cgi

とやってみました。すると、URIがループしてしまうらしく、ブラウザにはとんでもなく長いURIが表示されてしまいました。

うーん、ちゃんとスラッシュが末端であることを認識してくれればいいのになぁと思いながら、もしかしたら正規表現で行末であるところの$を使えばうまくいくかもなーと思い立ち、

RedirectMatch permanent /$ http://www.tokuda.net/diary/adiary.cgi

と記述してみました。

結果は、ばっちり上手くいきました。

上手くいったものの、一回redirectが入るので少々無駄のある解決策ですよね。Webブラウザが要求したURIしか表示されないとしたら、やっぱり一回はWebブラウザに戻して、再度リクエストを投げてもらうしかないんでしょうかねぇ。

と、思ってadiaryのページを見たらrewriteを使う方法が推奨されているじゃないですか。しかも、同梱されているドキュメントにサンプルまで載っているじゃないですか。

RewriteEngine	On
RewriteBase	/diary/
RewriteCond	%{REQUEST_FILENAME}	!-f
RewriteRule	^(.*)$			adiary.cgi/$1	[L]

うーむ、呪文だ。RewriteCondの所がちょっとよくわからんな。

でも動くよ。こりゃぁいい。

■サスペンドで接続が切れてた

朝起きたらMacBookがサスペンドしていて (あたりまえだけど)、嫌な予感とともに起こしてみたら案の定sshの接続が切れていました。

つまり、昨日のddは失敗したというわけ。

んで、dd if=/dev/zero of=/dev/sd0c bs=1mをするだけのshell scriptを書いて、バックグラウンドジョブで流して出かけました。

■rawデバイスとblockデバイスの歴然とした違い

そんでもって、夜になっても終わらず。13時間ぐらい流したところでおかしいなぁとIRCでぼやくと、「sd0cじゃなくてrsd0cじゃないの?」というアドバイスを頂戴しました。

おー、rawデバイスとblockデバイスですね。newfsのときも教えてもらったのに応用の利かないやつです。

なんかUSBメモリだとスピードが一桁ちがうとのこと。

ということでddコマンドにcount=10をつけて10Mbytesだけ書く試験をやってみました。

glantank# dd if=/dev/zero of=/dev/sd0c bs=1m count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 8.168 secs (1283761 bytes/sec)
glantank# dd if=/dev/zero of=/dev/rsd0c bs=1m count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 1.893 secs (5539228 bytes/sec)

4.3倍ほど差が出ました。これは歴然とした差ですね。5Mbyes/secなので計算すると250Gbytesの場合、やっぱり14時間弱ほどかかりそうです。

ehciのumass接続なのでUSBとしてはがんばっているはずですが遅いですねぇ。結局のところPATAで接続しないと全然駄目だろうという話になりました。やれやれ、眠っているCeleron400MHzのマシンを引っ張りだしてくるしかなさそうですねぇ。出すのも分解するのも面倒だなぁ。

■SIGINFOでddの進行状況を表示させる

ところで、ddの進行状況は普通に実行していると表示されませんが、SIGINFOのsignalを送ってやると進行状況(というかddの結果出力そのまま)を表示してくれると教えてもらいました。

kill -INFO プロセスIDでも良いですが、フォアグラウンドで実行している場合にはCtrl-Tで簡単に出力が得られます。こりゃ便利。

朝はやっぱり起きないねー。

シマウマの歌を歌っていたよ。シマウマは馬よりもロバに近いって今日どっかのWebページで読んだなぁ。

信号の間に合うように走っているとなんか楽しそうな顔をしていて、なんかこっちも楽しくなってしまうね。いいね。

先週書いた年賀状を渡したんだろうかね。

あしたは遠足らしい。ちゃんと起きられるかな。

先週購入した250GbytesのHDDですが、ずーっと放置していて初期不良の一週間を超えそうなので急いで動作確認することにしました。

USB経由でHDDをGLANTankに接続し、無事に認識されることを確認しました。

で、ddを使って書き込みテストをやろうと思い立ちdd if=/dev/zero of=/dev/sd0を実行しました。

しかし、ぜんぜん終わる気配を見せません。ircでぼやくとbs=1mとかやるんじゃないの、と教えてもらいました。デフォルトではbs=512となっており非常に効率が悪いというのがその理由です。

さっそくbs=1mで実行すると、14Gbytesぐらいで終了してしまいました。

/: write failed, file system is full
dd: /dev/sd0: No space left on device
13912+0 records in
13911+0 records out
14586740736 bytes transferred in 1845.423 secs (7904280 bytes/sec)

あれぇと思っていると、/dev/sd0cってやるんじゃないの、と教えてもらいました。

# ls -l /dev/sd0
-rw-r--r--  1 root  wheel  14586740736 Jan 14 05:41 /dev/sd0

わっはっは。/dev/sd0という14Gbytesのファイルを作ってしまった。そりゃぁ/も溢れますよ。

気を取り直して/dev/sd0cでddを実行するのです。

これも時間がかかりそう。

とあるきっかけでアマゾンのロングテールは二度笑うを入手しました。

事例ベースで戦略について記した本です。さくさく読んですぐに読了でした。一日あれば読めちゃうかも。

アマゾンについては最後の方にちょっと出てくるだけでタイトルよりは幅広い話題をあつかっています。

「勝てる土俵で戦え」と書いちゃうと「あたりまえじゃん」なのですが、それができないとどういう恐ろしいことが起こるか(起こったか)がわかりやすく書かれています。専門家には当たり前の話なのかもしれませんが、戦略なんて素人のおれにとっては「ほう、そういうもんなのか」と思わせてくれる一冊。