いくつかのブラウザのフォント設定（初期値）を比較しました。

ブラウザやOSが異なると、意図したフォントで表示されないことがあります。理由を知っておきたいのですが、「送り手」と「受け手」の事情があると思いますので、まずは、いくつかのブラウザでの設定方法の違いを整理しておきたいと思います。（設定は全て初期値です）

Firefox 14.0.1:（初期設定）

ubuntu10.04（Linux）版のFirefoxです。「Webページが指定したフォントを優先する」にチェックが入っています。

Windows（7）版のFirefoxの初期設定値です。Linux版と項目は同じですが「フォント」の指定が具体的な点で異なります。

Google Chrome 21.0.1180.57:（初期設定）

Linux版のGoogle Chrome です。すべて「Andale Mono」が選択されていますが、これは「何も選択していない」のと同様です。実際に閲覧すると「Webページが指定したフォントを優先する」という設定が有効であるような表示になっていましたが、無指定のWebページに備えて指定する必要がありそうです。

Internet Explorer 9:（初期設定）

「プロポーショナルフォント」と「等幅フォント」の二つだけを指定できるようです。それぞれ「適切な候補以外は選択できない」ように制限されているようです。

「ここで選択するフォントは、フォントが指定されていないWebページやドキュメントで表示されます」とあるので「Webページが指定したフォントを優先する」ようです。

まとめ：

ブラウザ	プロポーショナル	明朝体	ゴシック体	等幅	Note
Firefox（Linux）	ゴシック体	serif	sans-serif	monospace	Webページ優先
Firefox(Windows)	ゴシック体	MS P明朝	MS Pゴシック	MS ゴシック	Webページ優先
Chrome（Linux）	-	-	-	-	Webページ優先
Internet Explorer	MS Pゴシック	なし	なし	MS ゴシック	Webページ優先

調べた範囲では、どのブラウザも「（初期設定では）Webページ優先」でした。「設定を変える人は少ない」という前提ではWebページの指定フォントで表示される機会は多いわけですから、ブログなどを制作する側は「フォントの指定に注意をはらうこと」が大事なことに思えました。「このページは読みづらい」とならないよう、フォントの指定に注意したいと思います。

詳細は未確認ですが、OS毎に「搭載しているフォント」が異なるようです。全部のOSを調べるわけにもいきませんが、「適切なフォントの指定」のためには、ある程度調査する必要がありそうです。

ブラウザから見るフォントの種類には「プロポーショナル/等幅」と「明朝体/ゴシック体」の二つの軸があることが分かりました。Webページでフォントの指定がない場合、Windowsでは「MS P明朝」や「MS ゴシック」のように特定のフォントが使われるようですが、Linuxの場合は「特定のフォント」ではないようです。最終的には「何かが」選択される仕組みになっていると思いますが、その仕組みはわかりませんでした。これも調べる必要があると思います。

ubuntu（Linux）でブラウザの利用者がフォントを指定するのは面倒です。例えば、ubuntu（Linux）版のFirefoxで「等幅フォント」を変更しようとすると、候補に（同じ書体で）70以上の搭載フォント名が提示されます。「Internet Explorer」のように「等幅フォント」だけが表示されると楽な作業ですが、「プロポーショナルフォント」も混ざっているので「多少の負担」を強いられます。フォントの区別が怪しい状況では困難さが増すので、名前と姿を把握する努力は必要なようです。

ハードディスクの気になるSMART値をメモ。

ハードディスクを交換して落ち着いた時期になったので、ubuntu10.04のディスクユーティリティで「SMART情報」を確認したのですが、気になる数字が見られました。経年変化を知るためには初期の状態を記録する必要があると思うので、メモしておきます。

Read Error Rate:

「値が0でない場合、ディスク表面または読み書きヘッドのどちらかに問題があります」となっていますが、評価は「Good」です。といっても「値」は「しきい値」と同じ「51」なので心配ですが、大丈夫なんでしょうか。

この値はピーク値のようです。前回確認した時は「10」だったような気がしますが、今回急上昇していました。ディスクの温度と関係があるのかもしれません。ディスク温度が「47°Ｃ」となっていたのでパソコンの蓋を開けると、「44°Ｃ」まで下がりました。

Power-off Retract Count:（積算値）

「ハードディスクに大きな負担を与える」ような事象のようです。無理に電源を切るようなことは滅多にしないので、この数値は多過ぎるように思いましたが、セットアップ時に何度か電源を切ったことを思い出しました。通常運転中の現在は、数字に変化はないようです。

Load/Unload Cycle Count:（積算値）

「プラッタ上のランディングゾーン（表面加工された非記録領域）に退避した回数」と読めたのですが、例外もあるようです。プラッタの外側に「ランプ」と呼ばれる待機場所を持った機種もあって、その場合も同様の表現になるようです。この機種の場合は正常に停止処理が行われた回数を示しているようなので、特に気にする必要はなさそうだと分かりました。

Uncorrectable Sector Count:（積算値）

｢（ID:5）Reallocated Sector Count｣の値が「1」だったんですが、「セルフテスト」の「詳細」というのを実行すると、2時間くらいかかりましたけど、その値は「0」になり、「（ID:198）Uncorrectable Sector Count」の値が「1」になりました。

セルフテスト（詳細）を実行することで、「バッドセクタ」の評価が変わったようです。現在の総合評価では「ディスクは正常です」となっていますが、セルフテスト以前の総合評価は「ディスクにはほんの数個のバッドセクタがあります」でした。今は問題ないようですが、しばらくの間は注意する必要がありそうです。

Write Error Rate:

「または」が2つあって、何を示している値なのかよくわかりません。よくわからない値ですが、数値の変化を把握しておく必要はありそうです。

CrystalDiskInfo:

違うソフトウェアでの評価も知りたかったので、Windows用の「CrystalDiskInfo」を使ってみました。

補）初回の評価から数日後の値ですが、「C1:ロード/アンロードサイクル回数」が増えています。

「ID:C6」の「回復不可能セクタ数」が黄色で「健康状態：注意」となっています。ubuntuのツールで見た時の「ID」は「198」でしたが、評価対象ではなかったようです。

同じハードディスクのSMART情報を異なるソフトウェアで確認したんですが、評価は同じではありませんでした。個人的には「注意が必要」と感じていたので、Windowsのツールの評価には妥当性があるように思えます。

まとめ：

最初の健康診断はパスしたようですが、読み書き時のエラー頻度やバッドセクタが発生していたことを考慮すると「要注意」だと思います。

「診断結果を見て何をすべきか、それを判断することが私にはできない」ということが分かりました。これが一番の収穫だったと思います。たくさんのハードディスクのSMART情報を見ている人と同じように解釈することは無理ですが、定期的に観察することで段々と理解できるようになるんだと思います。

ハードディスクの温度と故障率には因果関係があるそうなので、温度には気を付けたいと思います。この個体の場合は「45°C」を越えないようにすると良い気がしています。

古いハードディスクのアームの動かし方（映像メモ）

アームの駆動方法は変わってきているようです。映像資料として幾つかピックアップしてみました。

MiniScribe製のハードディスク（1988年）ということです。リニア駆動のアームに見えましたけど、回転運動を直線運動に変える機構のようでした。リニアモーターではないようです。

メーカ不明の72MBハードディスクです。4枚プラッタ、4ヘッドと聞こえたので、1枚あたり18MBの容量があるようです。形状がやや複雑ですが、現在と同じスイングアームになっています。

ゴムローラーを押し当ててヘッドの位置決めをしているようです。こういう方法でも精度を保てた、ということが驚きです。アームを駆動するモータはステッピングモータのようです。

そして、現在のハードディスク。ボイスコイルモータというものを使ってアームを動かしているそうです。おかしな動きをしていますが、壊れているようです。

仮想ディスクのファイル転送速度はホストOS並みのようです。

ubuntu10.04（ホストOS）に載せたubuntu10.04（ゲストOS）の仮想ディスクのベンチマークを採ったんですが、ホストOSとほとんど変わらない転送速度を示しました。

補）8GiB/464GiBという狭い範囲なので、「右肩下がり」のグラフにはなっていません。

仮想ディスクを確保したのは、ホストOSパーティションの前方です。

仮想ディスクに割り当てた場所のホストOSのベンチマーク結果は次のようになっています。

パーティションの使用状況をみると、全体の20%を過ぎたあたりに仮想ディスクが割り当てられているようです。

数値を見ると、ホストOS側では125MB/sくらいのようです。ゲストOSでは、122MB/s（平均）となっていますので、大きなファイルの「転送速度」はほとんど同じと言ってよさそうです。

平均アクセス時間の内訳を分析すると小さなファイルのアクセス性能を推測できそうなので、表にしてみました。

-	平均シーク時間	平均待ち時間	オーバーヘッド	合計
ホストOS	9ms	4.2ms	2.3ms	15.5ms
ゲストOS	0.2ms	4.2ms	3.8ms	8.2ms

「シーク時間」や「待ち時間」はハードウェア毎に決まった時間があります。その時間を引けば、OSの持つ「オーバーヘッド」を把握できると思います。

一つのファイルを処理するための「オーバーヘッド」は「3.8ms」くらいですが、ホストOSの「2.3ms」と比べてもそれほど悪くない値のようです。相応の「シーク時間」と「待ち時間」を加えると、（仮想ディスクのサイズにもよりますが）実際の平均アクセス時間は「6.7ms:8.5ms」程度なので、小さなファイルを大量に処理する操作以外では、速度差を体感するのは難しいように思います。

以上、「仮想マシン（VirtualBox）」のディスクアクセス性能は「思った以上に高かった」というお話でした。

補）個人的には「7割程度」の性能でも十分と考えていました。（2010年発表のビジネス用途向けパソコンで調査しました。）

特別な事情がなければ、パーティションを細切れにしてマルチブート環境を作るよりも、仮想環境で同時に複数のOSを動かす方が便利に作業できそうですね。私の場合はWindows7とのマルチブートですが、これにはもちろん特別な事情があります。

ext4パーティションとLinuxカーネルの既知のバグ（VirtualBox）

新しいハードディスクにVirtualboxをインストールして古いハードディスクにあった仮想ディスクを移設すると、起動時に次のメッセージが表示されるようになりました。

メッセージの意味はよくわかりませんが、「違うファイルシステム」なら問題を避けることができそうです。以前は、VirtualBoxを「ext4」にインストールして、仮想ディスクを「ntfs」に置いていました。奇妙な使い方でしたが、今回の問題を（偶然）避けていたようです。

補）「put the disk image and the snapshot folder onto a different file system」としていました。

今回は、両方を「ext4」に導入しています。使い方を正したつもりでしたが「警告」を受けたのでファイルシステムを変更することにしました。「新しいから」という理由だけで「ext4」を使っていましたので、変更に抵抗はありません。

補）「located on an ext4 partition」→「located on an ext3 partition」としました。

ファイルシステムを「ext3」に変更すると、警告は出なくなりました。

入れ替えたあとで気が付いたんですが、「VirtualBoxの設定を変更する」という選択肢もあったようです。英語が苦手ということもあるんですが、「既知のバグ」という言葉に過剰に反応したようです。

補） 「enable the host I/O cache permanently in the VM settings」としませんでした。

振り返ると、警告を避けるために3つの選択肢があったのですが、最も手間のかかる方法を選択しました。

最終的な判断の根拠は乏しいので、この選択が正しいのか、間違っているのか、今のところわかりません。

「ext3」と「ext4」の違い：

エクステントは、ext2およびext3で使われてきた伝統的なブロックマッピング方式を置き換える概念である。エクステントは連続した物理ブロックの集合であり、大きなファイルに対するパフォーマンスを改善し、フラグメンテーションの発生を減らすことができる。ext4におけるエクステントは、4KBのブロックサイズで最大128MBまでの連続した領域をマッピングすることができる。inodeごとに4つのエクステントを格納することができる。ひとつのファイルに5つ以上のエクステントがあるとき、残りのエクステントはHtreeで構造化される。

「エクステント」という概念の有無が大きな違いのようです。

仮想ファイルは大きなファイルなのでパフォーマンスやフラグメンテーションの発生で多少不利な面がありそうですが、これは程度問題なので、致命的な不具合の発生を事前に避けられたことをよしとしたいと思います。