LongingLog.ext

不良セクタで破壊されたファイルシステムの救出

Mon, 12 Apr 2010 16:38:48 +0900

適当に再起動を繰り返したことが引き金となったのか、/に割り当てていたファイルシステムをマウントできない自体に陥った。あわてずに、UbuntuのCD-ROMをブートすると、そのHDDは不良セクタがいっぱいで危険！とのメッセージが表示された。

とりあえず、マウントしようとしてみるとファイルシステムエラー。
reiserfsなので、reiserfsckをかけると不良セクタによるダメージで問題があるとのメッセージが表示された。

不良セクタを指定してfsck

badblocksによって検出した不良セクタの位置をfsckに渡してやることで、それを避けた状態にできるようだ。

# badblocks -v -b 4096 -c 4096 -o sda1_badblocks.txt /dev/sda1

-vを付けると進捗が表示される。
-bでブロックサイズを指定。いまの標準は4096の様だがファイルシステムの作成時期が古い場合など違うこともあるので、なにかで確認すべし。
-cで一度に読み取り、テストするブロックの数を指定する。ある程度多くても問題ないと思うし、適度に大めにすることで速くできそう。
これで数時間。
で、不良セクタ指定でfsckをしてみる。

# reiserfsck --badblocks sda1_badblocks.txt /dev/sda1

すると、、ジャーナルの部分に不良セクタがあって死亡(´･д･`) 。。

ddrescueでイメージとしてパーティションを救出

あきらめかけていた所、ddrescueなるツールを知った。
ddでは不良セクタで読み取りエラーが出た所で終了してしまうけど、ddrescueならリトライするし、読み取れなかったらごにょごにょ処理してくれる。

# ddrescue -d -b 4096 -v -r 1 /dev/sda1 sda1.img sda1.log

ここでのlogはレスキューの進捗具合を記録してるので、中断しても同じログファイルを指定することで再開してくれる。便利。
-rは最大リトライ回数。デフォルト0なのでリトライしない。
実は最初はこれを指定せずに読み取ったのだが、-r 1にするだけで結果が改善した。
でも実行にかかった時間も何倍も延びた。

では、抜き取ったイメージにたいしてfsck

# reiserfsck sda1.img

まずジャーナルに記録されてたことをリプレイして、その後はBtreeのノードとかをチェックしてくれた模様。最終的には「--rebuild-treeしないとどうにもならない不整合が15箇所あるよ」と言って終了した。

# reiserfsck --rebuild-tree sda1.img

なので--rebuild-treeを実行。ああ、2.4.8あたりのころ、reiserfsがバグっててすごいダメージを負ったころに実行したの以来だ。reiserfsの根幹となっているB*-Treeのデータをゼロから作成する。

ではマウントしてみる

#mount -t reiserfs -o loop,ro sda1.img /mnt/tmp
#ls /mnt/tmp
bin command etc init linuxrc mnt proc sbin sys usr
boot dev home lib lost+found opt root service tmp var

-o loopをつけてループバックマウントするのだ。
よし，復活。

不良セクタでファイルシステムが死んでしまったら、ddrescueでイメージとして抜き出して修復することが一番よい方法のようだ。イメージファイルになっているとコピーも簡単なのでfsckとかがやりたい放題。
ま、こんなことせずにすむようにRAID組むとかSMARTの不良セクタ代替の個数とかをちゃんとチェックするとかしないとねー。
ってかまだSSDじゃないの？と言われかねないな。

MVCのVとCをブラウザに持っていったら？

Mon, 19 Oct 2009 20:19:26 +0900

「RESTful MVC」なアーキテクチャの話[Life is beautiful]を見て、そういう開発をやったのを思い出した。ただし、右半分だけである。

サーバ側にはモデルとそのラッパ(認証など)のみで、
ブラウザ側のJavascriptがControllerとView(Template)の役割を持たせる。
Javascriptでラップされたオブジェクトへのメソッド呼出が
サーバ側でのメソッド呼出と一対一になる。
間はXML-RPC。次のプロジェクトではJSONに切替えた。

問題は左半分側がないために、ユーザを不必要に待たせる時間が存在することだ。
なぜかというとJavascriptのロードが終わって実行されてからデータを取りにいくから。

初期の描画だけでもサーバ側でやればその問題はなくなるが、ビューを別言語で二つ書かなくてはならない。これは手間だし、バグの温床になりかねない。

でも今は違う。これからはサーバサイドでもJavascriptが使えるし、QUnitとかでちゃんとテストも出来る。となるとJavascriptで作った同じView Templateをサーバとクライアントで使える。

というわけで冒頭の方式が出てくるわけだ。
僕の場合、まあAjaxでどうせ「データオブジェクトを描画する」ところを書くならJavascriptでクライアント側で、と思ったのが出発点だったけど、
この方式には役割を明確化し、インターフェースを正しく定義することに
必然性を持たせる作用があるとLife is beautifulでは主張されている。
確かに役割が不明確になってControllerが肥大化とかあるある。

そういえばローカルストレージとかでもクライアントでのViewは重要になるね。
だれかJavascriptでのテンプレートエンジンをよろ。

PENTAX K-7評

Wed, 30 Sep 2009 23:58:24 +0900

娘の誕生にあわせてPENTAX K-7を買いました。
「ムービーをとって実家に送るんだい」と言ったら、嫁もろ手をあげて賛成。

6/27の発売以降、悩みに悩んで見送っていました。
というのもカメラの本体はすばらしいが、画質は前のK20Dに劣るという噂が。
でも買ってみたらそんな心配は無用でした。

それどころか、K10DやK20Dと同じ価格帯にも拘らず、
カメラとして、写真を撮るための能力アップがすばらしい。

シャッターを切ったときの反動が80%低減（当社比）
オールドレンズで必須の絞りこみ測光が劇的に改善、ほぼ無音で瞬時に終了
そのおかげでグリーンボタン動作が快適

まとめると、つまりはシャッターの改善がすばらしいのです。
従来は一つのモーターでミラーアップと絞りの動作を行っていたが、
それぞれ専属のモーターに別けた、というのがその改善の肝でしょう。

別けたことでミラーの動作の終了時にブレーキをかけることができてミラーショックを低減、絞りの方も独立したことで2、3の様な効果が出た。

この効果は実際に撮影に出てみるとすごく実感します。(特にAEが効かないレンズで！)

次回はK10Dとの画質比較をしてみます。お楽しみに〜！

水平分離のススメ

Fri, 11 Sep 2009 00:37:00 +0900

IBM PCの互換機、AT互換機の成功は水平分離の力を類を見ない程強く示している。
様々な部品が規格化、モジュラー化されることによって大量生産のメリットを引出し、そして性能と価格で競争する。その結果が現在のPC製品と市場である。非常に高性能でありながら、低価格だ。
垂直統合の製品はまず価格で敗れ、次に性能を追い越される。最後に残るのは信頼性だ。だが、信頼性もいつかは追い付かれる。いつかは市場の縮小によってその信頼性を維持し担保するための資金が尽きるからだ。

実はここで取り上げたいのはPCやその眷族に関してではない。水平分離がいつかは訪れるかもしれない別の業界についてだ。それは自動車だ。
自動車製造も水平分離の時代？にあるように、実の所、中国ではすでにはじまっているらしい。インドでも格安自動車が規格されるくらいだからおそらくはじまっていよう。

もし自動車業界で水平分離が進んだら？まずはエンジンの会社ができるだろう。PCでいうならインテルだ。だがそれには駆動系との連結部分などについての規格化が必要だろう。電気自動車であれば、モータやバッテリはエンジンよりも水平分離向きではないか。シートなんかも量産しやすい。あとは制御系だ。ハンドルやブレーキ、AT回り、どれくらいの粒度が適しているか分からないがそれも市場原理で決まるだろう。

こうして車メーカーが部品の組合せによって製造を行うようになったらどうなるだろうか。まず安くなる。安全性は当然、垂直統合型より劣るだろうが規格化されれば試験も簡単になる。ユニットテストの結果は公表され、結合テストも低いコストで実施でき、いずれは追い付く。そして性能についてだが、電気自動車は垂直統合型よりもよくなるのではないか？モータ、バッテリは大量生産のメリットが生きそうだ。
と、ここまで書いて思ったのだが、内燃機関の車に取って代わる電気自動車の方が水平分離の方向へいく可能性が高い。いや、むしろ水平分離によって競争力が下支えされて内燃機関の車を駆逐するのではないだろうか。

もちろん、これは車好きにとっては大きな問題だ。性能はともかく、価格と利便性、ランニングコストで電気自動車が上回るようになればこれまでの車は立場がない。フィルムとデジカメの関係のように趣味としてしか成立しなくなり、やがてコストが熱意をも飲み込んでしまうだろう。そしてそれは雪崩のように訪れる。

さて、このようなシナリオを前に日本のメーカーはどのような動きをするだろうか。当然、今は垂直統合で電気自動車やハイブリッドを開発しているだろう。だが、それを売るだけではいずれ水平分離型に負けてしまう。ローエンドからはじまり、やがて高級車の手前まで侵蝕される。
それを避けたければ自ら撃って出るしかない。様々な規格を作り、その規格にあった部品を作って売る。その規格で車を組み立てるリファレンスも作る。
規格が市場のルールを作っていく。だから、それを他社に支配されれば水平分離の旨味もまったくない。日本のPCメーカーと同じ轍を踏むことになる。

水平分離は日本にとって悲劇でしかないのだろうか？いや、そうではない。例えば日本初のWIMAX事業者UQはむしろ「土管」になりたいと言っている。垂直統合へのこだわりが市場を小さくしてしまうのなら、市場そのものを広げるような戦い方も一つの道なのだ。スケールメリットがコスト優位性を押し進め、イノベーションを誘発する。
先手を取る日本が見たい。

mod_expires: ファイルの更新時刻からの経過時間を元にExpiresを設定するパッチ

Fri, 07 Aug 2009 23:45:13 +0900

Google Page Speedでこのサイトを計測したら、いろんなことを指摘された。その中の一つがLeverage browser caching、ブラウザのキャッシュを有効利用せよ、だった。
Leverage browser cachingの解説によると、httpレスポンスヘッダにExpiresもしくはCache-Control: max-ageによって最低一ヶ月、最大一年先を指定する様にと書かれている。(Expiresの方がサポートされていることが多いので推奨)
mod_expiresを使えばそんな指定は簡単だ。

ExpiresActive On
ExpiresByType image/jpeg "access plus 1 month 15 days 2 hours"

だが、しかし、このサイトではよく写真の差し替えをする。アップしたあとで色を調整し直したくなるのはよくあること。そんな時に差し替え前の写真のキャッシュがずっと使われるのはまずい。

なのでキャッシュの有効期間をアクセスしてから1日にしてみた。すると有効期間が短すぎてそれらのデータへのアクセス数が無駄に増加してしまった。

てことは、このサイトでは新しいデータのキャッシュ有効期間は短めがよく、古いデータは更新されないから有効期間はどれほど長くても構わないということになる。
これは他のサイトでもあることかもしれない。つまり、世代別CGみたいに生存期間が長いものは長く生きるべきで、短い物は寿命も短いとみなしてよい、みなすべき、ということ。

mod_expiresではアクセス時刻(A)または更新時刻(U)をベースとし、それに指定の時間を足して、キャッシュが無効になる時刻を設定する。

そこに、生成時刻もしくは更新時刻からの経過時間を生存期間と考え、それを元に
キャッシュの有効期限を設定する様にすれば比較的簡単に上記のような要求に答えられるのではないか。

ということでApache 2.2.12用でパッチを作ってみた。
httpd-2.2.12-mod_expires_uptime.patch

設定方法はこんな感じ

ExpiresActive On
ExpiresByType image/jpeg "uptime times 2"

この設定で生存期間(uptime) × 2をアクセス時刻に足したものをExpiresとする。

ちゃんと世代別にしようと思ったら、どれくらいをその分け目とするか、その上と下とでどういった値を使うか、など必要以上に複雑化してしまう。そこでとりあえずこんな仕様にしてみた。反響求む。

太りすぎは猫でもNGらしい。

Sun, 26 Jul 2009 22:29:01 +0900

こういうの大好き。ひさしぶりに爆笑した。

bsdiffとxdeltaを比較してみた

Mon, 20 Jul 2009 09:00:15 +0900

昨日の記事で出てきたbsdiff、実際に使ったことがなかったのだが、xdeltaよりも50%〜80%も出力する差分が小さいらしい。

ruby-1.8.7-p160とruby-1.8.7-p174を対象に比べてみる。
まず、元のサイズを調べる。
ruby-p160 949579 bytes (約928KB)
ruby-p174 950091 bytes (約928KB)

じゃあ、bsdiff、xdeltaで差分を作ってみよう。

$ bsdiff ruby-p160 ruby-p174 ruby-p160-p174.bsdiff

→ ruby-p160-p174.bsdiff 22152 bytes (約22KB)

$ xdelta delta ruby-p160 ruby-p174 ruby-p160-p174.xdelta

→ ruby-p160-p174.xdelta 152538 bytes (約148KB)

これはスゴいよ！確かにbsdiffで作った差分はxdeltaによる差分の15%程でしかない。念のため、復元をして、md5をチェックしてみる。

$ bspatch ruby-p160 ruby-p174_by_bsdiff ruby-p160-p174.bsdiff
$ xdelta patch ruby-p160-p174.xdelta ruby-p160 ruby-p174_by_xdelta
$ md5sum ruby-p174 ruby-p174_by_bsdiff ruby-p174_by_xdelta
41c7edda80df89b7ca3db108b65b255c ruby-p174
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_bsdiff
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_xdelta

と、ちゃんと差分からruby-p174を復元できる。

しかし、このbsdiffの10倍の性能を誇るGoogleの技術、スゴすぎる。

初代ガンダム無料放送byバンダイ

Mon, 20 Jul 2009 06:16:39 +0900

ガンダムの無料放送が今日7/20から始まっている。
初代ガンダムを全話、一日一話のペースで見れるらしい。これはすごい。

ブログに張り付けれるっとのことで、コードも取得したけど
初期化に時間がかかりすぎるのでやめた。

実物大ガンダムといい、30周年にふさわしい。
今年はほんとにガンダムの年だ。

Googleはスピード狂である。

Sun, 19 Jul 2009 12:38:35 +0900

Googleが最新の実行ファイルのアップデート方法を発表した。
[google.com]、[sourceforge.jp]、[mycom.co.jp]

Chromeのアップデートの際に旧版と最新版の差分をこれまでは純粋にバイナリのdiffとして配信していた。新方式に移行することで例えば190.1->190.4への移行に際して以下のようにデータ量を1/10程に出来るという。

Full update	10,385,920
bsdiff update	704,512
Courgette update	78,848

ではこの新方式とはいったいなんであろう？
Google Chromeの公式ブログには以下のような説明がある。

server:
asm_old = disassemble(original)
asm_new = disassemble(update)
asm_new_adjusted = adjust(asm_new, asm_old)
asm_diff = bsdiff(asm_old, asm_new_adjusted)
transmit asm_diff

client:
receive asm_diff
asm_old = disassemble(original)
asm_new_adjusted = bspatch(asm_old, asm_diff)
update = assemble(asm_new_adjusted)
　※ここでoriginalとは旧バージョンのことと思われる。

まず、サーバ側では旧版、新版ともに逆アセンブルを行い、実行ファイルにコンパイルされる直前のデータに起こしてから、その差分を転送する。
クライアント側では手元にある旧版を逆アセンブルし、ダウンロードしたパッチをあて、アセンブルする。

最適化が施され、大きくなりがちなバイナリ差分よりも、その手前のデータの方が
差分が小さくなるというのは納得しやすい。
デメリットはクライアント側に逆アセンブル、アセンブルを行うプログラムを仕込まなければならないことと、その実行時間がせっかく短縮したダウンロード時間を相殺するのではないかということくらい。
これくらい複雑な仕組みを導入するに足る、転送量が減るということは大きなメリットだ。Chromeはバックグラウンドでアップデートを行うため、CPUを使うのはいいが、ダウンロードは帯域使用によってユーザの環境をも圧迫する。

ところで、Linuxのアップデートに使われるyumにはそのような差分アップデート機能はない。常にフルアップデートだ。そろそろどうにかならないものか。
そういえば7zipと同じ圧縮方式のxzをGNUが採用したらしい。
ringサーバにはcoreutils-7.4.tar.xzがあるとのこと。
coreutils-7.4.tar.gz - 9708910B
coreutils-7.4.tar.xz - 4048924B
gzipの半分以下とは…。

とにかく、Googleのスピード狂、チューニング狂っぷりには執念を感じるほどだ。Page Speedもある。そういった部分、単純に尊敬する。

ノイズキャンセリングヘッドホンの威力

Tue, 07 Jul 2009 01:09:34 +0900

車、飛行機、電車の中に溢れる騒音を消すことが出来たら、
どんなに快適だろうか？

実は音に逆相の音をぶつけると消える。波だからだ。
簡単な理屈。でも、これを実際にやるのは難しい。

まず、マイクなどで実際に存在している騒音を捉え、そのデータを元に打ち消す音を作ることになるが、それだけでは正確にキャンセルできない。測定する場所と音を聞く場所が違うからだ。それに音はそんな処理をしている内にもどんどん進んでしまう。

そんなわけで、なかなか実現しないと思われていたこの技術も実はそろそろ商品になって普通に売られるようになった。まずはヘッドホンタイプからだったが、最近カナル型のイヤホンでも出ている。しかも手を出せない値段ではない。

ちょうど6月末にSONYの新商品NC33が出たので買ってみた。
※7/7現在、Amazonで6,811円。

電車の中はもちろん、人の声でガヤガヤしたところ、歩く音が反響するような建物内など、いろんな所でノイズをフーッと消してくれる。突発的な音はある程度残るけど、ずーっと続く音をしっかり捉えて、まったく感じさせなくしてくれる。こうなると、音楽をしっかり聴くことが出来るのはもちろん、騒音がないことで信じられないくらいリラックス出来る。付け加えるとこのNC33、そこそこ中低域も出ていい音。

家の外で音楽を聴くなら、間違いなくお薦めだ。