デスクトップPCのSSDを交換した。 (いろいろ追加ありｗ)

壊れた訳ではないのだが、数日前に見た、ある種(Cisco, HPE, SanDisk)のSSDが約4万時間(約4.6年)で使用不能になるというニュースが発端だった。 (→ 元の情報)

それで、僕のPCのSSD(AData SX900)の電源on時間を調べたら、約32000時間(約3.6年)で、4万時間までの残りは約1年であった。※ この問題が起こるとSSDに全くアクセスできなくなる(「文鎮化」)ということなので、心配になって調べてみると、対象はSanDisk製のSAS SSDのみのようだ。 (→ 参照)

※実際に使っていた時間(期間)は約6年なので、実際の残り期間は1.7年程度と思われる。

更に、HPEの資料によれば、対象のSSDは問題が起こり出す2020/10の約4年(4万時間)前(→ 2016/3/9頃)に出荷されたもののようだ。 (以下、左の資料から引用)

Due to the SSD failure not occurring until attaining 40,000 power-on hours of operation and based on the dates these drives began shipping from HPE, these drives are NOT susceptible to failure until October 2020

僕が使っているAData SX900は2013年頃の製品で、上の情報によれば問題のSSDより前に製造・出荷されただろうから、対象外の可能性が高いし、そもそも、対象はSanDiskのSAS SSD(ただし、確証となる情報は見付からなかった)と随分違うので、おそらく問題ない。だから、僕のSSD・PCで上記の問題が起こる可能性はほとんど0だが、使用時間が長くなったので、安心のために(+気が向いたｗ)、手持ちの予備的なもの(東芝 THNSNH256GCST)に交換することにした。

そもそも、Linuxに移行した時に、暫定的に「そこら辺にあった」SSD(AData)にインストールして、良かったら今回交換したもの(東芝)に換えるつもりだったのだが、問題なく動いていたし、面倒なので(どう面倒かは以降を参照)、そのままにしていた。

なお、新しいSSD(東芝)の電源on時間は約9400時間(約1年)だったので、充分な余命がありそうだ。

下調べと試行錯誤

交換するSSDはシステム(起動)ドライブ※なので、やっぱりいくつかの落とし穴があった。

※ここでは「ドライブ」は「ディスク」とほぼ同義である。SSDを「ディスク」というのが少し変な感じなので、基本的に「ドライブ」とした。

システムドライブの移行方法を調べると、大きく分けて2種類があった。: 複製(クローン)かコピーかである。

複製(クローン)は、ddコマンドなどでドライブを丸ごとコピーし、コピーはドライブ中のファイル単位でコピーする。移行するのは起動ドライブなので、ブート情報・領域もそのままコピーできる前者のほうが安全な気がした。が、ドライブのUUIDまでコピーされてしまう(→ 論理的に同じものが2つできる)気がして(未確認)、後々トラブルの原因になると考えたので、後者のファイル単位でのコピーにした。

調べていたら、Clonezillaという良さそうな複製ツールが見付かり、最初はそれを使おうとしていた。が、なんか書いてあることがおかしいので止めた。

というのは、「ブートローダー(grub)なども再インストールする」とあるが、そもそも複製なのだからそんな必要はないのだ(必要なのはファイル単位でコピーする場合)。UUIDについては書いてないので、そのままコピーされるのではないか。

仮に、UUIDはコピーせず、それでgrubを再インストールするというなら、/etc/fstabも更新する必要があるが、それはしない(さまざまなOSには対応できないし、複製ツールがファイルまで変更するのはおかしい)から複製しただけでは起動できない。

それだったら、処理内容が分かっていて手慣れたddを使うほうが良いと考えて却下した。

大体ね、Clnonezillaはサーバなどの非対話環境でも使うことを想定しているようだが、クローンでは駄目だと思う。マシンの実行中にクローンしたら、微妙に変なものができないか?? そういう用途では論理的なコピー(ファイル単位かつロックなどする)でないと駄目だと思う。

ファイル単位でのコピーの場合で一番気になって居たのは、(どんなOSでもいつも面倒な※、)ブートローダー(grub)などを設定・更新しないと起動しないであろうことだ。調べたら、grub-installでgrubを再インストールし、fstabを更新(システムドライブのUUIDを変更)すればいいという情報があって(→ 参照)、それなら簡単そうだと思ってやったら嘘だった。。。必要な作業内容に漏れがあって、そのままでは起動できなかった。

※だけど、LinuxはWindowsより3倍くらい楽で良かった＾＾

試行錯誤したら、どうやら、grub-installではgrubの設定(/boot/grub/grub.cfg)が作成されないためのようだ。それを作るコマンド(grub-mkconfig)はあるのだが、ライブメディアで起動したLinuxでコピーを実行しているため※、作成される設定は元々の設定とは関係ないものになりそうなので嫌だった。＊

※コピー中に元のドライブの内容が変更されるのを防ぐため。

＊今考えると、単に起動するだけであれば、ライブメディアで設定しても良さそうだ。が、現在の設定内容は自分で変更した箇所があるので、それが引き継がれないのは良くない。

仕方ないので、fstabと同様に、中のUUIDを新しいドライブのものに書き換えたものを使うことにした。

grub.cfgには「手で変更するな」という警告が書いてあるが、今回は仕方ない(ちゃんとやるのは面倒だ)し、実質的には複製した場合と同じことなので良しとした。

なお、最初は(トチ狂って?)grub-installは不要かと思い込んで試したが、見事に起動しなかった。ドライブのブートローダーはファイルとしては見えないので、コピーできないのだろう。ただ、なぜかgrubの画面が出たが、元々ラップトップ用Linuxのシステムドライブにしていたので、それが残っていたためだろう。

交換作業

最終的に、作業手順・内容は以下だった。

準備
1. 新しいドライブ(東芝 SSD)の不良ブロックのチェック (badblocksコマンド)
  - 基本的に、寿命が残っているSSDでは不良ブロックは生じないが、数年間使っていなかったので回路・素子に問題が生じていないかや連続使用で問題が起こらないかの確認が目的である。
2. 新しいドライブの内容(ラップトップ用Linux)をバックアップ (tarコマンド)
  - ラップトップ用Linuxのドライブがなくなると不便なので、別のものに移すことにした。
3. 新しいドライブの内容を別の古いドライブ(Intel SSD)にリストア
  - 使ったUSB-SATAアダプタの電源アダプタのコネクタ(4ピン※)が今一つで、GNDが1本しか出ていないため、古いドライブではそのままでは電源がonにならなかったので、間にアダプタを入れた。
    - ※SATAの電源コネクタを壊してしまったため、4ピンを使った。
4. 古いドライブにgrubを再インストール (grub-installコマンド)
5. 古いドライブのgrub.cfgの修正 (起動ドライブのUUIDの変更)
6. 古いドライブのfstabを更新 (ルートパーティションのUUIDの変更)
7. 古いドライブでラップトップが起動するかの確認
移行
1. 新しいドライブ(東芝 SSD)のフォーマット・パーティション作成 (gpartedコマンド)
2. ライブメディアでLinux Mintを起動
  - コピー中にコピー対象のドライブの内容が変わらないようにするため、ライブメディアで作業した。
3. 現在のドライブ(AData SSD)の内容を新しいドライブにコピー (rsyncコマンド)
  - データ量が少ないため、15分くらいで終わった。
4. コピー内容のチェック (diffコマンド)
  - 基本的に、コピー時にエラー(中身の変化など)は起こらないが(起こるようならOSがまともに動かない)、念のためにチェックした。
5. 新しいドライブにgrubを再インストール (grub-installコマンド)
  - 最初は、ブートディレクトリの指定を誤ったために起動しなかった。ドライブのトップでなく"/boot"まで指定する必要があった。
6. 新しいドライブのgrub.cfgを更新する。 (起動ドライブのUUIDの変更)
7. 新しいドライブのfstabを更新する。 (ルートパーティションのUUIDの変更)
8. 新しいドライブをPCに取り付け・接続する。
9. 新しいドライブで起動するかの確認
後処理
1. 新しいドライブのSMART情報(属性)が、smartctlコマンドでちゃんと表示されるようにした。
  - 東芝SSDのベンダ固有情報を/etc/smart_drivedb.hに追加した。
  - 他の東芝のSSDになかった属性(7, 8, 10)については、CrystalDiskInfoの画面キャプチャを参考にした。
    - ただ、Seek_Error_RateなどSSDには関係ない属性なので、実は違うのかも知れない。
    - その点では、元々あったSpin-Up_Timeなども同様である。
2. Muninで新しいドライブの情報がちゃんと表示されるようにした。
  - ドライブの指定方法を修正し、新しいドライブの温度が表示されるようにした。
  - コピー(USB-SATAアダプタで接続していた)中に転送エラーが起こったようで、(smartctlコマンドがエラー64を返すために)SMARTのグラフが警告状態になったままで気分が悪いので、smartctlコマンドの代替(ラッパ)を作り、SMARTのエラー数が増えない限り「エラーなし」にするようにし、警告状態にならないようにした。

: 新しいドライブ(東芝SSD)の不良ブロックのチェック中

: ライブメディアで起動して、ファイルコピー中

: 起動ドライブを新しいドライブに換えたが起動失敗。。。

: 新しいドライブをPC内部に設置するため、マウンタに取り付けた(左側)。なぜか、東芝のドライブは裏表が逆に付く。

: 新しいドライブをPC内部に設置した(一番下のベイ)。

: 新しいドライブのSMART情報がちゃんと表示できるようにした。

: 新しいドライブのエラー数が0でないので、Muninのグラフが警告状態(オレンジの枠)になってしまった。

: 新しいドライブのエラー数が増えない限りMuninで警告しないようにした。

: 新しいドライブは、アイドル時の温度が以前のより2℃くらい低い。: 旧: オレンジ(中)、新: 緑(下)

効果・感想など

新しいドライブは容量が以前の2倍くらい(128GB → 256GB)のため、交換後の空き領域がかなり増えた(約53GB → 約140GB)。なお、どちらのドライブも似たような性能らしく※、特段速くなったようには感じない。

※仕様上は新しいほうが速そうだが、未確認。

ただ、空き領域が増え、余命が伸びたので、以前はHDDに格納していたキャッシュなどをSSDに移動し、多少は高速化できたかも知れない。

が、体感上は分からずｗ

新しいドライブは、アイドル時の温度が以前のより2℃くらい低い(室温で約33℃ → 約31℃)のは、「ちょっといい感じ」なことである。

が、この辺りの温度での小さな差は、実質的な効果はない。

なお、元のドライブはPCに付けておき、非常時の起動用にしようと思っている。常時ミラーリングなどできるといいが、容量が小さいので簡単ではないし、古いドライブの寿命が縮まるので良くない。

更に、元のドライブの電源を繋げておくべきかどうかについても悩ましい。: 電源を繋げておけば、中のデータがリフレッシュされて(期待)、いざという時に駄目になっている確率が減るが、電源on時間とともに寿命が縮むのであれば、繋げておかないほうが良いし、誤操作を防ぐという点でもそのほうが良い。

→ 「非常時」がそうそうあるとは思えないし、逆に、(データが消えるかも知れない)十年以上放置するということもなさそうので、繋げないことにした。 (7/16 4:59)

例によって、「いつも苦労してんな」だが、まあ、(僕の周りの)世の中なんてそんなものだ。

その後 (7/18 12:08)

使っていたら、いくつかおもしろい・良さげなことに気付いたので、列挙する。

なぜか、システムの負荷(uptimeコマンドのload average)が下がった。
- 時々wコマンドやtopコマンドでシステムの負荷を見ると、以前はアイドル時でもload averageが1を超えていて、今一気分が悪かったのだが、交換後は1未満(例: 0.4)になっていることがある。
- 理由は不明だし、使っていて体感的には特に変化はないのだが、気分は良くなった＾＾
  - システムドライブの交換後にキャッシュなどをHDDからSSDに移したため、システムドライブの遅延時間が減り(下記)、プロセスの待ち時間が減ったためではないかと想像している。
    - "load average"は、簡単に言うと「何かを待っているプロセス数」なので、各プロセスが何も待たずに実行されているほど少なくなる。
システムドライブ(交換したSSD)の遅延時間が減った。
- Munin(システムの状況監視ソフト)を見ていたら気付いた(やっぱり、体感的には特に変化はない)。
- 以前(ADataのSSD)は平均1ms程度だったのが、東芝のSSDに換えてから平均0.7ms程度になった。 (→ グラフ: 右から1/3以降は交換後)
  - SSDの速度の違いによるものだろうか。
HDDの温度を4℃くらい下げられた。
- これもMunin(システムの状況監視ソフト)を見ていたら気付いた。
- 昨日だったか、なぜかHDDの温度が上がって40℃くらいになったので、下げられならないか考えていたら思い付いた。
  - ドライブベイの前のファンは12cm(元々は8cmx2だったのを改造した)と大きく風量はあるが、中央部は軸のために羽根がなくて風が少なそうだ。
  - 一方、HDDはその辺りに設置しているので、風が少なくて冷却効果が弱いのではないか? (→ 写真: HDDは中段の黒)
  - そこで、試しにHDDとSSD(ファンの下半分の後ろにある)の位置を交換してみたら、意外にうまく行って、4℃くらいも下がった(例: 40℃ → 36℃)。 (→ グラフ: 中央辺りで位置を換えた)
    - ファン中心部の風が少ないのなら、ファンの直近に冷やす対象を置くのは得策でない(場合がある)ようだ。少し離して、風を均一にするようなものがあるといいのか。
  - ただ、なぜかSSDの温度が1℃前後上がってしまった。
    - それで、SSDも風の強い部分(ファンの上半分の後ろ)に設置したり(→ 写真: HDDを下段に、SSDを上段に)、通風や放熱を改良したが、今一つ効果がなかった。
    - HDDの温度が低くなったために、ファンの回転数(ドライブの温度で制御している)が100rpmくらい下がって風が少し弱くなって、SSDの温度が上がったのではないかと推測している。
    - 書いたあとで写真を見ていて気付いたが、SSDの前のファンの前はケースの開口の境目で穴がなく、吸気が悪そうだ。これも関係あるのだろうか??
      - (7/19 5:24) 試しにベイに縦に設置してみたが、SSDの温度は下がらなかったので、関係なさそうだ。
        
        ファンは回転しているので、吸気側の部分的な障害物の吸気効率への影響は全体に及ぶのではないか。
    - (7/20 13:21) 随分いろいろ試したら、SSDの温度を1-2℃くらい下げられた(かも知れない)。
      - 空調(冷房)にも影響されるのでまだ安心できないが、ここ数時間はOKだ。 (→ グラフ: 緑の右側約1/3以降はSSDの平坦な面を下にして取り付けている。なお、左から2/3は凹みの広いラベル面を下にしていた。)
      - 効いたと思われることは、SSDのケースの平坦な面(ラベルのない側)をトレイに直接固定したことである。
        
        なぜか、その面にはネジ穴がなく、(その反対側の)ラベルのある面を下にして設置する想定のようだが、その面はほとんどが凹んでいて(上の写真を参照)密着性が悪く、熱伝導も悪いのではないかと考えた。
        
        こうする前は、想定どおりにラベル面を下にして居たが、少し放熱が悪かった印象だ。
        
        ただ、ラベルのない面の内部は基板の裏面で、ケースがチップと接していないため(実際にラベル面で接しているかは不明)、放熱性はラベル面より劣りそうだ。が、トレイとの接触面積が広いほうがケースが冷えるので得策だと考えた。
        
        また、マウンタを介すと、上と同様に凹みがある面でマウンタに接するうえに、マウンタはトレイにネジでしか接しないために熱伝導性が劣化する気がしたので、マウンタは使わないことにした。
        
        それから、当然ながら、ファンからの風がちゃんと(冷たい・直接・抵抗なく・分散せずに)ドライブに当たるのは重要なので、ベイへの設置方法もいろいろ試した。
        
        結局、当初のように、風量の少なそうなファンの中央部を避けて羽根の上半分の中央辺りの直後にSSDが来るようにした。
        
        また、効果はなかったようだが、SSDとHDDの間に予備のトレイを入れてセパレーターにして、ファンからの風が分散せずにそれぞれのドライブに達するようにした。
      - いずれにしても、良く言われている、M.2やNVMeの冷却とは温度が全然違う。が、上のような考え方で冷却性を高められると思う。
    - (7/21 14:59) 上で、SSDの温度が2℃も下がることがあるのはどうもおかしいと思って居たら、思わぬ失敗が発覚したが、それで冷却性を高める方法が分かった。
      - 最後にSSDをベイに装着したあと、PCケースの前面パネルの閉め方が不充分だったために隙間ができていて、ファンの吸気量が増えたためのようだ。
        
        パネル下側のヒンジのピンが抜けていたために、下部が少し開いていた。
      - それに気付いて前面パネルをちゃんと閉めたら、SSDの温度は1℃上がり、温度低下は1℃になってしまった。
      - ただ、怪我の功名で、比較的容易に吸気量を増やして冷却効率を向上させられることが分かった。
        
        前面パネルの側面の開口(吸気口)を広げればいい。
        
        吸気口はスリットになっているので、その柱が吸気抵抗になっているのだろうから、それを減らして開口を広げることにした。
        
        実物の構造を見て、右側はスリット部を下から約13cmを切断し、左側はスリットの柱を1/3に間引いた。
        
        ありがたいことに、スリットは前面パネル本体とは別の部品になっていた。
        
        右側は特に強度に寄与していないので、切断しても問題なさそうだったが、左側にはパネルを閉める爪が付いているため、切断は難しかった。
      - 作業後、無事に昨日のようにSSDの温度が1-2℃下がった。 (→ グラフ: 緑の右端から1/4以降。その前はケースの前面パネルをちゃんと閉めていた。)
- SSDの温度がわずかに高くなったのは少し気分が悪いが、そもそも実用上は全く問題ない領域なので良しとした。
  - ↑その後、上記のようにSSDの温度が高くなったのが解決できた(見込み)。 (7/20 13:21)

: システムドライブの遅延時間: 右から1/3くらい(東芝に交換した時)を境に、高さ(ドライブの処理時間)が低くなっている。

: ファンの回転数(上), ドライブ温度(中), CPUなどの温度(下): ドライブ温度: 取付位置の移動前(左半分)はHDD(青)が40℃くらいまで上がっているが、移動後(右半分)は36℃くらいに下がった。ただし、SSD(緑)は少し上がった。一方、ファンの回転数は移動を境に100rpmくらい下がっている。