いまから5〜6年前だろうか。「ネットブック」、あるいは「ミニノート」と呼ばれるコンピュータがはやったことがあったのを覚えていらっしゃるだろうか。
比較的能力の低いCPU、狭い液晶画面、小さなHDD、少ないメモリ領域という形で、性能をぐんと抑えつつ価格を5〜6万とものすごく安くしたコンピュータである。
ただ、その後間もなく登場したタブレット機器に押されて、一気に下火になり、今は店頭で見かけることもまずなくなってしまった。

さて、私の手元には、2008年9月に投入したこのネットブックがある。Acer Aspire ONE、AOA-150Bbである。
性能はといえば、

• CPU…Intel Atom N270 (1.6GHz, デュアルコア)
• メモリ…1GB (増設不可)
• ハードディスク…160GB
• プリインストールOS…Windows XP Home Edition

というものである。ちなみに、私が欲しいなぁと思っているタブレット、Xperia Z2タブレットでは、

• CPU…Snapdragon 801 (最大2.3GHz, クアッドコア)
• メモリ…3GB
• 記憶容量…32GB
• プリインストールOS…Android 4.4

と、ストレージさえ除けば処理性能は圧倒的に上回っている。もうそんなボロいネットブックなんて処分してしまえばいいとは思うのだが、そこは「もったいない」精神が働くというわけで、できる限り現役のまま使ってあげたいというのが私の気持ちである。

現在このネットブックは、Ubuntu 12.04 LTS(当然32ビット版)が動作している。以前はWindows XPとのデュアルブートであったが、XPのサポート終了に伴ってWindows領域を削除、さらにディスクパーティション構成を組み替えて、完全にUbuntu専用機になっている。
なお、さすがに処理性能を考えて、Unityは2Dとしてある。他の軽量デスクトップも考慮に入れてはあるのだが、持ち歩いて頻繁に使うこと、電源性能(サスペンド、ハイバネートのしやすさ)の問題で、重いがUnityを使用している。

で、これがどれだけ遅いのかということだが、簡単なベンチマークということで、Google ChromeとFirefoxを、起動後Unity操作可能時点で同時にクリックし、両方が起動する時間を測定してみることにした。Google ChromeもFirefoxも、数個のタブがすでに開いており、それを読み込みながら起動する設定となっている。

• Google Chromeの画面(どこか1つ)が出てくる時間…4分10秒
• Firefoxの画面(どこか1つのタブ)が出てくる時間…7分30秒

普通のコンピュータでブラウザ1つを立ち上げるのに7分かかっていたら処分した方がよいに決まっている。

このようにとんでもなく遅い原因はメモリ不足である。最近のブラウザであれば、数個タブを開いていれば1GBなんてあっという間に食ってしまう。つまり、ブラウザを立ち上げていると(もちろん、起動直後なので、他のプロセスも次々に起動しているが)メモリを食い、1GBを使い尽くすと、今度は仮想メモリ(スワップ)領域へのデータ移動が始まり、両方でディスクアクセスを取り合ってずっとディスクにアクセスしたままになる、という構図である。
(なお、この実験のときには、スワップのしやすさを表す数値 swappinessは通常の60から10へと変更して、よりスワップがかかりやすくしている。)

この遅いマシンを何とか改善したい。そこで目をつけたのは、使われずに自宅で放置されていた2GBのSDカードである。
Aspire ONEには2つのカードスロットがある。1つは右側にあるSDカード専用スロット、1つは左側にある、SDカードなどいろいろなカードを読み込めるマルチカードリーダースロットである。
作戦としては、このどちらかにSDカードを挿入、スワップ領域をこちらに移設して、高速なアクセスを実現させようというものである。
なお、大量のアクセス(読み書き)が発生するため、SDカードの寿命は著しく短くなってしまうが、もともと使われていなかったSDカードなので、そう惜しいという気持ちはない(もし皆さんが実践されるときには、その点よく注意して欲しい)。

作戦はこうである。

• Aspire ONEのSDカードスロットにSDカードを挿入
• 起動時にマウントさせるように認識、かつそれがスワップ領域であるようにする
• スワップ領域をこのSDカードに割り当て
• swappinessを調整してわざとスワップされやすいようにする

今回は、左側のマルチカードリーダースロットをスワップ用SDカードに割り当てた。これは、Ubuntu上では/dev/mmcblk0p1として参照することができる。
普通に挿入するとリムーバブルメディアとして認識されてしまうので、まずマウントを解除、次にディスク領域をスワップ領域として確保する。これは、Ubuntu付属の「ディスク」ツール、GParted、コマンドラインからであればfdiskなどいずれかで可能である。これらでSDカード領域をまるごとスワップ領域にする。

最後に、起動時に必ずマウントされるようにするため、/etc/fstabをちょっとだけ改良する。もしもともとスワップ領域を設けているのであれば、そのエントリーを参考に次の行を付け加える。なお、もともとあるスワップ領域の行は消さないで、先頭に「#」を入れておき、コメントで無効にする。

/dev/mmcblk0p1 none swap sw 0 0

これでOKだ。再起動するか、

sudo swapoff /dev/sda4　(デバイス名は機器によって変更すること)
sudo swapon /dev/mmcblk0p1

を実行すれば、新しいSDカード上のスワップ領域が有効になる。cat /proc/swapsにより、スワップ領域の使用状況を確認することが可能だ。一応、確認しておこう。

次は、スワップしやすくしてしまう(積極的にメモリからSDカードに「吐き出す」)設定である。これは、swappinessという数値をいじる。この値は、スワップのしやすさを表す数値で、0に近づくほどスワップしにくくなる。通常は60であり、最近の大容量メモリを搭載した機種では10や0という値をとることも珍しくないが、今回は逆に、80や90という値にしよう。これを設定するのは、/etc/sysctl.confというファイルである。ここに1行、こういうふうに記述する。

swappiness = 90

再起動してこの設定を有効にすれば、準備完了である。
それでは、どのくらい速くなったかを調べてみよう。先ほどと全く同じ設定で、起動直後にGoogle ChromeとFirefoxを起動して、両者のタブ(のうち1つ)が操作可能になる時間を測定する。まず、swappinessが60(デフォルト値)の場合。

• Google Chrome…3分33秒
• Firefox…2分ちょっと(10秒程度。このとき計測がうまくいかなかった)

まぁもちろんまだ遅いといえば遅いが、先ほどのケースからすれば劇的に改善された。さらに、swappinessを90とし、preloadを有効にした上で(いままではメモリが少ないので有効にしなかった)改めて測定する。

• Google Chrome…2分40秒
• Firefox…2分10秒

となる。Google Chromeで性能が向上しているのは、タブあたりのメモリ割り当てが多いGoogle Chromeで効果が顕著に出ていることを示していると思われる。
もちろん、Firefoxが起動して2分もかかって表示されるのはそれでもイライラするかとは思うが、起動したあとしばらく待ってマシンが落ち着いてから起動するようにするなど、運用を工夫すれば若干気分的にも改善できると思う。
なお、この時点でスワップ領域の消費量は300MBほどで、2GBのSDカードの10数パーセントである。

いろいろ書いたが、この方式は、いってみればWindowsのReadyBoostと同じような考え方で、HDDよりは高速な半導体デバイスに記憶領域を間接的に移動させるというアイディアである。
同じ考え方はデスクトップ機にも応用可能である。例えば、使用していない2GBや4GBのUSBメモリなどが余っているのであれば、それらをスワップとして割り当ててやれば、メモリが少ないマシンでも高速化の効果が出る可能性はある。

ただ、この設定で運用を行って以来、サスペンドやハイバネートが効かなくなってしまった。
サスペンドについては原因が不明である。
ハイバネートは、このSDカードの領域が足りないためと推測される(Write errorが出るのだが、SDカードそのものの検査を行ってもディスクエラーは確認されない)。そこで、ハイバネートをかけたい場合、いったん無効にしたHDD上のスワップ領域を有効にする。

sudo swapoff /dev/mmcblk0p1 && swapon /dev/sda4

これでハイバネートは元に戻るが、運用上面倒ではある。このあたり、いいアイディアがあれば追求してみたいが、もう6年ものとなっているネットブックがいつまで持つかという点も問題ではある。

【2014年8月28日追記】その後のスリープ・ハイバネート対応を別記事にまとめてみました。参考になさってください。

続いて、メインマシンであるX220のSSDへの交換へと移りました。

今回の場合やっかいなのは、ファイルシステムが2種類(正確には3種類)あることです。このマシンは半分をWindows,半分をLinux (Ubuntu)のデュアルブートとして構成しているので、Windows用のNTFS、Linux用のext4という2つのファイルシステム(さらに、Linuxのスワップ領域)が混在しているのです。このため、通常のNTFSしか想定していないディスククローニングツールではコピーができません。実際、X61で使用したNTI Echoを使っても、ext4領域は認識すらしてくれません。

また、当初320GBだと思って買ってきたIntel SSD 320が、実際の容量としては300GBであったことが判明。このため、X220の換装もパーティションを縮小してコピーする必要が出てきてしまいました。
そこで、すべきこととして、

• まず、ファイルシステム全体を縮小し、300GBに収まるように調整する。
• 次に、ディスク全体をコピーする。不可能であればパーティションごとにコピーをする。
• ブート領域(MBR)をコピー

という3段階のステップを踏むことにしました。

まずはファイルシステムの縮小です。NTFSの縮小は、Acronis Disk Directorを使用しました。Parted Magicはこの時点ではまだ不安があったので使用しませんでした。
一方、ext4の領域変更はParted Magicを使用。私のコンピュータでは、/パーティションと/homeパーティションの2つの領域を作っているのですが、/領域にかなり空きがある一方で、/home領域が若干ディスクを圧迫しているので、領域の再デザインも一緒に実行しました。

続いて、ディスク全体のコピー。Parted Magicでもやはり縮小コピーができなかったので、Parted Magicを使って、NTFSとext4についてパーティションごとにコピーを行っていきました。NTFSもext4も、コピーは問題なく終了です。

最後はMBR領域のコピー。これについては、原始的な(苦笑)ddコマンドを使用します。
dd if=/dev/sda of=./sda.mbr count=446 bs=1
dd if=./sda.mbr of=/dev/sdb
ここで、count=446としてあるのは、MBRのうちブート部分だけをコピーしたためです。512としますとパーティションテーブルもコピーすることになりますが、当然2台のディスクのパーティションテーブルは異なっているので、もし512でやってしまうと大変なことになります(実際一度やって、コピー先のディスクのパーティションを消してしまいました)。

さて、これで起動…
…してみると、うまく起動しません。
どうやら、起動用のgrubは隠し領域を持っているようで、これがうまくコピーできなかったためのようです。

そこで今度は、Parted Magicについてきた、grub doctorを使用します。その名の通り、grubに問題が発生した際に診断をしてくれるという便利なツールであります。grub doctorを起動すると、いくつか対話的な質問が出てきます(例えば、どの領域にgrub.confがあるか、など).それに間違いなく答えれば、再度grub領域を作成してくれるというわけです。2〜3の簡単な質問に答えて、無事インストールされたことを確認、再度起動すると…
うまくいきました！　grub画面が出てきて、Linux (Ubuntu)もWindowsもちゃんと起動してくれます。

今回いちばんの問題だったのは、ディスクそのものの挿入でした。
Intel 320 SSDシリーズは、SSD本体の上に、黒い枠のようなものがついてきます。どうもこのSSDはデスクトップマシンにインストールされることを考えているようなのですが、この黒い枠があるおかげで、X220のハードディスクスロットの入口につかえてしまって入らないのです。試しに黒い枠を外そうとしましたが、この枠を止めているネジはSSD全体を固定する機能も兼ねているためにそうもいかず。
そこで、またもやX220の分解です。
X220の裏側のネジを外し、本体全体をゆるめます。さらにキーボード固定部分も外してキーボードを取り外します。こうすると、HDD/SSDを入れるスロットの上のカバーがみえるようになります。このカバーを少し浮かせながら、まず入口から斜めにSSDを差し込み、十分入ったら水平にスライドさせて、コネクタとつなげます
…というもののこれがまた非常に難しい。1時間近く格闘した挙句、何とかつなぐことに成功しました。また、X220にもともとついてきたゴムの制振部材やケージについては、取り外さざるを得ませんでした。もっとも、黒い枠がついたままのSSDは容積ぴったりに収まっているので、十分固定されて振動に耐えるようになっています。おまけにSSDは振動に強いですし。

こうして、SSDの換装が成功しました。
今のところ、X61ほどの加速感はあまり感じませんが、特にWindows側では全体的な速度の向上を感じます。LInux側はあまりスピーディになったという印象を受けませんが、今のところ問題は発生していません。
また、X61で発生した、Windows Updateなどができなくなってしまう問題は、X220では発生していません。
電池の持ち時間についても、X220ではあまり変わらないようにみえます。ただ、私の使い方が、電池でほぼフル活用するというやり方なので、節電にあまり寄与していないかも知れません(液晶バックライトがかなり電力を消費している可能性が高いです)。

いずれにしても、X61に続き、X220でも快適なSSDライフを送ることができるようになりました。