月別:2019年05月
ホームPage 1 / 11
  • 音楽
本田美奈子.ミュージアム、「かの残響、清冽なり」

この五月連休のうちのある一日を使って、本田美奈子.ミュージアム[1] に行ってきました。

 

本田美奈子.といえば、昭和の代表的な歌姫のひとりですが、道半ばで急性骨髄性白血病を患い、残念ながら38歳という若さで他界されました。彼女のデビュー当時に間近に本人を見たこと、アメイジンググレイスのうたごえがきっかけとなって、本田美奈子.のことゑもっと知りたいとおもうようになったことは、以前に記事にしました。[2]  [3]  [4]

 

半年ほど前に、Twitterのお知らせメールで、本田美奈子.ミュージアムが開館したことを知り、いつか行ってみたいと思っていたのですが、なかなか機会がなく、この五月連休になってしまいました。

 

JR武蔵野線の北朝霞駅から南西の方向へ徒歩約25分、小川沿いにある倉庫街の一角にそのミュージアムはありました。

 

stage

 

本田美奈子.の歌手としてのデビューは1985年。東芝EMIからレコードを出していました。
当時、私が勤務していたT社では、会社の福利厚生の一環である夏祭りのイベントとして、
芸能人を呼ぶ、ということもやっていました。その年は、本田美奈子でした。東芝EMIが同じT社のグループ会社のひとつであったというのも選択された理由なのでしょう。

 

彼女のうたごえについていえば、当時は、比較的激しいテンポの曲に合わせて、小柄な女の子が歌っているな、くらいの認識しかありませんでした。私が間近に美奈子本人を見たのは、これが最初でした。(そして最後でした。)

 

minako_1_1985 minako_2_1992

 

本田美奈子.ミュージアムには、彼女の歴史が綴られています。その後、1986年のマリリンを世に送り出し、ガールズバンドでロックも経験し、ミュージカルへの挑戦も、ポップスとクラシックを混ぜた新しいクラシカル・クロスオーバーというジャンルへの挑戦も、というキャリアを積んでいくのでした。

 

history_1 history_2

 

history_3 history_4

 

再び、本田美奈子.を知ることとなったのは、2005年、アメイジンググレイスのうたごえを聞いた時でした。

 

実際、それまでは、本田美奈子.がどのような活動をしているか知らなかったのです。このアメイジンググレイスのうたごえを聴いて、彼女のことをもっと知りたくなったのです。

 

本田美奈子.ミュージアムには、それぞれの時代の活動を知らせる写真と、当時使用していた衣装や小道具、台本、数々の賞をいただいたときの楯やトロフィーなどが電磁されています。ミス・サイゴンに出演したときの帝国劇場の楽屋を再現したブースもありました。

 

exhibition_1 exhibition_2

 

本田美奈子.の20年間の歌手としての人生で、彼女は日本の歌謡曲から演歌、ロック(ガールズバンド)、海外のポップスにいたるまで、ポピュラー音楽のジャンルをすべて歌い、ミュージカル女優として、また、クラシカル・クロスオーバーという新しい世界へと挑んでいました。シンガー・アーティストの中でも稀有な存在でした。

 

坪井賢一さんがダイヤモンド・オンラインから出版された「かの残響、清冽なり。本田美奈子.と日本のポピュラー音楽史」という電子書籍[5] には、「日本の100年にわたるポピュラー音楽の水流は、彼女の20年に流れ込んだように思える。」と書かれています。

 

 

ポップス歌手としてデビューした1985年から、最後のコンサートとなった2005年の、この20年間に、本田美奈子.のすべてが集約されています。

 

本田美奈子.のすごいところは、その音域の広さです。それもポップスからソプラノ音域のクラシックまで、「すべてのジャンルの歌をそれぞれの発声法で」しかも同一のコンサートの中で歌うといったことまで成し遂げています。YouTubeにも、彼女の音域の広さが分かる動画が投稿されていたことを思い出します。

 

坪井賢一さんも、「現在でも広い音域を自由に行き来する歌手は多数いる。・・・しかし、ソプラノ音域のクラシックまで、それも声楽の発声(頭声)で歌ったポップス歌手は彼女以外にはいない。・・・本田はそれぞれのジャンルをそれぞれの発声法で歌っており、これは例がない。」と絶賛されています。

 

本田美奈子.ミュージアムでのフィルムコンサートでも、彼女の音域の広さは伺い知ることができます。

 

本田美奈子.に会いに、本田美奈子.ミュージアムへ行きましょう。

 

 

(2019-5-18)

 

 

[1] 本田美奈子.ミュージアム https://minako-museum.jimdofree.com/

[2] あるアーティストの生涯

[3] 本田美奈子.と「ひめゆり」

[4] 本田美奈子.の最後のクリスマスコンサート

[5] 坪井賢一「かの残響、清冽なり。本田美奈子.と日本のポピュラー音楽史」(ダイヤモンド社)  第1巻「再生」  第2巻「声楽」  第3巻「舞台」

 

.

 

 

 

テレビ録画用外付け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)

 

 

 

ホームPage 1 / 11