OpenSolarisのバグとソースコード修正箇所の対応付け

私はカスタマサポートエンジニアだが、障害対応の時にソースコードを参照することがよくある。日本のユーザは修正内容について細かく知りたがる。Webで公開している技術情報ではもちろん、バグデータベースに開発者が書いたコメントでも説明しきれない。そう言うときはソースコードにあたる。

OpenSolarisに関わることが増えてきたので、登録されたバグに対してソースコードのどこが修正されたのかを見つける方法を調べた。ちょっと面倒だが、OpenSolarisのコードリポジトリ（http://repo.opensolaris.org/）にアクセスできれば簡単なのかもしれないが、私のアカウントは権限がないと拒否される。プロジェクトに参加しないとだめなのだろうか。

まずBugster（http://bugs.opensolaris.org/）でバグの状況を調べる。たとえば「6740597  zfs fletcher-2 is losing its carries」は10-Fix Delivered (Fix available in build) なので、既に修正がリリースされている。修正が含まれるビルドはRelease Fixed欄に書いてあるsolaris_nevada(snv_114) である。

各ビルドのソースコードはON Download Archives（http://dlc.sun.com/osol/on/downloads/）にアーカイブされている。ビルド114はb114（http://dlc.sun.com/osol/on/downloads/b114/）である。

このビルドに含まれる変更はFull HTML Changelog (with files updated)に書いてある。たしかに6740597が入っていて、変更されたファイルのフルパスも分かる。

Issues Resolved:
    BUG/RFE: 6740597 zfs fletcher-2 is losing its carries
Files Changed:
    update:usr/src/grub/grub-0.97/stage2/zfs-include/zio.h
    update:usr/src/uts/common/fs/zfs/fletcher.c
    update:usr/src/uts/common/fs/zfs/sys/zio.h

ソースコードはON Source（http://dlc.sun.com/osol/on/downloads/b114/on-src.tar.bz2）である。これをダウンロードする。比較するために、一つ前のビルド（b113）のソースもダウンロードする。変更ファイルをdiffすると、ソースコードのどの部分が変更されたかが分かる。6740597では、usr/src/uts/common/fs/zfs/sys/zio.hの79行目が次のように変更されている。

b113

#define    ZIO_CHECKSUM_ON_VALUE    ZIO_CHECKSUM_FLETCHER_2

b114

#define    ZIO_CHECKSUM_ON_VALUE    ZIO_CHECKSUM_FLETCHER_4

つまり、チェックサムをONに設定したときのアルゴリズムをfletcher-2からfletcher-4に変更したということである。6740597はfletcher-2の脆弱性を指摘したもので、より強力なfletcher-4をデフォルトとすることで対処したようだ。このバグに関連するディスカッションはzfs-codeの次のスレッドである。

fletcher2/4 implementations fundamentally flawed
http://www.opensolaris.org/jive/thread.jspa?threadID=69655

Bugsterは私のアカウントだと、バグの最初のレポート内容しか出てこないが、アカウントの権限によってはその後の議論や修正コードへのリンクなどが見られるのかもしれない。

（注）Firefoxならmozilla-central（http://hg.mozilla.org/mozilla-central/summary）で修正履歴が分かるし、Bugzilla（https://bugzilla.mozilla.org/）の関連バグにもリンクされている。

ZFSインテントログ（ZIL）

Solaris ZFSのZILについて調べた。参考にしたのはSunのソフトウェアエンジニアのブログ記事である。

ZFS: The Lumberjack（ Neil Perrin's Weblog）
http://blogs.sun.com/perrin/#the_lumberjack

slog blog (or blogging on slogging)
http://blogs.sun.com/perrin/entry/slog_blog_or_blogging_on

The ZFS Intent Log（Neelakanth Nadgir's blog）
http://blogs.sun.com/realneel/entry/the_zfs_intent_log

ZFSの書き込みは、ディスク上で常に一貫性を保つように、DMUトランザクションとして扱われる（DMU = Data Management Unit）。DMUトランザクションは、全て反映されるか全く反映されないかのどちらか一方しかない（アトミック性）。

DMUトランザクションは主メモリ上でトランザクショングループにまとめられる。トランザクショングループがコミットされるのは、おおむね数秒間隔である。トランザクションをそのままディスクに反映せずにトランザクショングループにまとめるのは、書き込み性能を向上させるためである。

ファイルシステムをO_DSYNCでオープンしたり、fsync()を実行したりして同期書き込みを行うことがある。典型的なアプリケーションはデータベースである。同期書き込みは、更新データがstable storageに書き込まれたあとでアプリケーションにreturnすることを要請する。トランザクショングループがコミットされるまで待つと性能が悪化してしまう。これを解決するのがZFS Intent Log（ZIL、ZFSインテントログ）である。

ZILはディスク（HDDもしくはSSD）に置く。すなわちstable storageである。ZILに書き込まれるのは未コミットのトランザクションである。コミットされたトランザクションはZILから削除される。上記の同期書き込みのシナリオで考えると、トランザクションをZILに書き込んだ時点でstable storageに格納したと考えることができるので、すぐにアプリケーションにreturnしてよい。これにより同期書き込みの性能を向上させる。

64KB以下の書き込みは、データ自体がZILのログレコードに書き込まれる。64KBを超えるサイズの書き込みデータは、ディスクに同期したあとで、同期したデータへのポインタだけがログレコードに書き込まれる。

ZILは通常、メインプールの中に動的に割り当てられる。これを別デバイスに配置することができる（zpool add <pool> log <log devices>）。SSDのような高速デバイスに配置すると性能向上が期待できる。非ミラー構成のSSD ZILデバイスが故障したり、slogデバイスが満杯になったら、メインプールの領域を使う。

VMwareゲストがVMware Server 2のインベントリに追加できない

米国本社のエンジニアが作ったVMwareゲストが動かない。動かないどころか、インベントリに追加できない。私が使っているのはVMware Server 2.0.1（Windows版）である。面白いことにVMware Player 2.5.2では問題なくブートできる。

VMware Server 2のWeb管理画面に出てくるエラーメッセージはこうだ。

The selected virtual machine is not recognized on this system. The cause of this problem may be that the virtual machine's .vmx file is corrupted, or that the virtual machine version is newer than is recognized by the host. You can remove the virtual machine from the inventory if you believe that it is not recoverable.

Click the link below to remove the virtual machine from the inventory.

Remove Virtual Machine

To help diagnose the issue, you can check the virtual machine files at their last known location: "[standard] XXXX/XXXXX.vmx"

XXXXX.vmxを編集することで解決した。vmxファイルの先頭は次のようになっていた。

.encoding = "windows-1252"

私の環境で作ったvmxがすべてShift_JISになっていたので、次のように書き換えてみた。

.encoding = "Shift_JIS"

これでインベントリに追加できるようになり、ブートもできた。

legitimate

legitimateという単語を見聞きすることがときどきある。新しい言葉は、インプットするだけではなかなか身につかないので、アウトプットしてみよう。用例をいくつか拾ってみた。

ファームウェアやOSがハードエラーを誤検出することがある。誤検出は「false alert」あるいは「false positive」という。ウイルスの誤検出も同様である。反対に、どう考えても正真正銘のハードウェアエラーであるときは「legitimate」を使うとよい。以下は同僚のハードウェアエンジニアが書いたメールの一部である。

This looks like a legitimate memory issue.  I think this DIMM needs to be replaced.

legitimateの用法には、「まっとうな」「合法的な」という意味もある。以下の例文では、Webサイトへ悪意をもって送られた大量のリクエストによって、本来処理すべきリクエスト（legitimate incoming traffic）が処理できなくなることについて述べている。

somebody basically sends so many requests to your - phony requests, but requests - to your website that you spend all your bandwidth trying to handle them and can't handle legitimate incoming traffic.

最後の例文は、送信元IPアドレスを偽装したパケットなのか、正しく送られたパケットなのかを簡単には識別できないということについての話である。後者のことをlegitimate packetと言っている。right packetでもcorrect packetも、この文脈にはそぐわないだろう。

STEVE:  Ah, well, now, that's another good point, is the other thing that these packets are doing is that they're spoofing their source IP.  When a legitimate packet comes to a server or to an end-user, it identifies who sent it, that is, by IP address, and what its destination is.  The destination IP gets it to you.  The source IP is the IP to which you send the return traffic.  So the packet has to have both.  In these denial of service attacks, the source IP is being randomized on purpose so that you really don't know if it's legitimate or not.

（参考記事）
Security Now! Episode #8
http://www.grc.com/sn/sn-008.txt

Norton AntiVirus 2009の「権限がないアクセス」メッセージ

Norton AntiVirus 2009（NAV2009）をインストールしたあとに履歴ログを見ると、「権限がないアクセスを遮断しました」というメッセージがときどき記録されている。重大度は中レベルだ。

これは「Norton製品の改変対策」機能である。悪意のあるソフトウェアの中には、アンチウイルス製品の機能をまず停止するものがある。それに対する対策である。私のPCでは、c:\windows\explorer.exeが処理者で、NAV2009のファイル（MCUI32.exeなど）が発生元というパターンが多い。explorer.exe（Windowsエクスプローラ）がNAV2009のファイルに対して何かを実行しようとして、それを防御している。

ちょっと不安になったが、explorer.exeがウイルスなどに犯されているわけではない。ログメッセージの「処理」欄が「終了メッセージをウィンドウに送信」である。つまり、explorer.exeがNAV2009のウインドウを閉じるアクションを遮断したのだ。たしかに履歴ウインドウやネットワークマップウインドウを閉じたときに記録されているし、「Norton製品の改変対策」をオフにすると記録されなくなる。ごく普通の処理のときに出るのか不明だが、処理タイミングの問題なのかも知れない。

「explorer.exe」と「終了メッセージをウィンドウに送信」以外の組み合わせは、実際にNAV2009に対する攻撃の可能性があるので要注意である。

（参考記事）
Unauthorized access of ccSvcHst.exe Blocked/Logged?（Norton Community : Norton Users Discussion Forum : Norton Internet Security / Norton AntiVirus）
http://community.norton.com/norton/board/message?board.id=nis_feedback&thread.id=21209&view=by_date_ascending&page=1

「拙速」なアメリカ流

「後付け」「対症療法」というと、やってはならないことというニュアンスをだいたいの日本人が持っているだろう。物事を進める前に、想定される事態を十分に考慮に入れ、水も漏らさぬ計画を立てた上で実行すべしという意識が日本のビジネスマンや企業には強い。いったんやり始めたあとで問題が出ることは許されない。

シリコンバレーのIT企業はまるで反対だ。スピードが最優先である。問題が出たら、そのときに対処すればよい。やってみないと分からないこともあるので、走りながら考える。失敗したら、それは経験を蓄積したと考え、次に活かす。いざとなれば、裁判で決着すればよい。会社のやり方が自分に合わなくなったら転職すればよい。会社というコミュニティから離脱するだけだ。

結果として、アメリカのやり方は初動が速い。開始時のコストは少なくてすむ。しかし問題が出ると、それを解決するためのコスト（訴訟も含めて）があとからかかってくる。なかなか結果が出なければ、傷が深くならないうちに撤退する。「拙速」である。

日本流は初期コストがかなりかかる。そして立ち上がりは遅い。初期にかかったコストを回収するために、安易に撤退することはできない。会社に所属しているから、そう簡単に辞めるわけにはいかない。定年まで勤め上げれば高額の退職金がもらえる（はず）。粘り強く・忍耐強く・細く長くという、日本で美徳とされるやり方が求められる。

日本で販売代理店を立ち上げるときには、とにかく準備と資料が必要だ。価格表やカタログ、製品マニュアルは当然だが、販売マニュアル、トラブルシューティングマニュアル、製品マニュアルに出ていないような技術仕様など、ありとあらゆるものを用意してようやく、じゃあ売りましょうということになる。書籍である、当該分野のことならその本を見れば何でも分かる。学校の教科書といってもいい。

アメリカの販売パートナーだったら、必要なものはその都度担当営業に要求したりテレカンをやったりして、とにかく素早く動いて結果を出そうとするはずだ。しかし、走りながら考えるアメリカ流では、情報共有に難がある。必要の都度メールや電話で確認しているから、情報がまとまらない。まとめる人もいない。そこで出てくるのがポータルだったり検索エンジンである。社内に散逸している情報を一元的に閲覧したり探し出したりできるようにする後付けの仕組みだ。

もちろんこれは非常に単純化した見方であるし、どちらが優れていると言うつもりはない。何事も両極端はダメだ。周りの状況によってアメリカ流にスピードに比重を置いたほうがうまく行く場合もあるし、日本流に慎重にやった方が効果的な場合もある。中間のどこかに解がある。しかもその解は不定なのである。それでも、一方のやり方しか知らずに無意識にそれをやってしまうのと、両方のやり方を知ったうえで最適なやり方を考え出すのと、変化の激しい世の中にどちらが向いているかは明らかである。

ちなみに「拙速」はネガティブな文脈で使われることが多い。この文章でアメリカ流儀を「拙速」と書いたのはその意図からだ。しかし広辞苑に「兵は拙速をとうとぶ」という用例が出ているし、孫子の「巧遅は拙速に如しかず」という言葉もある。必ずしも忌むべき言葉ではないのである。

Firefoxアドオン

アドオンをなるべく入れない人もいるが、作業効率が上がるものなら積極的に試すのが私の流儀である。とりわけTab Mix Plus、GMarksは無くてはならない存在である。

Brief
RSSリーダー。社内Wikiの更新チェックに使っている。インターネット上のRSSはGoogle Reader。

GMarks
Googleブックマークと同期するブックマーク用アドオン。自宅と会社のPCでブックマークを同期できる。Firefoxのブックマークは、ブックマークツールバーのみで使っている。ブックマークツールバーは常に表示し、仕事で頻繁に使う社内のシステムを中心に登録している。

Google Gears
Google ReaderやGmailのオフライン機能のためにインストールしたが、今は使っていない。

Hide Find Bar
Ctrl + Fで表示される画面最下部の検索バーを自動的に閉じるアドオン。

IE View
Firefoxでの表示がおかしいページがときどきある。Internet Explorer前提で作って確認しているのだろう。右クリックでIEを起動してURLを受け渡せるので便利だ。

Personal Menu
メニューツールバーを非表示にするアドオン。1024×786のThinkPad T42でメイリオフォントを使うと表示範囲がやや狭い。画面をできるだけ広く使うためにインストールした。たまにメニューツールバーが表示されっぱなしになるのが玉に瑕だ。Altキーを何回か押すとこうなるようだ。再起動すれば非表示に戻る。

QuickRestart
Firefoxを再起動するボタンをツールバーに追加できる。しばらく使っているとFirefoxの使用メモリが徐々に増えていく。タブを開いたり閉じたりしているうちに、解放しきれないメモリが溜まっているような印象だ。一気に掃除するためにときどき再起動している。表示されっぱなしになったメニューツールバーの対策にも使える。

SQLite Manager
places.sqliteの肥大対策で使った。

Tab Mix Plus
タブ機能の拡張アドオン。リンクやブックマークを別タブで開いたり、間違って閉じたタブを復元したりするのに重宝する。

タブカタログ
タブをサムネイル表示するアドオン。便利かと思ったが、Ctrl + Tabで切り替えるほうが速いので出番があまりない。

窓使いの憂鬱からAutoHotkeyへ移行

これまで「窓使いの憂鬱」でキーボード配列をカスタマイズしていたが、Windows 7への移行を視野に入れて、レジストリとAutoHotkeyの併用に切り替えた。

ドライバを使う窓使いの憂鬱はVistaで動作しないため開発終了となった。Applet氏が「のどか」で開発を引き継いだが、有償ソフトになってしまったし、改版履歴を見るとマイナーなバグが取り切れていないようである。しばらくAutoHotkeyでやってみることにした。

さて、入れ替えるべきキーは以下の通りである。

• Esc → 全角/半角
• 全角/半角 → Esc
• CapsLock → Ctrl
• 左Ctrl → Enter
• 右Ctrl → Windows
• Alt + h/j/k/l → vi風カーソル（←／↓／↑／→）
• Ctrl + h → Back Space
• Ctrl + t → Delete

これに加えて、ATOKのキーカスタマイズで以下のキーアサインを行っている。

• x → 長音記号（ー）
• 無変換 → IMEオフ    （参考記事1）
• 変換 → IMEオン（参考記事1）

ところがAutoHotkeyはCapsLockの入れ替えがうまくいかない。日本語環境特有の問題らしい。窓使いの憂鬱やAutoHotkeyは、他の人にPCを操作させるとき、一時的に入れ替えを無効にして標準キー配列に戻せるところが便利だった。これはあきらめて、単体キーの入れ替えはレジストリで対処することにした。

Windowsの仕様（参考記事2、3）をもとにレジストリキーを書き換えるのもそれほど大変ではないが、Change KeyはGUIで設定できて便利だ。標準配列にリセットするコマンドもある（PC再起動が必要）。

vi風カーソルとCtrl + h/tはAutoHotkeyで定義する。Shiftキーを押しながらカーソルキーで文字列を選択することが多いから、Shift付きも定義する。

;Alt + H → 左カーソル
!h::Send {Left}
+!h::Send +{Left}

;Alt + L → 右カーソル
!l::Send {Right}
+!l::Send +{Right}

;Alt + J → 下カーソル
!j::Send {Down}
+!j::Send +{Down}

;Alt + K → 上カーソル
!k::Send {Up}
+!k::Send +{Up}

;Ctrl + H → BackSpace
^h::Send {Backspace}

;Ctrl + T → Delete
^t::Send {Delete}

（参考記事1）キーボード入力におけるモードについて（栗原潔のテクノロジー時評Ver2）
http://blogs.itmedia.co.jp/kurikiyo/2006/10/post_2250.html

（参考記事2）Archive: Scan Code Mapper for Windows（Windows Hardware Developer Center）
http://www.microsoft.com/whdc/archive/w2kscan-map.mspx

（参考記事3）
Windows Vista/XP/2000/NT4.0のキー配列の変更方法（藤枝和宏氏）
http://www.jaist.ac.jp/~fujieda/scancode.html

（2009/05/30追記）

のどかの現状について誤解を招く表現があったので修正した。

Firefox 3のplaces.sqlite肥大対策

places.sqliteをvacuumやreindexするとFirefox 3の起動が速くなるという話があるので、試しにやってみた。しかし体感できるほどの差はなかった。参考にしたのは以下のページ。

Firefoxのアドオン「SQLite Manager」を使ってFirefox自体のデータベースを最適化する
http://www.padmacolors.org/entry/20090318/685/

places.sqlite の再作成 Firefox Hacks 翻訳日記/ウェブリブログ
http://firefoxhacks.at.webry.info/200902/article_1.html

firefox 3が遅くなった→ SQLite reindexで解決＆高速化 - しおそると
http://www.sio.no-ip.com/mt/shio/archives/2008/10/firefox-3-sqlit.html

毎日相当な数のWebページを見ているためか、places.sqliteが29MB近い。VacuumとReindex後に約19MBまで小さくなった。SQLite Managerでテーブル情報を見ると、テーブルmoz_historyvisitsが6万レコード以上、テーブルmoz_placesは3万レコード以上もある。

オプションの履歴保存日数（browser.history_expire_days_min）を7日にし、さらにbrowser.history_expire_daysを10日に設定した。デフォルトの90日／180日も保存しておく必要はない。これでレコード数が激減するのかと思ったが、多少減っている程度で大きな変化がない。Firefoxの履歴ウインドウで見ると、昨年12月5日以降の履歴が残っている。再起動を繰り返しながら最古の履歴をチェックしていったら、少しずつ消えているようだ。徐々に設定した日数分に落ち着くのだろう。

現時点の状態をメモとして残しておく。

最古の履歴：2008年12月6日17:18
moz_historyvisits：66539レコード
moz_places：32427レコード
places.sqlite：19,681,280バイト

（2009年5月18日追記）

その後順調にレコードが減っていき、今日16:08時点でこうなっていた。

最古の履歴 2009/05/08 16:08
moz_historyvisits 5831レコード
moz_places 3508レコード
places.sqlite 19,681,280バイト → Vacuum、Reindex後 2,215,936 バイト

（2009年5月28日追記）

7日／10日の履歴保存日数は短すぎることが分かったので、20日／30日に変更。

映画の中の使えるセリフ（部下の褒め方編）

ピアース・ブロスナン主演の007第2作「トゥモロー・ネバー・ダイ」は、彼の4つの007映画のうち一番好きな作品だ。この映画でボンドが戦うのは、世界中のメディアや企業を牛耳るエリオット・カーヴァー。頭は切れるが、ちょっとイカレている。国家間の紛争を影でお膳立てし、それをいち早く報道することで莫大な利益を得ている。さらに中国でクーデターを起こして現政府を転覆させ、反乱軍のリーダーから今後100年の独占放送権を獲得するという野望をも抱いている。

カーヴァーが、世界各地での悪事の報告をビデオカンファレンスで部下から聞くシーン。「Good morning, my golden retrievers」と呼びかけつつ部屋に入ってきたエリオットが、壁面の巨大なスクリーンを前に、手に持ったリモコン端末をスタイラスでせわしくタップしながら、次々と報告を聞いていく。パキスタンで暴動、カリフォルニアで飛行機事故というニュースに「Excellent!」。そしてエリオットの指示どおりにバグを満載した新しいソフトウェアがリリース予定で、ユーザはすぐにアップグレードを強いられるだろうという報告に「Outstanding!」。outstandingは、他のものから飛び抜けて優れているという意味である。エリオットの「Oustanding!」は、「アーウトスタンディング」と「ア」にアクセントを置き、いやみったらしく延ばす発音で、耳にこびりついて離れない。

部下の失敗を叱責するのは時代遅れで、よいところを褒めて成長させるのがいいリーダーの条件とされている。外国人のチームを率いて週次ミーティングで活動報告を受けるようなことがあったら、「Good job」や「Excellent」、「Great」などとともに「Outstanding」も使ってみようと思っているのだが、元ネタが元ネタだけに、「このリーダー、イカレてんじゃないの？」と思われるのがオチかもしれない。