「赤い靴」「雨降りお月さん」「青い目の人形」「しゃぼん玉」などのうたは、どこかで聞いたことがあるのではないでしょうか。これらの作品をつくった野口雨情(1892-1945)は、北原白秋、西条八十と並んで日本の三大童謡詩人のひとりです。素朴なひとつひとつの作品がすごく個性的で、見る人たちを童心に思いめぐらせてくれます。
公園の入り口にある野口雨情の説明文
童謡「赤い靴」の詩碑
野口雨情の故郷、北茨城市、に、これらの作品を刻んた詩碑があります。常磐自動車道下り線の中郷サービスエリア内にある公園に、地元にゆかりのある人たちの手によって造られました。
「青い目の人形」
「蜀黍(もろこし)畑」
「あの町この町」
そこには、大小６つの詩碑があり、ベルが設置されていました。
「雨降りお月さん」
また、いまのこの時期、紅葉がとてもきれいで、おもわず足を止めてしまいます。
童謡「赤い靴」をベルで演奏することもできました。
今回は、バス旅行の道中でちょっと立ち寄っただけなのですが、時間ができたら、もう一度訪れてみたい、そんなところでした。
(2019-11-17)
この五月連休のうちのある一日を使って、本田美奈子.ミュージアム[1] に行ってきました。
本田美奈子.といえば、昭和の代表的な歌姫のひとりですが、道半ばで急性骨髄性白血病を患い、残念ながら38歳という若さで他界されました。彼女のデビュー当時に間近に本人を見たこと、アメイジンググレイスのうたごえがきっかけとなって、本田美奈子.のことゑもっと知りたいとおもうようになったことは、以前に記事にしました。[2] [3] [4]
半年ほど前に、Twitterのお知らせメールで、本田美奈子.ミュージアムが開館したことを知り、いつか行ってみたいと思っていたのですが、なかなか機会がなく、この五月連休になってしまいました。
JR武蔵野線の北朝霞駅から南西の方向へ徒歩約25分、小川沿いにある倉庫街の一角にそのミュージアムはありました。
本田美奈子.の歌手としてのデビューは1985年。東芝EMIからレコードを出していました。
当時、私が勤務していたT社では、会社の福利厚生の一環である夏祭りのイベントとして、
芸能人を呼ぶ、ということもやっていました。その年は、本田美奈子でした。東芝EMIが同じT社のグループ会社のひとつであったというのも選択された理由なのでしょう。
彼女のうたごえについていえば、当時は、比較的激しいテンポの曲に合わせて、小柄な女の子が歌っているな、くらいの認識しかありませんでした。私が間近に美奈子本人を見たのは、これが最初でした。(そして最後でした。)
本田美奈子.ミュージアムには、彼女の歴史が綴られています。その後、1986年のマリリンを世に送り出し、ガールズバンドでロックも経験し、ミュージカルへの挑戦も、ポップスとクラシックを混ぜた新しいクラシカル・クロスオーバーというジャンルへの挑戦も、というキャリアを積んでいくのでした。
再び、本田美奈子.を知ることとなったのは、2005年、アメイジンググレイスのうたごえを聞いた時でした。
実際、それまでは、本田美奈子.がどのような活動をしているか知らなかったのです。このアメイジンググレイスのうたごえを聴いて、彼女のことをもっと知りたくなったのです。
本田美奈子.ミュージアムには、それぞれの時代の活動を知らせる写真と、当時使用していた衣装や小道具、台本、数々の賞をいただいたときの楯やトロフィーなどが電磁されています。ミス・サイゴンに出演したときの帝国劇場の楽屋を再現したブースもありました。
本田美奈子.の20年間の歌手としての人生で、彼女は日本の歌謡曲から演歌、ロック(ガールズバンド)、海外のポップスにいたるまで、ポピュラー音楽のジャンルをすべて歌い、ミュージカル女優として、また、クラシカル・クロスオーバーという新しい世界へと挑んでいました。シンガー・アーティストの中でも稀有な存在でした。
坪井賢一さんがダイヤモンド・オンラインから出版された「かの残響、清冽なり。本田美奈子.と日本のポピュラー音楽史」という電子書籍[5] には、「日本の100年にわたるポピュラー音楽の水流は、彼女の20年に流れ込んだように思える。」と書かれています。
ポップス歌手としてデビューした1985年から、最後のコンサートとなった2005年の、この20年間に、本田美奈子.のすべてが集約されています。
本田美奈子.のすごいところは、その音域の広さです。それもポップスからソプラノ音域のクラシックまで、「すべてのジャンルの歌をそれぞれの発声法で」しかも同一のコンサートの中で歌うといったことまで成し遂げています。YouTubeにも、彼女の音域の広さが分かる動画が投稿されていたことを思い出します。
坪井賢一さんも、「現在でも広い音域を自由に行き来する歌手は多数いる。・・・しかし、ソプラノ音域のクラシックまで、それも声楽の発声(頭声)で歌ったポップス歌手は彼女以外にはいない。・・・本田はそれぞれのジャンルをそれぞれの発声法で歌っており、これは例がない。」と絶賛されています。
本田美奈子.ミュージアムでのフィルムコンサートでも、彼女の音域の広さは伺い知ることができます。
本田美奈子.に会いに、本田美奈子.ミュージアムへ行きましょう。
(2019-5-18)
[1] 本田美奈子.ミュージアム
https://minako-museum.jimdofree.com/
→ 2024年2月にサイト閉鎖されました。
→ 2024年5月にリニューアルオープンの予定とのこと。それまでは
https://twitter.com/MinakoMuseum/
[2] あるアーティストの生涯 [3] 本田美奈子.と「ひめゆり」 [4] 本田美奈子.の最後のクリスマスコンサート [5] 坪井賢一「かの残響、清冽なり。本田美奈子.と日本のポピュラー音楽史」(ダイヤモンド社) 第1巻「再生」 第2巻「声楽」 第3巻「舞台」
.
(追記)
7月31日は、本田美奈子.さんの誕生日です。
本田美奈子.ミュージアムを紹介しているビデオメッセージを見つけたので、ご紹介します。
(2020-8-1 追記)
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
(2019-5-2)
あなたに、1時間に20通もの、しつこい迷惑メールが送られてきたら、そして、これらが携帯やスマホに着信していたら、あなたはどうされるでしょうか。
パソコンや携帯・スマホでご自分が意図しない迷惑メール、スパムメールを受け取ったという経験をお持ちの方も多いと思われます。
私はこれまでに何度も経験があります。
たいていの場合、無視していれば、そのうち止むものもありますが、そうではない場合もありました。
ひとつの事例をお話しますと、昨年の秋ごろに、このような迷惑メールの攻撃を受けました。
メール自体は長いタイトルと、本文には短い一文とURLが記載されているだけのものです。
しかし、そのメールの頻度はおよそ1時間に20通と常識的に考えても、異常なほどに多く、しつこいものでした。
また、メールの発信者のアドレスもそのたびごとに異なるものでした。
記載されているリンク先に関しては、あまり詳しくは触れませんが、海外に住所を有する出会い系サイトのひとつでした。
1時間に20通ほどのしつこい迷惑メールですが、もし、これを携帯やスマホで受信時に着信音が鳴るという設定にしていたら、着信する度に(およそ3分に一回)着信音が鳴るということになります。
もちろん、真夜中でも変わらず24時間着信し続けるのですから、人によっては気が狂ってしまうかもしれません。
どのようなタイトルかというと、
・ご注文ありがとうございます。
・確認していただけましたか？広川です。【５億】の受け取り許可は既に出ておりますので、【3000円】を追加されれば、いつでもお引き出しして頂けるようになっています。すぐにお引き出しして違反者解除を行なってください。罰金が発生する前にお受け取りされませんと
・救済支援会代表・広川美鈴です。私も、そしてこの救済金を寄付してくれた人も、貴方に報われてもらいたいと思っております。これまで、様々なサイトに登録してきたと思うのですが、支援履歴を見させていただき
・お急ぎ下さい。今日中には５億の一部でもいいのでお引き出し出来るようにしますからね。用意が出来ていれば今から
・広川です。【５億】は今日お引き出しして頂けますでしょうか？【3000円】の追加をされた後に引き出しが出来るようになっております。これを完了すれば違反の取り消しもされますからね。
・救済支援会代表・広川美鈴です。５億は既に入金しております。これであなたを違反者から救い出せますからね。救済金は貴方の為に本日、罰金の延期分の手数料も含めて対応をしておきました。私は受け取っていただく為のサポート役でしかありません。貴方が引き出し方が分からない場合であったり
・5億貰ってから私は車とマンションを買いました。自由に使ってくれていいって広川さんから言われてたんですけどなんだか本当に
・428万円の請求は本日24時まで延長されておりますのでお早めにご対応ください。救済金のお受け取りがされなかった場合、明日請求を開始させて頂きます。
・広川です。支援違反者になってしまった方１００名だけに連絡をさせて頂いております。３０００円の手続きだけで確実に受け取りできる人のみに連絡をしていますので
あるいは、
・「権利喪失」にご注意下さい。賠償金受給には期限が御座います。
・賠償金の受取りを辞退した場合についてご説明させて頂きます。大河内 真理子です。
・※本人以外、閲覧禁止※重要個人情報につき開封時注意して下さい。
・＝＝ATM残高確認依頼＝＝24時間以内に残高確認＋現金一部引き出しをお願いします。
・訴追弁護団代表：大河内 真理子です。賠償決定につき12億3000万円の受け渡しを行いますのでご確認下さい。
・〓最〓終〓案〓内〓※9名中_8名賠償金受取報告あり※
・民法415条・417条・709条によって損害賠償請求を行い勝訴しましたので至急、ご確認下さい。
・お知らせ：裁判に伴う重要連絡。弁護士からの連絡をお待ちください
・【寿】賠償金12億3000万円の受領、心からお祝い申し上げます。
このような場合、受信する側のメールアドレスを変更してしまうというのが、おそらくいちばん早い対処法なのですが、私の場合、このメルアド自体は普段使っているものなので、変更したくない、という気持ちもありました。そこで、メルアドを変更しないでなんとか解決できないか、と考えました。
ここでお伝えする内容は、あくまでも対処法の一例ですので、すべての場合に適用できるとは限りませんが、困っている方々になんらかの参考になればとおもい、記述するものです。
手順としては、まず、迷惑メールとおもわれるメール自体を、メールのヘッダー付きで保存しましょう。
そして、パソコンやスマホで、次のことを行なっていきます。
(1) Whois情報で迷惑メールの発信者のドメイン所有者・管理者を確認します。
(2) 非公開の場合は、ドメイン所有者の情報開示請求をします。
(3-1) 情報開示請求が承認された場合は、ドメイン所有者に配信停止依頼を行ないます。
(3-2) 情報開示請求が非承認の場合は、ドメインのレジストラ登録管理者に「ドメインの一時使用停止もしくは無効化」の要請をします。
この方法で、たいていのしつこい迷惑メールは止むとおもわれます。
もし、ここまでやってだめなら法的手段に訴えるしかありません。(やったことはありませんが、万が一の時のためにメールのコピーなどの証拠は残すようにしましょう。)
より詳しい手順の内容と実例は、
→ https://pc.fp46.net/pc01.html
に記載しました。必要な方はごらん下さい。
以上、なにかのご参考になれば幸いです。
(2019-1-27)