Landscape トップページ | < 前の日 2005-09-25 2005-09-27 次の日 2005-09-29 >

Landscape - エンジニアのメモ 2005-09-27

NTFS でファイル レコード セグメント 読み取れませんエラー


* NTFS でファイル レコード セグメント 読み取れませんエラー

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [Windows] [PC]

やってしまった。iPod のケーブルと間違えて、USB2.0 の外付けハードディスクのケーブルを動作している最中に抜いてしまった。しかも、抜いた後気づくのがかなり遅れた。その結果、USB2.0 の外付けディスクが読めなくなってしまった。

USB2.0 のハードディスクは、2005-03-31 の「USB 2.0 外付けハードディスクケースを購入」で購入したもの。つまり、ケースだけ。中身は Maxtor 96147U8 で、容量は60GB。以前は USB2.0 のカードを使って接続していたが、2005-06-18 の「Athlon64 マシンを自作する」で作った ASUS A8V-E DELUXE /NW に直接接続するようにしている。

- 症状

まず、エクスプローラの起動にかなり時間がかかる。おそらく、該当ドライブのファイルのインデックスを読みに行って、読めないので何度もリトライしているんだろう。イベントログを見ると、以下のエラーが大量に記録されていた。

デバイス \Device\Harddisk2\D に不良ブロックがあります。

この流れはやばい。とりあえず chkdsk コマンドで復旧を試みる。

- chkdsk 実行

コマンドプロンプトから chkdsk を実行。

C:\Documents and Settings\hiroaki>chkdsk f: /F
ファイル システムの種類は NTFS です。
ボリューム ラベルは ボリューム です。

CHKDSK はファイルを検査しています (ステージ 1/3)...
ファイル レコード セグメント 24 を読み取れません。
ファイル レコード セグメント 25 を読み取れません。
ファイル レコード セグメント 26 を読み取れません。
ファイル レコード セグメント 27 を読み取れません。
ファイル レコード セグメント 904 を読み取れません。
ファイル レコード セグメント 905 を読み取れません。
ファイル レコード セグメント 906 を読み取れません。
ファイル レコード セグメント 907 を読み取れません。
ファイル レコード セグメント 968 を読み取れません。
ファイル レコード セグメント 969 を読み取れません。
ファイル レコード セグメント 970 を読み取れません。
ファイル レコード セグメント 971 を読み取れません。
ファイル レコード セグメント 996 を読み取れません。
ファイル レコード セグメント 997 を読み取れません。
ファイル レコード セグメント 998 を読み取れません。
ファイル レコード セグメント 999 を読み取れません。
ファイルの検査を完了しました。
CHKDSK はインデックスを検査しています (ステージ 2/3)...
ファイル 28 内のインデックス $I30 のインデックス エントリ BOARD_~1.ZIPを削除します。
ファイル 28 内のインデックス $I30 のインデックス エントリ BOARD_MEETING20050801.ZIP を削除します。
ファイル 214 内のインデックス $I30 のインデックス エントリ LOG20050912 を削除します。
ファイル 214 内のインデックス $I30 のインデックス エントリ LOG200~1 を削除します。
ファイル 214 内のインデックス $I30 のインデックス エントリ trackdown を削除します。
ファイル 214 内のインデックス $I30 のインデックス エントリ trackd~1 を削除します。
ファイル 641 内のインデックス $I30 のインデックス エントリ 01-Children Dream Version.wav を削除します。
ファイル 641 内のインデックス $I30 のインデックス エントリ 02-Fable Dream Version.wav を削除します。
ファイル 641 内のインデックス $I30 のインデックス エントリ 01-CHI~1.WAV を削除します。
ファイル 641 内のインデックス $I30 のインデックス エントリ 02-FAB~2.WAV を削除します。
インデックスの検査を完了しました。
CHKDSK は破損ファイルを回復しています。
ファイル レコード セグメント 25 のフラグを修復しています。
ファイル 25 の軽度なエラーを修復します。

いくつかのファイルは壊れていて、削除されてしまった。でも、とりあえず chkdsk は終了した。これで復旧できたかな? もう一度エクスプローラを立ち上げても、症状が変わらない。かなり長い時間待たされる。そして、イベントログにはさっきと同じエラーが記録されている。修復できてないの? もしかしたらこのディスク、もう二度と読めないのかも?

もう一度 chkdsk してみる。あんまり意味がないかもしれないけど、今度はもっと多くのオプション付き。

C:\Documents and Settings\hiroaki>chkdsk f: /f /V /R /X
ファイル システムの種類は NTFS です。
ボリューム ラベルは ボリューム です。

CHKDSK はファイルを検査しています (ステージ 1/5)...
ファイル レコード セグメント 24 を読み取れません。
ファイル レコード セグメント 25 を読み取れません。
ファイル レコード セグメント 26 を読み取れません。
ファイル レコード セグメント 27 を読み取れません。
ファイル レコード セグメント 904 を読み取れません。
ファイル レコード セグメント 905 を読み取れません。
ファイル レコード セグメント 906 を読み取れません。
ファイル レコード セグメント 907 を読み取れません。
ファイル レコード セグメント 968 を読み取れません。
ファイル レコード セグメント 969 を読み取れません。
ファイル レコード セグメント 970 を読み取れません。
ファイル レコード セグメント 971 を読み取れません。
ファイル レコード セグメント 996 を読み取れません。
ファイル レコード セグメント 997 を読み取れません。
ファイル レコード セグメント 998 を読み取れません。
ファイル レコード セグメント 999 を読み取れません。
ファイルの検査を完了しました。
CHKDSK はインデックスを検査しています (ステージ 2/5)...
ファイル 5 内のインデックス $I30 のインデックス エントリ found.003 を削除します。
インデックスの検査を完了しました。
ドライブ上の軽度な矛盾をクリーンアップしています。
CHKDSK は破損ファイルを回復しています。
ファイル レコード セグメント 25 のフラグを修復しています。
ファイル 25 の軽度なエラーを修復します。

chkdsk のオプションの意味。/F さえ指定しておけばいいような雰囲気。やっぱり意味無いかな・・と思ったけど、chkdsk のステージ数が 3 から 5に増えてるね。より徹底的にやってくれている模様。
/F              ディスクのエラーを修復します。
/V              FAT/FAT32:ディスクの全ファイルの完全なパスと名前を表示します。
                NTFS: クリーン アップ メッセージがあればそれも表示します。
/R              不良セクタを見つけ、読み取り可能な情報を回復します。
                (/F を意味します)
/X              必要であれば、最初にボリュームを強制的にマウントを解除
                します。ボリュームへ開かれているすべてのハンドルは、無効
                になります。

chkdsk 完了。でも、エクスプローラでアクセスしようとするとやっぱり時間がかかり、イベントログにはエラーが記録される。何回 chkdsk してもこの状態から進まない。症状としては、ファイルのデータそのものはディスク上にはあるんだけど、それにアクセスするためのインデックス情報が破損している。で、chkdsk でそれを修復しようとしたが、修復しきれない状態。

こんな状態でも、サルベージする方法はいろいろあると思う。別のディスクにダンプして生きてるデータだけ吸い出していくとか。でも、そこまでしなくても、今回は何とかなりそう。このドライブは更新頻度が低いデータ保存用ドライブ。CD からリッピングしたデータや、様々なアーカイブを保存している。1ヶ月前に取ったバックアップもある。諦めてフォーマットした方が早い。

フォーマットしたらエラーが出なくなった。で、別ディスクからバックアップをリストア。データはちょっと古いけど、まあ大丈夫。やっぱりバックアップ重要。

- NTFS ってジャーナリングファイルシステムなのに

そういえば、動作中のドライブから SCSI ケーブルを抜いたときの各ファイルシステムの障害耐性を調べたレポートで、ext3 だか何かが怪しい挙動を示したというのをどこかで読んだ気がする。でも、今回の体験をしたので私にとっては NTFS も ext3 も同じレベルだ。いや、むしろクラッシュしたことがない分、ext3 の方が信頼が置ける。個人的経験だけでは信頼性は測れないとはわかっているけど、やっぱり心証的に悪い。

そもそもファイルのインデックスってメタデータで、ファイルシステムのジャーナリング機能で保護されるはず。なのに、今回はしっかりファイルシステム的にクラッシュしたのはなぜ? 突然の電源断には耐えられても、USBケーブルの挿抜には耐えられないってこと? もしかして、USB ストレージのコントローラやドライバが悪いのかな?

すべての記事の見出し (全1029件)
全カテゴリの一覧と記事の数
カテゴリごとに記事をまとめ読みできます。記事の表題だけを見たい場合は、すべての記事の見出し (カテゴリ別表示) へ。

直近30日分の記事
2007-04-23 (Mon)
2007-03-07 (Wed)
2007-02-27 (Tue)
2007-01-17 (Wed)
2007-01-15 (Mon)
2007-01-14 (Sun)
2007-01-08 (Mon)
2006-12-01 (Fri)
2006-11-22 (Wed)
2006-11-20 (Mon)
2006-11-19 (Sun)
2006-09-30 (Sat)
2006-08-29 (Tue)
2006-08-04 (Fri)
2006-07-27 (Thu)
2006-07-23 (Sun)
2006-07-17 (Mon)
2006-07-10 (Mon)
2006-07-06 (Thu)
2006-07-03 (Mon)
2006-06-29 (Thu)
2006-06-28 (Wed)
2006-06-27 (Tue)
2006-06-25 (Sun)
2006-06-19 (Mon)
2006-06-18 (Sun)
2006-06-15 (Thu)
2006-06-11 (Sun)
2006-06-01 (Thu)
2006-05-30 (Tue)
プロファイル
斎藤 宏明。エンジニアです。宇都宮市に住んでいます。
リンク
RSS
スポンサードリンク
Powered by
さくらインターネット

© 斎藤 宏明 Saito Hiroaki Gmail Address
Landscape - エンジニアのメモ http://sonic64.com/
Landscape はランドスケープと読みます。
ひらがなだと らんどすけーぷ です。