タグ:xfs
ホームPage 1 / 11
テレビ録画用外付けUSBハードディスク(USB-HDD)の故障とその修復・復旧の方法

1. はじめに

 

2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。

 

このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな?と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。

 

取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。

 

しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。

 

☆ ☆ ☆

 

さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。

 

その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。

 

この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

2. 確認手順の概略

 

(1) Linuxパソコン(PC)を準備する

(2) USB-HDDをマウントし、マウントボイントを確認する

(3) USB-HDDをアンマウントし、ディスクチェックを行なう

(4) USB-HDDのディスクファイルの修復を行なう

(5) USB-HDDを再度マウントしてファイルのリストを確認する

(6) 再度アンマウントしてディスクチェックを行なう

 

これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。

 

3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する

 

準備するものは、Linuxを起動できるパソコン(PC)と故障した(?)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。

 

液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。

 

必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)

 

CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。

 

以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。

 

まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。

 

この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。

そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。

 

次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。

 

以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。

 

次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1  ( または xfs_check /dev/sdb1 )

です。

すると、次のような表示がでてきました。

 

[root@localhost user01]# umount /dev/sdb1

[root@localhost user01]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3

expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3

bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 7195546658)

--- (途中、省略) ---

bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4502697197)

ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33

badly aligned inobt rec (starting inode = 5277979757)

bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6257491054)

--- (途中、省略) ---

bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4315432406)

ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34

badly aligned inobt rec (starting inode = 6034583137)

bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 5675287099)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4294967296)

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049

- 21:34:45: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

found inodes not in the inode allocation tree

- 21:34:45: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 30

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 13

- agno = 14

- 21:34:53: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:34:53: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:34:53: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 30

- agno = 31

- 21:34:53: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

No modify flag set, skipping filesystem flush and exiting.

[root@localhost user01]#

 

これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。

 

4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう

 

次に、修復できるかどうかをやってみました。使用するコマンドは、

xfs_repair -Lv /dev/sdb1

です。

 

ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。

 

今回は、次のような表示がでてきました。

 

[root@localhost user01]# xfs_repair -Lv /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

- block cache size set to 332184 entries

Phase 2 - using internal log

- zero log...

zero_log: head block 199805 tail block 199805

- scan filesystem freespace and inode maps...

bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

--- (途中、省略) ---

ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31

badly aligned inobt rec (starting inode = 7924286411)

bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6393507745)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152

sb_fdblocks 52700857, counted 52709049

- 21:37:17: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan and clear agi unlinked lists...

found inodes not in the inode allocation tree

- 21:37:17: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 21:37:25: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:37:25: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:37:25: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 26

- 21:37:25: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

Phase 5 - rebuild AG headers and trees...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 31

- 21:37:25: rebuild AG headers and trees - 32 of 32 allocation groups done

- reset superblock...

Phase 6 - check inode connectivity...

- resetting contents of realtime bitmap and summary inodes

- traversing filesystem ...

- agno = 0

--- (途中、省略) ---

- agno = 31

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify and correct link counts...

- 21:37:25: verify and correct link counts - 32 of 32 allocation groups done

XFS_REPAIR Summary Tue Apr 30 21:37:25 2019

Phase Start End Duration

Phase 1: 04/30 21:37:06 04/30 21:37:06

Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds

Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds

Phase 4: 04/30 21:37:25 04/30 21:37:25

Phase 5: 04/30 21:37:25 04/30 21:37:25

Phase 6: 04/30 21:37:25 04/30 21:37:25

Phase 7: 04/30 21:37:25 04/30 21:37:25

Total run time: 19 seconds

done

[root@localhost user01]#

 

今回は、Phase1、Phase2、・・・、Phase7 と進んでいき、終了した(「done」)との表示でした。

 

もしも、この操作の実行中に、

 

Phase 1 – find and verify superblock…

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error — 入力/出力エラーです

 

のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。

 

5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう

 

さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。

デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)

 

今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。

そのディレクトリまで進み、ファイルの存在状態を確認しました。

 

[root@localhost user01]# cd /run/media/user01

[root@localhost user01]# ls

e4f007b8-c779-4d7a-a2db-34c15c363213

[root@localhost user01]# cd e4f007b8-c779-4d7a-a2db-34c15c363213

 

コマンドは「ls -al」です。

 

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# ls -al

合計 1742544948

drwxr-xr-x. 3 root root 53248 4月 30 12:30 .

drwxr-x---+ 3 root root 60 4月 30 21:46 ..

-rw-r--r--. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a

-rw-r--r--. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a

-rw-r--r--. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a

drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a

--wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat

--wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat

--- (途中、省略) ---

--wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# cd .toshibazze89d874cd80a

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]#

[root@localhost .toshibazze89d874cd80a]# cd log

[root@localhost log]# ls -al

合計 188

drwxr-xr-x. 2 root root 97 4月 22 10:59 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 51200 3月 17 22:59 00000064.dat

-rw-r--r--. 1 root root 51200 4月 6 10:33 00000065.dat

-rw-r--r--. 1 root root 51200 4月 22 10:59 00000066.dat

-rw-r--r--. 1 root root 27008 4月 30 12:30 00000067.dat

-rw-r--r--. 1 root root 11 4月 22 10:59 info.dat

[root@localhost log]#

[root@localhost log]# cd ..

[root@localhost .toshibazze89d874cd80a]# cd alkf

[root@localhost alkf]# ls -al

合計 60

drwxr-xr-x. 2 root root 4096 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.bin

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.buc

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.bin

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.buc

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.bin

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.buc

-rw-r--r--. 1 root root 32 11月 4 2013 ald.bin

-rw-r-----. 1 root root 32 11月 4 2013 alk.bin

[root@localhost alkf]#

[root@localhost alkf]# cd ..

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]# cd aeef0000000

[root@localhost aeef0000000]# ls -al

合計 520

drwxr-xr-x. 2 root root 8192 4月 29 16:00 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 8月 28 2018 aee00000000.bin

-rw-r--r--. 1 root root 80 3月 7 2017 aee00000001.bin

-rw-r--r--. 1 root root 80 6月 25 2014 aee00000002.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 2月 15 2017 aee0000007e.bin

-rw-r--r--. 1 root root 80 3月 1 2017 aee0000007f.bin

[root@localhost aeef0000000]#

[root@localhost aeef0000000]# cd ../aeef0000001

[root@localhost aeef0000001]# ls -al

合計 500

drwxr-xr-x. 2 root root 8192 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 12月 5 20:15 aee00000080.bin

-rw-r--r--. 1 root root 80 8月 5 2015 aee00000081.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 12月 3 2017 aee000000ff.bin

[root@localhost aeef0000001]#

[root@localhost aeef0000001]# cd ../aeef0000002

[root@localhost aeef0000002]# ls -al

合計 140

drwxr-xr-x. 2 root root 4096 4月 27 15:22 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 2月 27 20:15 aee00000101.bin

-rw-r--r--. 1 root root 80 3月 3 23:25 aee00000103.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 5月 14 2018 aee00000137.bin

[root@localhost aeef0000002]#

 

以上のように、修復されたファイルの状態を確認することができました。

 

最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1

です。

 

[root@localhost ~]# umount /dev/sdb1

[root@localhost ~]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...

sb_fdblocks 52700857, counted 52709049

- 22:13:57: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

- 22:13:57: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 22:14:05: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 22:14:05: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 22:14:05: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 2

--- (途中、省略) ---

- agno = 31

- agno = 1

- 22:14:05: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Phase 6 - check inode connectivity...

- traversing filesystem ...

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify link counts...

- 22:14:05: verify and correct link counts - 32 of 32 allocation groups done

No modify flag set, skipping filesystem flush and exiting.

[root@localhost ~]#

 

特に、問題はなさそうです。

 

この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。

 

6. まとめ

 

以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

------------------------------------------------------------------
References

[1] 液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)

[2] 「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
------------------------------------------------------------------

 

(2019-5-2)

 

 

 

液晶テレビに接続したUSBハードディスクの故障と対策

我が家の居間には、37型の液晶テレビ(東芝レグザREGZA)がおいてあり、そこに、USBハードディスクが接続されている。

 

いつもは、テレビ番組を録画して、時間の余裕のあるときに再生などをしている。もっとも、使用するのは私自身ではなく、専ら家族たちである。

 

先日も、ふつうに録画した番組を見ていたのだが、突然、「これなあに? どうなってるの?」との大声。

 

呼ばれて行ってみると、テレビの画面には、

「未登録のUSBハードディスクを検出しました。USBハードディスクの登録を行いますか?」

という表示がでており、

ここで「はい」を押すと、

「登録を行うために、初期化を行います。このUSBハードディスクの内容はすべて消去されます。よろしいですか?」
との表示になった。

 

もちろん「よろしい」わけはない。

そのハードディスクには、採り貯めた「まだ見ていない」番組のデータファイルがあるのだ。

 

いつもは、リモコンの録画リストというボタンを押すと、録画された番組の一覧が表示されるのだが、今回は、「未登録のUSBハードディスクを検出しました。.....」の表示になっている。

 

そこで、取扱説明書を見ながら、USBハードディスクの設定なるものをトライしてみた。
だが、いっこうに元にもどらない。

 

これは、もしかしたら、ハードディスクの故障かもとおもい、
テレビから取り外し、パソコン(PC)に接続して確認することにした。

 

Windowsでは、xfs形式のファイルは認識できないため、LinuxOS(Fedora)のPCに接続してみた。

自動的にマウントされ、USBディスクのプロパティを見ると、録画したUSBハードディスクは、1TBの容量で、ほぼ99%が使用済みの状態が確認できた。

 

いったん、アンマウントし、ファイルのチェックを行なった。

 

# umount /dev/sdb1

# xfs_check /dev/sdb1

.

can't read block 8388608 for directory inode 128

dir ino 128 missing leaf entry for 165273d8/bd8

.

block 0/7630956 type unknown not expected

sb_fdblocks 2747039, counted 2651561

 

次に、修復できるかを行なってみた。

 

# xfs_repair -Lv /dev/sdb1

Phase 1 - find and verify superblock...

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error -- 入力/出力エラーです

 

との表示がでて、終了した。

 

本来、正常であれば、Phase 2, Phase 3, ... といけるはずなのに、それができなかった。

 

そこで、強制的にマウントし、ファイルのリストがでてくるかを確認した。

 

# mkdir ../../test1

# mount -t xfs /dev/sdb1 /test1 -o ro,norecovery

# xfs_logprint /dev/sdb1

xfs_logprint:

data device: 0x811

log device: 0x811 daddr: 976762528 length: 262144

Header 0x93 wanted 0xfeedbabe


**********************************************************************

* ERROR: header cycle=147 block=42066 *


**********************************************************************

Bad log record header

 

やはり、だめか。次に、強制的にファイルの表示をやってみた。

 

# cd /test1

# ls -al

ls: cannot access .toshibazze89d874cd80a: 入力/出力エラーです

ls: cannot access .toshiba_size_info_e89d874cd80a: 入力/出力エラーです

ls: cannot access M000020100220034450e89d874cd80a.dtv.meta: 入力/出力エラーです

ls: cannot access M000020131029154951e89d874cd80a.dtv: 入力/出力エラーです

ls: cannot access M000020130514205951e89d874cd80a.dtv.meta: 入力/出力エラーです

ls: cannot access .toshiba_dir_info_e89d874cd80a: 入力/出力エラーです

.

.

 

ここでお分かりのように、ハードディスクのヘッダーの一部が読み込みできない状態になっていたのであった。

 

おそらく、これはもう、USBハードディスクの摩耗故障で、寿命だ、と判断した。

 

ちょうど、WindowsでいうところのFAT(File Allocation Table)が壊れている状態なのだろう。

 

残念だが、ここまでくると、あきらめるしかない。

 

次の日には、新しいUSBハードディスクを買いに、家電量販店まで足を伸ばしたのであった。

そして、すぐに接続し登録して、新たに録画ができるようにしたのであった。

 

(2013-11-10)

 

 

なお、参考にさせていただいたサイトは次のとおりです。

 

レグザ USBハードディスクの傾向と対策

http://regza2000.bbs.fc2.com/?act=reply&tid=4056693

 

「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 - レグザREGZA研究

http://www.4682.info/repair

 

 

 

 

ホームPage 1 / 11