あさりのみそしるダイアリー

非常事態が日常です…そんな時こそ声を上げないと人生ジエンドにゃん(´・ω・`)

RECBOXとたたかう その4

そして、その4です。とりあえず今日はこれで最後ですかね(ここから先にはまだ進めないので)

お約束ですが・・・
すべて自己責任でお願いします。何かあっても当方は何も責任を取りません!
あと、私は3TBのHDDが手元にないとか、そういう理由でバックアップを取らずにオリジナルHDDをそのまま使っていますが、バックアップなりコピーなりをとってやった方が絶対にいいです!




例によって、RECBOX内のHDDをデスクトップパソコンに取り付けてKNOPPIXを起動します。

イメージ 1

で、「ディスク・ユーティリティ」を開いて

イメージ 2

「SMARTデータ」というのをクリックしてみます。
SMARTというのはHDDの健康状態のことで、HDDは自身の健康状態を記録しています。


イメージ 3

で、先のボタンをクリックして下の方にスクロールしていくと・・・

なんと赤くなっている項目が!
いかにもあやしそうですね。

上の方にも表示されている通り、このHDDには16個のバッドセクタが存在します。
それがこれで、Current Pending Sector Count の値は16セクタとなっています。
詳しいことは私もよくわからないのですが、要するにHDD上に危ない領域があるということでしょう。
この領域に対して書き込みをしようとした際に、書き込みに失敗した場合は、代替セクタに書き込まれます。これまでに何回、代替セクタに書き込むことになったのかという回数を示しているのが Reallocation Count です。
で、読み込み時には代替セクタとか関係なく、特に何の操作も行われません。このバッドセクタ(不良セクタ)に対してデータを読みに行っても、読めないことが十分ありえます。そして、読めない領域の内容を別の正常な領域(代替セクタ)に書き込んで、バッドセクタを回避しようということはできません。自分で何かやればいいんでしょうけど。


とりあえず、RECBOXのHDD上には不良セクタが存在するので、その領域にアクセスしようとしているのであれば・・・


イメージ 4

sudo smartctl --log=selftest /dev/sdc

特定のパーティションではなく、RECBOXのHDDそのものに対して行いたいので上のようなコマンドをコンソール上で実行します。

たぶん、これによって何かでてくるはずです。
実際、出てきたんですけどね。

これをみるに、一番最初の読み込みエラーな領域が1524376番目の領域にあるっぽいですけど。活動時間が5328時間ということで、常に動いていたからそのくらいかな~とも思います。購入からもうすぐ1年たつので妥当でしょう。
Remainingは、先頭から10%の領域を見ただけですよ(後ろにまだ90%の領域が残っていますよ)ということでしょうかね。


で、思いました。

1524376番目の領域ってどこだよ!!


イメージ 5

ここで、GPartedを起動して(ちなみに、ここで書くことではありませんが、GParted起動後、RECBOXのHDDをリストから選択する必要があります)、パーティションを選択し右クリックします。
メニューの最下部に「情報」という項目があるのでそれをクリックすると、こんな画面が。

これを見ると、開始セクタが1000008で、終了セクタが3000007、総セクタ数が2000000であることがわかります。
つまり、今見ているパーティション「/dev/sdc2」は、HDDの先頭から1000008番目の領域からはじまることがわかります。

ここで、バッドセクタがどこにあったのかを思い出してみましょう。
1524376番目でしたよね。

sdc2パーティションは1000008~3000007番目の領域ですから、1524376番目の領域はsdc2パーティションに含まれることがわかります。


イメージ 6

イメージ 7


まぁ、本当かどうかはちょっとあれなので、コンソールからもみてみましょう。

sudo badblocks -vs -o sdc.bad /dev/sdc

このコマンドを実行することで、/dev/sdc上のバッドセクタ(バッドブロック)がどこにあるのかを知ることができます。

ただ・・・実行した後に思いました。3TBの領域に対してこんなの実行したらどれだけの時間がかかるかわからない!

ということで、キャンセルして

sudo badblocks -vs -o sdc2.bad /dev/sdc2

を実行しました。先ほど確認した/dev/sdc2について、本当にそこに不良セクタがあるかどうかをチェックしてみます。

---------------------------------
Checking blocks 0 to 999999
Checking for bad blocks (read-only test): done                               
Pass completed, 17 bad blocks found.
---------------------------------

これならほとんど時間はかからずに終わります。
で、出てきました。/dev/sdc2には17個のバッドセクタがみつかりました。
SMART値よりも1だけ多いけど気にしないことにしましょう。(この領域に不良セクタがあることには変わりありません)


ためしに、/dev/sdc1 , /dev/sdc3 , /dev/sdc5 についても同様に不良セクタ数を確認してみたところ・・・

---------------------------------
knoppix@Microknoppix:~$ sudo badblocks -vs -o sdc1.bad /dev/sdc1
Checking blocks 0 to 499981
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.
knoppix@Microknoppix:~$ sudo badblocks -vs -o sdc3.bad /dev/sdc3
Checking blocks 0 to 1999999
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.
knoppix@Microknoppix:~$ sudo badblocks -vs -o sdc5.bad /dev/sdc5
Checking blocks 0 to 499999
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.
---------------------------------

と、バッドセクタ数は0であることが確認できました。
要するに、他の領域にはバッドセクタはない・・・と。

ちなみに、/dev/sdc4は、その中に/dev/sdc5と/dev/sdc6を内包しているので気にしないことにしました。
それと、/dev/sdc6は前にも書いた通り録画番組などのデータが保存された領域なのでサイズがバカでかく、実行するのにはかなりの時間がかかるので無視しました。たぶん・・・大丈夫でしょう。


で、バッドセクタがどこにあるのかという情報は sdc2.bad に書き出したため、この情報をもとにしてバッドセクタをなんとかすることもできます。

sudo fsck -l sdc2.bad /dev/sdc2

----------------------------------
fsck from util-linux-ng 2.17.2
fsck: fsck.linux_raid_member: not found
fsck: Error 2 while executing fsck.linux_raid_member for /dev/sdc2
----------------------------------

ただ、この/dev/sdc2の領域はファイルシステムが不明であるため(少なくともKNOPPIXでは認識できない領域なので)、ブロックサイズがいくつだの、どういう形で値を格納すればいいのかだのがわかりません。

なので、fsckを実行しても、上記の通りメンバーが見つからずエラーが返ってきてしまいました。



つみましたね~。


ただ、今回の検証から分かったことは、少なくともHDD上には物理的なエラーが生じているということです。
これを解決する方法はただ1つ!


新しい3TBのHDDを購入して、元のHDDの中身をそのままコピーしましょう・・・と。

それしかありませんね。
今回のbadblocksコマンドによるバッドセクタのチェックの際、/dev/sdc2に対してのみけっこう時間がかかりました。
それは、当然バッドセクタにぶちあたっているからなのですが、badblocksはセクタに対する読み込みについて一定時間以内に応答がなければ、その領域をバッドセクタとして次の領域のチェックにまわるのだと思います。

RECBOXでは、おそらくいつまでも読み取れないバッドセクタを読み続けることになるのでしょうね、いつか読み取れるだろうと信じながら・・・。

この領域が何のための領域なのかはわかりませんが、もし録画番組のインデックスがこの領域で生成されているのだとしたら、毎回の起動時にインデックスを読みに行くので必ずバッドセクタにぶちあたって以降の動作ができない状態になります。
これが原因で、RECBOXが起動できない状態になっているのだとしたら、HDDの交換は十分に有用でしょう。

ただ、コピーしようにも読み取れない領域はどうやったって読み取れないので、そこはどうなるのかは、コピーソフトの動作しだいなんでしょうけどね。

コピー先HDDもコピー元HDDも鼻毛鯖に取り付けることでコピー操作は可能でしょう。
RECBOX本体はコピー元HDDと同じキーを持っており、コピー後のHDDは、コピー元のHDDと同じキーをもっているので、HDDの交換をしたところで録画番組が再生できなくなり、動作はしたもののリセット(初期化)が必要になるということはおそらくないと思います(そう信じたいです)。
もちろん、録画データに対してなんらかのアクションを起こせばキーが変わるので、コピー元HDDは使用できない状態になるんでしょうけど。



要するに、物理的にHDDに問題があることが分かったので、新しいHDDにコピーを行ったうえでそれをRECBOXに取り付けてみて、それでもってちゃんと起動すれば万々歳だし、起動しなかったらいろいろと詰んだ状態になるなということで、もうこれが最後の手段ですな・・・と。

もしこれがダメならあきらめるしかないでしょう。
ほかに何の策もないので。
あとは、HDDのコピーでなんとかなることを祈るだけです・・・。その前にHDDを買わないとね。



一応、今回やったことのログも。

http://space.geocities.jp/asari_no_miso_soup/blog/recbox/recbox_log3.txt

途中途中で変なことをやっていますが、スルーしてください。



最後に・・・
すべて自己責任でお願いします。何かあっても当方は何も責任を取りません!
あと、私は3TBのHDDが手元にないとか、そういう理由でバックアップを取らずにオリジナルHDDをそのまま使っていますが、バックアップなりコピーなりをとってやった方が絶対にいいです!