2014年12月21日日曜日

ThinkPad W520 の HDD を SSD へ引越し

4年間ほどメインマシンとして ThinkPad T510 (Core i7 M620) を使っており、まだまだ使えそうなのですが、ついついと中古で ThinkPad W520 (Core i7 2960XM) を入手してしまいました。いくつかのベンチマークで、T510 よりも 1.5 倍程度の性能でした。W520 は、メモリスロットが4スロットあり、最大で32Gまで対応できますが、そこまでは不要と判断して、16G(4Gx4枚)としました。そして、W520 は SATA 3.0 対応であり、わたしの自宅マシンとしては初モノです。
というわけで、仕上げに、HDD を SSD に引っ越しましたので、その手順をメモしておきたいと思います。

内蔵されていた HDD は、HITACHI HTS725050A9A364 の容量 500G 7200RPM でした。
どのベンダーの SSD に換装しようかと思ったのですが、今回は自分の中でイメージが良い SanDisk のものを使ってみることにしました。今も使っている Sony CLIE で、SanDisk 製の MemoryStick を長年使っており、高速だし実績もあるというイメージを持っています。
そんなわけで、Extreme PRO 240G をチョイスしました。

引越し作業は、USB HDD 上にインストールした CentOS 7 から起動して行いました。ちなみに W520 は、USB 3.0 対応でもあるのですが、残念ながら USB 3.0 では CentOS 7 を起動できず、USB 2.0 ポートから起動して作業しました。
プリインストールされていた Win7 のパーティションは、次のようになっていました。
# fdisk -u -l /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x153c11d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sda2         3074048   944003071   470464512    7  HPFS/NTFS/exFAT
/dev/sda3       944003072   976771071    16384000    7  HPFS/NTFS/exFAT
sda1 が Win7 のシステムパーティション、sda2 が Win7 の本体、sda3 がリカバリ領域 (所謂 D2D 領域) です。

まず最初に、sda2 を gparted で縮小しました。ここで、NTFS パーティションを操作するためには、ntfs-3g と ntfsprogs を入れておく必要があります。どちらも EPEL に収録されています。
縮小後のサイズは、次の通りです。
# fdisk -u -l /dev/sda
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sda2         3074048   134146047    65536000    7  HPFS/NTFS/exFAT
/dev/sda3       944003072   976771071    16384000    7  HPFS/NTFS/exFAT
次に、ディスクの先頭から sda2 の末尾 (sector 134146047) までを、dd コマンドで SSD にコピーしました。SSD は、2nd HDD アダプターに接続。
# echo "134146047 * 512 / 65536" | bc
1048015
# dd if=/dev/sda of=/dev/sdb bs=65536 count=1050000 conv=sparse
必ずそうであるとは断言できませんが、新品の SSD は、全領域がゼロデータのはずなので、conv=sparse でゼロデータをスキップしてコピーしました。ここで、パーティションテーブルも一緒にコピーされたので、不正になった sdb3 を fdisk で削除して、正確に同じサイズの sdb3 を作成しました。
# fdisk -u -l /dev/sdb

Disk /dev/sdb: 240.1 GB, 240057409536 bytes, 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x153c11d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sdb2         3074048   134146047    65536000    7  HPFS/NTFS/exFAT
/dev/sdb3       134146048   166914047    16384000    7  HPFS/NTFS/exFAT
不要かもしれないとは思いつつ、パーティション 3 の D2D 領域もコピーしました。
# blkdiscard /dev/sdb3  ※1回目の dd で少し余分にコピーしたので、TRIM でクリア
# dd if=/dev/sda3 of=/dev/sdb3 bs=65536 conv=sparse
うまくコピーできたかどうか、md5sum 値を確認。
# dd if=/dev/sda1 bs=65536 | md5sum
# dd if=/dev/sdb1 bs=65536 | md5sum

# dd if=/dev/sda2 bs=65536 | md5sum
# dd if=/dev/sdb2 bs=65536 | md5sum

# dd if=/dev/sda3 bs=65536 | md5sum
# dd if=/dev/sdb3 bs=65536 | md5sum
これで、完全にコピーが終わったので、HDD を取り出して SSD に換装して起動、、、うまくいきました!
D2D リカバリーが出来るかどうかまでは確認していませんが、マシン起動時に ThinkVantage ボタンで D2D リカバリーのメニューには辿り着けました。

余談になりますが、CentOS 7 向けの ntfs-3g は、fstrim に対応しているようです。
# rpm -q --changelog ntfs-3g | less
...
* Thu Jul 31 2014 Richard W.M. Jones <rjones@redhat.com> - 2:2014.2.15-4
- Upstream patches which add fstrim support.
いちおう、最後のしめに、コピーした Win7 のパーティションに fstrim をかけました。
本当に fstrim が機能しているか、念のため小さいパーティションで試しましたが、ちゃんと動いているようでした。削除したファイル(ある程度大きいサイズのファイル)の痕跡が消えることを確認しました。

2015-09-08追記
その後、SSD の後半に CentOS を入れて、MBM でマルチブート運用しているのですが、その状態だと ThinkVantage ボタンで D2D リカバリーのメニューを呼び出すことが出来なくなるようです。しかし、MBM で Win7 のシステムパーティションを選択後に F2 連打、そのあと F8 押下で、「システムの回復」を選択すれば D2D リカバリに辿り着けました。ただし、本当にリカバリできて、しかも後半の CentOS パーティションに影響ないのか不明。試行してません。

ZFS の upgrade について

ZFS on Linux を利用し始めた初期 (2012年前半) に作成した zpool のバージョンが、古いままだった(version 23)ので、lz4 圧縮を使うために zpool upgrade を行いました。そうしたところ、なぜか tar ファイル展開で、展開したファイルのパーミッションがおかしくなる(mode 000 になる)現象に遭遇しました。
最初から新しいバージョン (version 5000) で作成した zpool では、正常に tar 展開されるし、何が原因だろうか?と違いを調べたところ、あまり意識していませんでしたが、zpool のバージョンとは別に zfs のバージョンもあり、これが古いまま (version 4) であることがわかりました。
# zfs get version
NAME              PROPERTY  VALUE    SOURCE
tankX             version   4        -
きっとこれだろうと思い、zfs upgrade tankX を実行して、バージョンを 5 に上げました。そうしたところ、正常なファイルパーミッションで tar 展開できるようになりました。以上、備忘録ですが、どなたかの参考になることがあれば幸いです。
なお、ZFS on Linux を使い始めて約2年半、今回のようなデータ保全に関わるトラブルは初めてです。わたしの利用の範囲ではということですけども。
人気ブログランキングへ にほんブログ村 IT技術ブログへ