2009/05/28

さらに縦幅が減るThinkPad

少し古くなるが、Inside the BoxにDisplay Ratio Change (again)というエントリが出ていた。内容的にはLCD画面について、
  • PC業界は4:3の比率から16:10の比率に移行したが、さらにまた16:9の比率へ移行し始めている。
  • この変化はLCDベンダーによるもので、これに関してPCベンダーはほとんど発言権がない。これに適応していくしかない。
  • だからといって、Lenovo自身がLCD工場を持つのは現実的でも効率的でもない。
  • 仮にハイエンドIPSディスプレイのオプションを出そうとすると15000の確定注文が必要。
モバイルPCのワイド化については、個人的には、
  • ユーザービリティ的には、歓迎しない。物理的に画面の縦幅が狭くなるから。広い画面が欲しい作業のときは外部モニターを使う(そういう作業は出先ではしない)。
  • サイズ的には、キーボードの大きさを確保しつつ、奥行きを短縮することで小型軽量化するということなら賛成。
このどちらが優先かというと後者だったりする。その意味では、X200は奥行きを短縮できていればサイズ的にも価値を高められたと思う。ただ、パームレストが狭いと意外に使いにくかったりするのが難点だが。

ともあれ、縦幅が狭くなることにはMatt Kohut自身もうんざりしているようで(I'm tired of losing vertical space)、Windows 7ではタスクバーを左に配置するつもりとのこと。試しにWindows 7 RCで右に縦配置してみると、こうなる。

Access Connections(5.40)は完全に切れてしまうし、省電力マネージャー(3.00)も危ない。そのうち何とかするのだろうが、これをデザイン的に破綻なくまとめるのは難しそうに思う。

(その後の状況

2009/05/18

X25-MのE9が減る

X25-Mのファームウェアの追記で触れたS.M.A.R.T.のE9の値だが、CrystalDiskInfo(2.7.2)で見たところ、目出度くというか何というか、97から96に減っていた。

先日来、Windows 7 RCのTrue Imageによるバックアップ/レストアを繰り返したことが効いたのかどうかは分からない。検証を待つ、というところだが、さて。

それから、使用時間の方はゆっくり進んでいる。基本的に止まっていて、何かの拍子に進むのではないかと思うが、これも謎。

[追記]

さらに、E9を1つ減らして95にすることに成功した。

行ったのはTrue ImageによるSSD全体のレストア(による書き込み)。予めX25-M全体のバックアップファイルをウルトラベースX6内のHDDに作成しておき、そこからX25-Mへレストアした。
  • 内容は基本パーティション×3(XP、Windows 7 RC日本語版、同英語版のブートパーティション)+論理パーティション×1。
  • パーティションの使用領域の合計は約47.54GB、ファイル数は159,926。
これを繰り返したところ、30回目(約1426GB)の後に95になっていた。この前にチェックした28回目(約1331GB)では96だったので、この間の1.4TB前後で変わったことになる。また、E1も1つ減って199になっていた。

これで、X25-Mの使用歴とE9の間に相関関係があることが確認されたといってよいと思う。

(この点は新しいエントリで整理し直した。)

ちなみに、今回の書き込み後にHD Tune Proで見たところ、最初は荒れていたが、段々元に戻っていった。

(この点も新しいエントリで整理し直した。)

2009/05/16

True Imageから直接ReadyNAS

Acronis True Imageは、Windows上では勿論、そのブータブルメディアからブートした状態でもNASへのバックアップ/レストアができる。ただ、GbEであってもローカルPCに直接繋いだストレージよりは遅いだろうと思って、これまでは使ってこなかった。ところが、実際にNASで試してみたら意外と速かった。

1. 基本的な速度

前提となるGbEの環境は以下のとおり。
  • ローカルPC: ThinkPad X61s
    • CPU: Core2 Duo L7700(1.8GHz)
    • メモリ: 4GB
    • 有線LAN: Intel 82566MM Gigabit Network Connection
  • NAS: NETGEAR ReadyNAS Duo(ST9320320AS×2)
  • ハブ: Buffalo LSW-GT-5W
この環境でReadyNAS上をフォルダをネットワークドライブとして共有し、X61s上のWindows 7 RCからCrystalDiskMark(2.2.0)で計測すると、結構な速度が出る。テストサイズは100MB(左)と、ReadyNASには256MBのメモリがあるので1000MB(右)も加えた。
  • Windows 7 RCなのは、ネットワーク速度はXPよりVista以降の方が速くなるから(自動的にパラメータを調整する機能がある)。

  • 100MBの方は、以前にX60s上のXPから計測したときより随分速い。
    • 改めてX60s、X61s上のXPから計測してみると、なぜか全体的に速くなっていた(ハードウェア構成は変わっていない)。シーケンシャルとランダム(512KB)のRead以外はWindows 7 RCと大体同じ。なお、ReadyNASのファームウェアは4.1.5にアップデートしてあるが、以前計測したときの4.1.4に戻しても同程度だったので、ファームウェアの差ではない。
    • シーケンシャルとランダム(512KB)のReadは、XPよりWindows 7 RCの方が断然速い(6割増し)。

  • 1000MBの方は、シーケンシャルのReadは依然速い。シーケンシャルとランダム(512KB)のWriteもあまり落ちてない。
ReadyNASに対して、ローカルのストレージとしては以下のとおり(他に光学メディアもあり得るが、速度面で比較にならないので除外)。
  • 内蔵SSD: X25-M
  • ウルトラベースX6内のHDD: Travelstar 5K500.B-250
  • USBメモリ: Green House PicoBoost 8GB
  • USB外付けHDD: LaCie Little Disk 500GB
これらのCrystalDiskMarkによる速度は以下のようになる。テストサイズは、バックアップ/レストアではGB単位のデータを扱うので1000MBで計測したが、ReadyNAS以外は100MBと1000MBで特に違いはなかった。

(注)テストサイズを1000MB、試行回数を5回とし、3回連続で計測した値の平均。

USB勢のシーケンシャルとランダム(512KB)のWriteが遅いが、これはX61sのUSBの宿痾といえるもの。X60sではもっと速い。

2. バックアップ/レストアの処理時間

これらのストレージを使ったバックアップ/レストアにかかる時間を以下の条件で手動計測。
  • バージョンはAcronis True Image 11 Home (build 8219)。設定は圧縮レベルを「高」とする以外はデフォルト。
  • 対象はX61sにWindows 7 RCをクリーンインストールし、Lenovoのドライバを入れたパーティション。
    • パーティションの使用領域は8.25GB、ファイル数は57,706。
    • バックアップファイルのサイズは2.83GB(圧縮レベル「高」の状態)。
  • 以下の2通りの場合で実行。
    • Windows 7 RC上で、これにインストールしたTrue Imageから別のWindows 7 RCのあるパーティションをバックアップ/レストア。
    • PicoBoostをTrue Imageのブータブルメディアとし、これからブートした状態のTrue Imageからバックアップ/レストア。
さて、結果は以下のようになった。


さらに、この処理時間でバックアップファイルのサイズを割って処理速度を出すと以下のようになる。


これは単純にストレージの転送速度に依るものではないが、
  • バックアップでは、ReadyNASは内蔵SSDとウルトラベースX6内のHDDに比べてさほど遜色がない。USB勢に対しては、X61sのUSBによるハンデがあるとしても、ReadyNASの優位は変わらないと思う。

  • レストアでは、ReadyNASはWindows 7 RC上では一番遅いが、内蔵SSDより少し遅い程度。ブータブルメディアからブートした状態では内蔵SSDとウルトラベースX6内のHDDに比べてかかる時間は倍程度になる。USB勢に対しては、ReadyNASの方が少し速い(レストアではUSB勢もハンデはない)。
実際の使用場面を考えると、バックアップはWindows上で、レストアはブータブルメディアからブートした状態で行うことが多いと思うが、この場合、ReadyNASはバックアップでは内蔵ストレージとさほど変わらず、レストアでは内蔵ストレージの倍程度の時間で済み、いずれもUSBより遅くなることはないといえる。勿論、この優劣関係は実際のストレージの構成によって変わってくるが。

したがって、バックアップファイルをNASに保存しておくポリシーであれば、一旦ローカルのストレージにコピーするようなことをせずとも、直接NASとの間でバックアップ/レストアする方が、手間的にも(普段通りにネットワークに繋いだ状態からUSBメモリを挿せば開始できる)、時間的にも(コピーする時間も合わせれば)有利ということになると思う。

2009/05/13

金属なUSBメモリ

USBメモリで進む容量増加/価格下落で、気が付けばOS環境そのものをUSBメモリに入れてブートしたり、バックアップ/レストアすることも普通に可能になっている。そこで手持ちのUSBメモリで試してみたが、千単位のファイル数やGB単位のデータ量となるとUSBメモリの速度の問題が馬鹿にならない。

これまでUSBメモリは速度よりコネクタが収納できるなどの機能で選んできたが、改めて速度を計測してみて、その遅さに愕然とした。

ここは速いものも持っておこうと調べてみたら、高速なUSBメモリはVistaが出た頃が旬で、その後は頭打ちどころか、SLCからMLCへの切り替えでライト速度が大きく落ちたものもあって、博打っぽいことになっているらしい。

1. 金属筐体

結局、値は張るがこれなら大丈夫だろうというのを1本と、まあ外れてもいいやというのを1本注文した。Green HouseのPicoBoostの8GB(GH-UFD8GBS)と、CFDのCUFD-Hの2GB(CUFD-H2G)だが、到着したものを見ると、別に狙ったわけではないが、両方とも筐体が一部金属になっていた。手持ちにあったSanDiskのCruzer Titaniumと並べるとこんな感じ。

左からPicoBoost、CUFD-H、Cruzer Titaniumだが、筐体の構造が全然違うのが面白い。
  • Cruzer Titaniumの金属無垢に対して、CUFD-Hは半透明のプラスチックの上下にプレス絞りのアルミ板を被せた厚みのある形、PicoBoostは側面の枠状のプラスチックを上下からアルミ板で挟んだ極薄の形をしている。

    PicoBoostの開発者はとにかく薄くしたかったのだろうと思う。CUFD-Hの開発者はプラスチックのベースのままでも高級感を出したかったのだろうが、惜しむらくはアルミ板の角の部分にプレス加工時の皺が出ていたり、本体とキャップに微妙なズレがあったりして仕上がりが今一つ。

  • 重量面では、Cruzer Titaniumが22gで一番重く、次いでCUFD-Hが14gで体積の割には軽く感じる。PicoBoostは10gで見た目相当。

  • 堅牢性では、やはりCruzer Titaniumは全くびくともせず、頭抜けていると思う(コネクタ内部が剥き出しではあるが)。CUFD-Hも厚みのある分、丈夫そうに見える。残るPicoBoostは不安を感じる程ではないが、扱いに気を付けた方が良さそうではある。
2. 速度

最初の目的の速度を、既に手持ちのものも併せてThinkPad X60sに挿した状態でCrystalDiskMark(Ver.2.2.0)で比較した。ファイルシステムはFAT32。

右から
  • IBM USB 2.0 High Speed Memory Key 128MB
  • Transcend JetFlash V30 1GB (ReadyNAS Duoの同梱品)
  • Transcend JetFlash V10 1GB
  • Sandisk Cruzer Micro 1GB
  • Sandisk Cruzer Titanium 1GB
  • CFD CUFD-H 2G
  • Kingston DataTraveler 100 4GB
  • Green House PicoBoost 8GB

(注)テストサイズを100MB、試行回数を5回に設定し、3回連続して計測した値の平均。
  • PicoBoostとCUFD-Hは期待通りの速さ。これなら最速級といえる。
  • Cruzer TitaniumとMicroは筐体の材質(Microは柔なプラスチック)以外に書き込み速度も違うのを初めて知った。TitaniumはSLCでMicroはMLCなのかもしれない。
  • このTranscend勢は遅い。価格相応か。
3. セクタ0

USBメモリのブートに関係するセクタ0だが、PicoBoost、CUFD-Hの両方とも初期状態でMBRになっており、基本パーティションが設定されていた。

ただし、PicoBoostではPeToUSBでパーティションテーブルを見ると以下のように、パーティションがActiveになってなかった(パーティションの先頭セクタもセクタ8064と、何か変)。

実際、このままAcronis True Imageのブータブルメディアビルダを実行してもブータブルにはならなかった。

一方、CUFD-Hの方では以下のように、極めて普通。パーティションがActiveで、このままブータブルにできる。

メーカーとしても、ユーザーが(それと意識しなくても)スムーズに使えるようにしておいた方がサポートが楽だと思うが。

2009/05/12

True ImageとUSBメモリのブート

Acronis True Image 11 Homeでは付属のブータブルメディアビルダでTrue ImageのブータブルUSBメモリを作成できるが、これが成功したり失敗したりする。こういうときに理由が分からないのが一番厄介なので、理由を調べてみた。なお、USBメモリがUSB-HDDとして認識されることが前提。

1. 成功させる方法

先に、ブータブルメディアビルダを実行しても失敗する場合に、これを成功させるための事前準備の方法を挙げておく。いずれもブータブルメディアビルダの前にUSBメモリに行っておくもの。

1.1. PeToUSBを使う(XP、Vista以降とも)

PeToUSB自体はBartPE/WinPEを目的としたツールだが、今回の目的にも使える。最も簡単。これをダウンロードし、PeToUSB.exeを実行すると(Vistaでは管理者として)、以下の画面が出る。

「Enable Disk Format」にチェック。その横のオプションは必須ではない。「Start」で実行すれば準備完了。

(注)PeToUSBはFAT(FAT16)でフォーマットするが、FAT16にはパーティションの最大サイズが4GBという制限があるので(Windows XPでFAT16ファイルシステムを使用した場合のパーティションの最大容量)、4GBを超える容量のUSBメモリはフォーマットが完了しない。この場合は、その後に「ディスクの管理」でFAT32でフォーマットし直せばよい。

1.2. VistaのDiskPartを使う(Vista以降の場合に)

Vistaの「ディスクの管理」ではなくコマンドラインのDiskPartを使う方法。なお、XPのDiskPartではUSBメモリを認識できないので無理。


  1. 管理者としてコマンドプロンプトを開き、「diskpart」と実行。するとDiskPartが起動する(カレントがDISKPARTになる)。
  2. 「list disk」と実行(認識されているディスクを表示)。
  3. 対象のUSBメモリを容量等から判断し、例えば「Disk 1」であれば「select disk 1」と実行(ディスクを対象として選択)。
  4. 「clean」を実行(対象ディスクの既存データ/パーティションを削除)。
  5. 「create partition primary」を実行(全容量で基本パーティションを作成)。
  6. 「active」を実行(作成した基本パーティションをアクティブにする)。
  7. 「format fs=fat32」を実行(FAT32でフォーマットする。これはFATでも構わない。なお、フォーマットは「ディスクの管理」から行っても同じ)。
  8. 「list partition」を実行し、アクティブな基本パーティション(Typeが「プライマリ」で左端に「*」が付く)が作成されていることを確認(これは必須ではない)。
  9. 「exit」でDiskPartを終了。
以上で準備完了。なお、操作順によっては、6.の前に対象のパーティションを選択する(「list partition」を実行し、例えば「partition 1」であれば「select partition 1」と実行)必要があることがある。

1.3. Windows PE 2.0を使う(XPの場合に)

やることはVistaのDiskPartと同じで、VistaベースのWindows PE 2.0のブータブルCD/DVDをXP上で作成し、そこからブートしてVistaのDiskPartを使う方法。とくに難しくはないが、手間はかかる。


  1. Microsoftから「Windows Vista SP1およびWindows Server 2008用の自動インストールキット(AIK)」をダウンロードする。これはISOファイルなので、CD/DVDに書き込むか仮想ディスクにマウントするかした上で、インストールする。
  2. 「Windows PE Toolsコマンドプロンプト」を開く。
  3. DiskPartは標準状態で使えるので何も追加する必要はない。したがって、例えば作業フォルダを「c:\bootwork」として「bootwork.iso」というISOファイルを作成するとすれば、以下を実行。
    copype x86 c:\bootwork
    oscdimg -n -b"etfsboot.com" ISO bootwork.iso
  4. 作成されたISOファイルをCD/DVDに書き込み、これからブートすれば自動的にコマンドプロンプトに入るので、後はVista上のDiskPartと同じ。
これらの準備の後、ブータブルメディアビルダを実行すればよい。

ちなみに、「HP USB Disk Storage Format Tool」というツールを使う方法もあるが、Hewlett-Packardのダウンロード条件が不明で、EULAを読む限りHewlett-Packard製品の存在が前提のようなので、除外した。手数もPeToUSBの方が少なくて済む。

2. ブートの基礎

USBメモリからのブートの話に入る前に、フロッピーディスクとHDDの場合のブートについて押さえておくと、
  • フロッピーディスクでは、先頭のセクタ(セクタ0)はブートセクタになっており、ブートコード(呼ばれ方は色々あるが、ブート用の小さなプログラム)がある。ブート時にはブートセクタが読み込まれ、そのブートコードがデータ内のOSを立ち上げる。

  • HDDでは、セクタ0はMBR(Master Boot Record)になっており、ブートコードとパーティションテーブル(パーティションの位置/長さ/Activeか等を記録)がある。一方、ブートセクタは基本パーティションの先頭セクタ(XPまではセクタ63、Vista以降はセクタ1282048)にある。ブート時にはまずMBRが読み込まれ、MBRのブートコードがパーティションテーブルからActiveな基本パーティションを探し、そのパーティションのブートセクタが読み込まれ、以下同上。

    (注)Vista以降で作成したパーティションの先頭セクタは、そのデバイスの容量が8GB以上の場合はセクタ2048になる模様。
したがって、フロッピーディスクとHDDでは以下の違いがある。
  • セクタ0がブートセクタか(フロッピーディスク)、MBRか(HDD)
  • ブートの過程にMBRが入るか(HDD)、否か(フロッピーディスク)
3. 観察

さて、実際のUSBメモリ内がどうなっているかについて、セクタの内容をDisk Probe(Support Toolsに含まれるツール)で直接確認しつつ観察してみた。

対象のUSBメモリはIBMの「128MB USB2.0 高速メモリーキー」。古い製品だが、True Imageのブータブルメディアに入るファイルは50MBぐらいだし、IBMによる「Memory Key Boot Utility」が使える。

PCはThinkPad X61sで、このUSBメモリを挿すと(他のUSBメモリも)USB-HDDとして認識される。

3.1. 成功の場合

まずブータブルUSBメモリの作成に成功する場合、実際に何が行われるかというと、準備段階では、

(PeToUSBの場合、自動的に以下が行われる)
  1. セクタ0をMBRとして、MBRのブートコードを書き込む。
  2. 基本パーティションを作成する(MBRのパーティションテーブルに記録。パーティションの開始セクタはセクタ63)。
  3. パーティションをActiveに設定する(同上)。
  4. パーティションをFATでフォーマットする(OSのライブラリを使うらしい)。
  5. フォーマットの際、パーティションのブートセクタにそのOSのブートセクタが書き込まれる(XP上ではXPの、Vista上ではVistaのブートコード)。
(VistaのDiskPartの場合、以下を行う)
  1. 「clean」で既存データ/パーティションを削除する。この際に、自動的にセクタ0をMBRとして、MBRのブートコードが書き込まれる。
  2. 「create partition primary」で基本パーティションを作成する(MBRのパーティションテーブルに記録。パーティションの開始セクタはセクタ1282048)
  3. 「active」でパーティションをActiveに設定する(同上)。
  4. 「format fs=fat32」でパーティションをFAT32でフォーマットする。
  5. フォーマットの際、自動的にパーティションのブートセクタにVistaのブートコードが書き込まれる。
(IBMのMemory Key Boot Utilityの場合、自動的に以下が行われる)
  1. セクタ0をMBRとして、MBRのブートコードを書き込む。
  2. 基本パーティションを作成する(MBRのパーティションテーブルに記録。パーティションの開始セクタはセクタ2)。
  3. パーティションをActiveに設定する(同上)。
  4. パーティションをFATでフォーマットする。
  5. パーティションのブートセクタにPC-DOS(IBM版のDOS)のブートコードを書き込む。パーティション内にPC-DOSの基本ファイル(IBMBIO.COM、IBMDOS.COM、COMMAND.COM)をコピーする(これらのデータは内蔵)。
この後にブータブルメディアビルダを実行すると、自動的に以下が行われる。
  1. 既存のパーティションのブートセクタにLinuxのブートコードを上書きする。
  2. パーティション内にLinuxのカーネル等のファイルをコピーする。
ここまで行うとUSBメモリは以下のようになる。
  • セクタ0にはMBRのブートコードがあり、パーティションテーブルには基本パーティションがActiveに設定された状態で記録されている。
  • パーティションの開始セクタ(準備の方法によって位置は異なるが)にはブートセクタがあり、Linuxのブートコードがある。
つまり、HDDの場合と同じ構成になる。また、準備段階でブートセクタに書き込まれる各OSのブートコードはLinuxのブートコードで上書きされるので、何でもいいことになる。

3.2. 失敗の場合

試しにUSBメモリのセクタ0を消去した(Disk Probeを使って0で埋めた)状態でXPの「ディスクの管理」で見ると、フォーマットしかできない状態になっている。これをFAT32でフォーマットすると、
  1. 自動的にセクタ0をブートセクタとして、XPのブートコードが書き込まれる。
この状態のUSBメモリにブータブルメディアビルダを実行すると、
  1. セクタ0のブートセクタにLinuxのブートコードを上書きする。
  2. Linuxのカーネル等のファイルをコピーする。
こうするとUSBメモリは以下のようになる。
  • セクタ0にファイルシステムがFAT32のブートセクタがあり、Linuxのブートコードがある。
つまり、フロッピーディスクの場合と同じ構成になる。この状態ではブート時にエラーを出してブートできない。

ここまでをまとめると、以下のように言ってよいと思う。
  • (USB-HDDと認識される場合に)USBメモリからブートできるためには、HDDと同様にMBRとActiveな基本パーティションが存在する必要がある。これはUSBメモリのブートにはMBRが必要と言われていることと符合する。


  • ブータブルメディアビルダは、既存のブートセクタへのLinuxのブートコードの上書き、Linuxのファイルのコピーはするが、そのUSBメモリがそもそもブータブルかどうかの面倒は見ない(少なくともこの環境では)。
4. 「ディスクの管理」の責任

観察していて気付いたが、「ディスクの管理」はUSBメモリのセクタ0の状態によって、フロッピーディスクと同様に扱うか、HDDと同様に扱うかを、それと明示せず自動的に切り替えている。

以下は、フロッピーディスクと同様の場合(A)とHDDと同様の場合(B)について、XPの「ディスクの管理」からUSBメモリの部分を切り出したもの。
  • A1は大概のUSBメモリは初期状態でこうなっていると思うが、セクタ0がブートセクタになっており、FAT32でフォーマットされた状態。これではブートできず、セクタ0のブートセクタをMBRに置き換えなければ(中のデータは全て消える)、ブータブルにはできない。
  • A0はMBRを消去した(0で埋めた)状態で、「ディスクの管理」ではフォーマットしかできない。USBメモリを初期化するようなツール(実際は全部0で埋める)を使ってもこうなると思う。これをFAT32でフォーマットするとA1になる。

  • B1はブータブルな状態で、A1にはない「(アクティブ)」が付いている。セクタ0がMBRになっており、FAT32でフォーマットされたActiveな基本パーティションがある。
  • B0-1はMBRはあるがパーティションはない状態で(セクタ0にMBRのブートコードはあるが、パーティションテーブルは空)、このような状態のHDDと同様に「未割り当て」となっている。VistaのDiskPartで「clean」だけを行うとこの状態になる。
  • B0-2はB0-1の状態からパーティションの作成だけを行った状態で、見かけ上はA0と同じになる。これだけなら「ディスクの管理」からも可能。
  • B0-3-aはB0-2の状態からパーティションをActiveにした状態で、「(アクティブ)」が付いている。なお、USBメモリ内のパーティションをActiveにするのは「ディスクの管理」からはできないので、VistaのDiskPart等で。
  • B0-3-bはB0-2の状態からパーティションをFAT32でフォーマットした状態で、見かけ上はA1と同じになる。A1とは違って、パーティションをActiveにすれば、このままブータブルにできる。
したがって、USBメモリを「ディスクの管理」で見ただけでは何がどうなっているのか分からないという状態に陥りがちで、「ディスクの管理」の責任は大きいと思う。なお、これはXPとVistaの「ディスクの管理」に共通で、Windows 7 RCでも変わってないので、当分このままだろう。

5. まとめ

(USB-HDDと認識される場合に)ブータブルメディアビルダによってTrue ImageのブータブルUSBメモリの作成が成功するかは、その前にUSBメモリがブータブルな状態になっているか(MBRとActiveな基本パーティションがあるか)に依るが、
  • その状態が「ディスクの管理」からは分かりにくい(そうと知らなければ全く分からない)
  • 初期状態のUSBメモリにはブータブルな状態のものと、そうでないものが混在している(おそらく)
ことが、成功したり失敗したりする理由のように思う。したがって、はまってしまったときはMBR(セクタ0)を直接覗けるツールで確認してみるのも一つの方法である。

6. その他

作業の過程で発見したこと。

6.1. DOSのブータブルUSBメモリ

自分でも認識してなかったが、USBメモリでブートできるような状態であれば、他のデバイスからDOSをブートしたときもドライバなしでそのUSBメモリが見える。したがって、Windows 98の起動フロッピーディスク(FDISK、FORMAT、SYS入り)があれば、普通にFDISKでの基本パーティション作成とActive指定、FORMAT、SYSによるシステム転送でMS-DOSのブータブルUSBメモリが作成できる。

一方、PC-DOSはといえば、PC-DOSの起動フロッピーディスクを持っている人は多くないだろうから(自分は持っていたが、とっくにフロッピーディスクが死んだ)、IBM/LenovoのUSBメモリでMemory Key Boot Utilityを使うのがほとんど唯一の方法のように思う。これが便利なのは、LenovoとHGSTのツールは今でもPC-DOSベースなので、このフロッピーディスクのファイルをそのまま上書きすればそのブータブルUSBメモリが作成できること(Feature Toolで確認)。

6.2. Syslinux

SyslinuxでMBRの書き込みができるはずだが、Syslinux.exe(3.75)を-maを含めてオプションを色々変えて試したが、セクタ0が既にブートセクタになっている状態でこれを上書きする形でのMBRの書き込みはできなかった(この環境では)。Syslinuxでは対象デバイスの指定にドライブレターが必要で、すなわちセクタ0が空の状態では使えないので、単体ではMBRを作成できず、ブータブルな状態にできないことになる。

6.3. Rescue and RecoveryのブータブルUSBメモリ

現在のThinkPadにはリカバリー/バックアップ用ツールとしてRescue and Recoveryがプリインストールされている。これ自体の良し悪しはあるが、このVista版から作成できるレスキューメディア(ブータブルCD/DVD/内蔵HDD/USB接続HDD)はVistaベースのWindows PE 2.0なので、USBメモリを1.2.のVistaのDiskPartを使う方法で準備し、レスキューメディアのファイルをコピーすれば、そのブータブルUSBメモリを作成できる(4.21で確認。ブート時に少し違うところがあるが)。

なお、Rescue and RecoveryのXP版のレスキューメディアはWindows PE 1.x(正確なバージョンは不明)で、これをUSBメモリに移植する方法は分からない。

6.4. セクタ0の直接編集

あまり勧められる方法ではないが、Disk Probeで直接USBメモリのセクタ0を編集してブータブルな状態にすることも可能。発想としてはHDDのMBRをコピーして修正の上でUSBメモリに書き込むもの。当然ながら間違えると危険なので、予めTrue ImageでHDDをバックアップしておいた方がよいと思う。

一般的にMBRの内容は以下のようになっている。

流れとしては以下のようになる。
  1. Disk Probeを起動し(Vistaでは管理者として)、現在ブートしているHDDをHandleに入れ、Read OnlyのままActiveとし、セクタ0を読み込む。これをファイルに保存し、HDDをHandleから外す。
  2. 保存したファイルを開き、Signatureからパーティションテーブルの終わりまで(01B8から01FDまで)を0で埋め、ファイルに上書きする。
  3. USBメモリをHandleに入れ、Read Onlyを外してActiveとし、セクタ0を読み込む(HDDのセクタ0でないことを確認)。保存していたファイルを開き、USBメモリに上書きする。Disk Probeを終了。
  4. USBメモリを一旦外して挿し直す(Disk Probeによる変更を認識させるため)。
  5. 「ディスクの管理」を開き、USBメモリが「未割り当て」の状態になっているはずなので、パーティションを作成し、フォーマットする。
  6. 再度Disk Probeを起動し、USBメモリのセクタ0を読み込む。最初のパーティションのブートフラグ(01BE)が00になっているはずなので、これを80に修正し、USBメモリに書き込む。
以上の作業で、USBメモリがブータブルの状態になるはず(実際の起動にはOSのファイルが必要)。
  • VistaによるMBRのブートコードでは、この方法で4GBのUSBメモリもブータブルにできた。
  • XPによるMBRのブートコードでは、2GBまでのUSBメモリは問題なかったが、4GB以上のUSBメモリはブータブルにできなかった。ブートコードに微妙な違いがあるらしい。なお、この状態からMBRのブートコードをsyslinux.exeを-maオプションで実行して上書きすればブータブルにできた。

2009/05/11

Windows 7 RC

Windows 7 Betaに続き、Windows 7 RCをThinkPad X61sにインストールしてみた。

1. インストール

今回は多少古くてもVistaのドライバを容赦なく入れる方針で進めたところ、基本的な機能に問題なし。ただ、日本語版と平行して英語版もインストールしたが、LenovoのUSサイトのドライバを使ったところ、日本サイトより古いものがあってオンスクリーン表示が出ない状態になった。これは日本サイトのホットキー機能のドライバ(5.21.01)を入れて解決。

見た目はBetaと特に変わらない。X25-Mの状態のエクスペリエンスインデックスは5.9に戻った。

[追記1]

EasyEject Utilityのインストーラを起動すると、「このプログラムには既知の互換性の問題があります」とのメッセージが出る。ここで「オンラインで解決策の有無を確認する」を選んでも解決策は見つからない。一方、そのまま「プログラムを実行する」でインストールはできた。特にOSが不安定になるようなことは起きてないが、EasyEjectの動作自体については問題がある。
  • Ultrabase X6との切り離し、Ultrabase X6内のストレージの切り離しは正常。
  • USBメモリ、USB外付けHDDは対象のデバイスとして出てこないので、切り離せない(Windows 7 RCでは正常に認識されており、標準の機能での切り離しは問題ない)。
[追記2]

27日にLenovoからWindows 7 Betaのドライバが出たので(Availability of Windows 7 Beta Device Drivers for some Lenovo Thinkpads)、入れてみた。
  • ホットキー機能=オンスクリーン表示(5.30)+全画面拡大機能(2.05)
  • システム制御ドライバー(1.01)(既に出ていたVista用と同じもの)
  • 省電力ドライバー(1.53)
  • 省電力マネージャー(3.00)(英語表示のみ)
  • Access Connections(5.40)(日本語にも対応)
このうちPower ManagerとAccess ConnectionsはWindows 7の新しいタスクバーに合わせたものになっていた。

ただし、小さいアイコンに対応していないようで、タスクバーを細くできないという問題あり。

2. SSDとの関係

Windows 7とSSDとの関係について、MicrosoftのEngineering Windows 7にエントリ(Support and Q&A for Solid-State Drives)が出ている。

[参考]
マイコミジャーナル: 欠点を克服、SSD本来のパフォーマンスを引き出す「Windows 7」
(このエントリを元にした記事。あまり表現が正確でない部分がある)

特に興味深いのは、(ランダムリードが十分速くてランダムライトの問題がない)SSDの場合はSuperfetchが自動的に無効にされるということ。
If the system disk is an SSD, and the SSD performs adequately on random reads and doesn't have glaring performance issues with random writes or flushes, then Superfetch, boot prefetching, application launch prefetching, ReadyBoost and ReadDrive will all be disabled.

SSDと直の方がSuperfetchをかませるより速いからこっちで切っといたよ、とカラッと言われると、やはりそうかと思いつつ、それはHDD+Superfetchは所詮劣るものという宣告でもあるわけで、それも分かってはいたが、ReadyBoost対応のUSBメモリやTurboMemory搭載のPCなどには少し切ないものがある(個人的なダメージはないが)。

また、SSDの場合はデフラグのスケジュールから除外されるが、それはSSDが自己申告してきたときに加え、(現在市場にあるSSDで正しく自己申告するものは稀なので)ランダムリードのテストで8MB/s(サイズは4KBと推測)の下限をクリアしたときも対象となる。ただし、このランダムリードのテストは製品版で追加される(「the final product」は製品版を指すと思う。「was added to」が過去形なので変な気はするが)。
The automatic scheduling of defragmentation will exclude partitions on devices that declare themselves as SSDs. Additionally, if the system disk has random read performance characteristics above the threshold of 8 MB/sec, then it too will be excluded.
The random read threshold test was added to the final product to address the fact that few SSDs on the market today properly identify themselves as SSDs.

X25-Mがどうかといえば、インストール後の初期状態では以下のようにSSDと認識されていなかった。
  • デフラグのスケジュールが有効になっている。
  • Superfetchが自動起動になっている。
上記の説明に従えば、X25-MもSSDと正しく自己申告しない部類なのだろう。CrystalDiskInfo(2.7.1)を見るとATA8-ACS2にも対応してないので。早速デフラグのスケジュールを無効にし、Superfetchも無効にした。ついでに、XPでもprefetchは無効にしておこうと思う。

3. Windows XP Mode

個人的にこれがないと困るというものではないが、XP Mode。USBデバイスの扱いやドライブの共有などVirtual PC 2007のときより洗練されている印象。


ただ、このX61sではウインドウ表示では結構もたつく。仮想マシンに1GBのメモリを割り当ててみたが(x86版なので3GBの中から)、あまり変わらない。全画面表示にすると、ようやく普通に動く感じ。全くストレスなく動かすにはスペックが要求されると思う。

全画面では画面解像度は1024×766となり、本来より縦が2ピクセル狭くなっている。

[追記]

VirtualChecker 1.0で表示させたところ、X61s(CPUはCore2Duo L7700)は当然ながらIntel VTが有効と出る。

4. セキュリティの警告

セキュリティの警告の微妙な誤訳については、Betaのときと変わっていない。

今後修正されるものか、製品版でもこのままなのかは不明。