ディスクの状態を確認するためにsmartctlを利用しました
1.概要
ディスクの状態を確認するためにsmartctlを利用しました。その内容を記述します2.詳細
(1)調査を始めたり理由
500GBのディスクがクラッシュのメッセージを出力して、grubによるブートができなくなりました。しかし、不思議なことにfsckを実行するとエラーなし、各パーティション内のファイルも参照できます。パーティションテーブルを再構築して、再度試しても状況は同じになります。この内容に関して記述します。
障害を解析した訳ではないので、詳細に関しては不明瞭な点が多数あります。grubを利用したbootだけがだめになってしまたディスクのようです。別の代替ディスクに交換して、環境を再構築すると問題はなくなりました。つまり、ディスクはクラッシュしていたと言うことですが、gparted, fsck, fdisk, mkfsでエラーにならない故障でした。
fdiskでディスクを調べていて、2048セクター以前の領域はユーザ側で利用できないことに気が付きました。0〜2047セクターなので、2048 * 512 = 1MBの領域です。ここには、パーティションテーブル以外にもbootに必要な情報が保管されています。私はmsdosパーティションテーブルを利用しているので、MBRが存在します。今回の故障はMBRは無事ですが、2047セクター内のmsdosパーティションテーブル以降の場所でクラッシュが起きたようです。ユーザーが普通利用する領域は無事なのでデータディスクとしては使えるようです。
(2)smartctlの調査
S.M.A.R.T.(Self-Monitoring Analysis and Reporting Technology)を表示するコマンドのsmartctlを利用しました。参考資料に従って、インストールします。
sudo apt install smartmontools
利用方法は簡単です。
sudo sumartctl -a /dev/sdd
問題なく利用できます。
注目すべき点は、最後に出力されるSMART Errorの件数と内容です。
エラーが発生していたならば、ディスク交換の時期です。
エラーがない場合は、エラー部分は表示されなので、ディスクトラブル発生時に表示内容を一度確認しておくことは良いことだと思います。
3.所見
ディスク先頭部分の利用方法はGPTがサポートされて変わりました。利用されていなかった領域にいろいろな情報が書かれているようです。こんな故障の仕方もあるのだと感じました。
参考
[本ブログ内参照]・memtest86のメモリテストがtest#2でフリーズ
・grubによるブートができなくなったdisk 2048 sector内のhardware障害
・ラウンドロビンを採用するNTPサーバのYAMAHAルータへのフィルタリング設定
[外部サイト参照]
・Smartmontools
コメント
コメントを投稿