壊れた訳ではないのだが、数日前に見た、ある種(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だが、使用時間が長くなったので、安心のために(+気が向いたw)、手持ちの予備的なもの(東芝 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. 準備
    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. 古いドライブでラップトップが起動するかの確認
  2. 移行
    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. 新しいドライブで起動するかの確認
  3. 後処理
    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のエラー数が増えない限り「エラーなし」にするようにし、警告状態にならないようにした。

効果・感想など

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

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

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

が、体感上は分からずw

新しいドライブは、アイドル時の温度が以前のより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)

 

(7/16 4:59, 8:47 修正・加筆; 7/18 12:08 「その後」を追加; 7/19 5:24 「その後」に追記; 7/20 13:21 「その後」に更に追記; 7/21 9:24 若干修正; 15:18 「その後」にPCケースの改良について追記)

  •  1
  •  0

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL