ソフトウェア

Windows Vistaを稼働しているマシンのハードディスクが手狭になったので、少し大きなHDDに換装した。いつものように、バックアップのページに書いてある、ディスクイメージを吸い出して、新しいHDDにコピーする方法で行ったのだけど、すんなり行かなかった。ブートローダ回りが、Windows XPとは異なっているためのようだ。
Vistaは、GUIが綺麗になったことと、デバイスドライバが圧倒的に不足していること以外はXPと変わらないように感じていたが、思わぬところに手が入っている。(多分、乗り換えのハードルを下げる目的で、Windows同士のマルチブートを拡張したのだと思うけど)

やったのは、以下の方法。

1. knoppixでCDブートする
2. 新しいHDDのヘッダ、セクタを古いのに合わせ(LBAにした)、シリンダ数が同じパーティション(hda1)を作成
3. 古いC:に当たる/dev/hda1をddで吸い出して、新しいHDDのhda1にddで上書き
4. 古いC:のMBRを吸い出し(dd if=/dev/hda of=mbr.img bs=446 count=1)て、新しいHDDに上書き
5. 新しいHDDのhda1(C:になる)をntfsresizeで容量一杯まで拡張

でリブートしてみると画面が真っ黒なまま動かなくなってしまった。Windowsのファイルチェックが走るはずなのだけどダンマリだ。
BIOSがおかしいのか、とか、ウィンドウズがおかしいのか、とか、ゴミが入っていたのか、とか、問題を切り分けるためにいくつか条件を変えていじってみたのだけど上手く行かない。これにより絞った条件で再度検索してみたら、Vistaになってブート回りが変わっているようだ、ということが分った。

XPまでは、MBR → active partitionのboot record → C:\io.sys だったはず。最後のも、パーティションの相対ジオメトリ決め打ちであったので、インストールに依存しないコードであった。現状は画面が真っ暗になることからMBRは通過している風なので、アクティブパーティションのブートレコードがインストール依存になったようだ。

ということで、更に調べると、中身で何をやっているかは分らなかったけれど、マイクロソフトのサイトにブートレコードを書換えて解決する方法が見つかった。昔は何もできなかった、インストールディスクからの回復コンソールで、以下ができるとのこと。

• マスターブートレコードの書換え (Bootrec.exe /FixMbr)
• アクティブパーティションのブートレコードの書換え (Bootrec.exe /FixBoot)
• C:ドライブのブートメニューの再構成 (Bootrec.exe /RebuildBcd)

上記の1、2をやり直して、上の3つを行うとブートできるようになった。(素晴しい。だけど、回復コンソールでは「自動回復するか」とか言ってくるので実行してみると、「できたっ！」とか言う癖に、実際には直らない。手動で上記を打たないとならない。)

だけど、その後4をやるとやっぱり駄目だ。回復コンソールすら上がらなくなる。どうやら、VistaのNTFS自体が少し変わっていて、私の手元のntfsresizeが古いために(多分パーティション情報かブートコード近辺に)互換性がないようだ。更なる検索を行い、Vistaでは自分でドライブの拡張と縮小ができるようになっていることが判明した。

仕方がないので、もう１回1と2をやり、Bootrecをやり、Vistaでドライブボリュームを拡張し、ようやく終った。
それにしても、Vistaは良く分らないほどディスク容量を食っている。

Linux の tmpfs を使って、/tmpをRAMディスクにしてみた。結論としては効果は全然なかった。

dfすると/dev/shmというエントリがあって、shared memoryらしいことは知っていたが、使ったことはなかった。これをちょっと調べてみたら、on demandにサイズが変わるRAMディスクのようなもで、/tmpをmountすることもできる。
実はCGIではffmpegを始めとする外部コマンドを多数使っている。コマンドをそのまま使っているため、ファイル渡しのIFになってしまっているところがあり、速度が少し気になっていた。
昔のSunOS 4.1の頃は swaptmp とか言うもので /tmp をRAMディスクにするのが普通だったりしたし、少しはファイル渡しIFを高速化できるかも、と考えた。

基本は、

• 通常デフォルトでメモリの半分サイズのtmpfsが作成されている。
• それを/tmpにマウントすれば良い。mount -f tmpfs -o size=64m /tmp

実際には、起動時に /tmp に名前付きpipe?ソケット?がいくつか作られているので、ブート後にマウントを行うとそれらが通信できなくなって支障が出る。(例えばフォントサーバが動かなくなって字形がショボくなったりする)。従って、fstabに書いて起動途中(デーモンが上がる前に)にmountする必要があった。

• tmpfs /tmp tmpfs size=64m 0 0

で、cgiで実測してみたけど、違いは誤差範囲であった。

考えてみれば、ハードディスクのアクセスの際には、HDDのディスクキャッシュ以前にもシステム管理のメインメモリのキャッシュが効いており、連続してアクセスする場合はほぼキャッシュ内に収まっているのだろう。万が一ハードウェアアクセスしてしまうと凄く遅くなるけれど、そうはならないようだ。実際のアルゴリズム的には、Cache → HDDも shm → swap も大して違わないのかもしれない。

書き込み後、時間が経ってから読み出すような場合には効果があるかもしれないけど、通常のtmpファイルとしては大きな利点はなさそうに思う。