☰

これらのエラーは実際には何を意味し、その原因は何でしょうか?

tag-icon • tag-icon hard-drive bash cygwin pata bad-blocks
これらのエラーは実際には何を意味し、その原因は何でしょうか?

の実行中にこのエラーが発生するのは今回が 2 回目badblocksで、前回から約 2 年が経過しています。ハードウェア (ケーブルなど) からソフトウェア (オペレーティング システム自体のインストール) に至るまで、ほとんどの要素がそれ以来変更されており、関連する共通要素は とCygwinプログラムbadblocks自体のみであるため、問題はこれらの間に存在している可能性が非常に高くなります。

badblocks破壊モード（つまりスイッチを使用）で実行すると-w、次のエラーが発生します。

do_writerrors の奇妙な値 (4294967295)

...パターンをドライブに書き込む各段階で。

私の知る限り、このエラーは、次のように報告された指定された最後のブロックを使用してコマンドを実行した場合にのみ発生するようですfdisk -l。

$ fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

$ badblocks -b 512 -vws /dev/sda 1953525168 1953525168
Checking for bad blocks in read-write mode
From block 1953525168 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:00 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)

$ badblocks -b 512 -vws /dev/sda 1953525168 1950000000
Checking for bad blocks in read-write mode
From block 1950000000 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:49 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)

ご覧のとおり、これも不良ブロックの誤検出を引き起こしますが、この不良ブロックは CrystalDiskInfo ではどこにも見つかりません。

ここに画像の説明を入力してください

この時点で、ドライブは複数回ゼロ化され、badblocks最後の数ブロックに何十回も書き込まれているため、ブロック内に不良セクターが存在する場合、SMART 値がその不良セクターを検出する機会が十分にありました1953525168。

これらのエラーは実際には何を意味し、その原因は何でしょうか?

答え1

harrymc は私の回答の核心 (つまり ) を説明したかもしれませんが4294967295、がそれを として単純に「認識」しない理由 (つまり、Windows で Cygwin ビルドすると「奇妙な値」エラーが発生する理由) については詳しく説明しません-1でした。unsigned intbadblocks-1

badblocksCygwinのコードを見てみました:

https://github.com/tytso/e2fsprogs/blob/v1.45.4/misc/badblocks.c#L463

https://github.com/cygwin/cygwin/tree/01c253a4c58b6c1da01615431bdc4c88fcba48ea/newlib/libc/syscalls/syswrite.c

: github.com/cygwin/cygwin/tree/01c253a4c58b6c1da01615431bdc4c88fcba48ea/newlib/libc/reent/writer.c

そして私はこれを思いつきました:

[tom@archlinux ~]$ cat test.c 
#include <stdio.h>

unsigned int eh() {
  return -1;
}

int main() {
  long got;
  got = eh();
  printf("%ld\n", got);
  got = (long) eh();
  printf("%ld\n", got);
  got = (int) eh();
  printf("%ld\n", got);
}
[tom@archlinux ~]$ cc test.c 
[tom@archlinux ~]$ ./a.out 
4294967295
4294967295
-1
[tom@archlinux ~]$

基本的にこれは、符号なし変数 (符号付き値を格納するために意図的に使用される可能性がある) を符号付き変数として解釈する場合、その変数自体のサイズで解釈する必要があり、その値を格納する別の変数のサイズで解釈するべきではないということを意味しています。

私はプログラミングに詳しいわけではありませんが、ご覧のとおり、 の(_ssize_t)型キャストはreent/writer.cおそらく間違っています。 が型 (または任意の符号付き型)_write()であると仮定すると、このような型キャストは冗長です。 が 型であると仮定すると、必要な型キャストは になります。(記録によると、これが必要なのは、その値を に(つまり) 「拡張」するためだけです。 のような比較は、私の知る限り、問題なく機能します。)int_write()unsigned int(int)_ssize_tret(an_unsigned_int == -1)

ただし、これは単なる推測に過ぎず、Cygwinの使用法についてはよく知らない_write()（例えば、それがこれ、もしそうなら、そのドキュメントはただのゴミなのかどうか）。しかし、私はそれがバグレポート、これにより、さらに詳しい情報が得られるかもしれません。

アップデート：これご覧のとおり、これは「回帰」を導入するコミットである可能性があります（基本的にはコミットメッセージに基づいて_ssize_tいます）。おそらく、Cygwinが64ビットになったときに、__SIZE_TYPE__size_tunsigned longこれそしてこれ)なので、32ビットCygwinでは（64ビットWindowsでも）問題を再現できないと思います。さらに以前のコミットおそらく一度は「修正」したはずです。だから私はそれを「回帰」と呼んでいます。

更新2: はい、私は正しいです: ここに画像の説明を入力してください おそらく今は Visual Studio を入手して、ちょっと確認してみる(_write()そしておそらく) 必要があるでしょう...write()

PS 「最後のブロック + 1」で読み取り専用テストを実行している場合、「奇妙な値」エラーに遭遇することはありません。_read()はを返し、に設定するのと0は異なり、は を返します。_write()-1errnoENOSPCファイルの末尾を読み取ろうとする" （ドライブ）。

答え2

10 進数値4294967295(16 進数) はFFFFFFFF、単純に-1符号なし 32 ビット整数として表されます。これは一般的な API エラー コードであり、他の意味はありません。このユーティリティはbadblocksLinus Torvalds によって数十年前に書かれた非常に基本的なもので、データを書き出して読み戻すだけです。

修正不可能なセクター数 ディスク ファームウェアが検出した不良セクターの数を示しますが、これらのセクターを読み取ることができなかったため、正常なセクターに再配置できませんでした。ファームウェアは、これらのセクターの再配置をあきらめました。

したがって、ファームウェアが検出したものの、再マップできないカバー不能なセクターが 459 個あります。

ディスクは間違いなく末期段階にあります。

ディスクを修復したいが、その内容は気にしない場合は、ディープ フォーマットを試して、すべての正常なセクターを書き換えて更新し、ファームウェアがアクセスできないセクターを不良としてマークすることができます。ここでは、製造元のユーティリティが望ましいです。Cygwin は避けてください。その Linux ユーティリティは Windows との良好な統合が保証されていないためです。

の DiamondMax サポートページ 最新のディスクユーティリティを提案する ディスクウィザード バージョン: 23.0.17160、おそらくディープフォーマットを実行できるでしょう。これは Windows ユーティリティです。

問題のディスクがWindowsシステムディスクである場合は、Windows PEブートディスクまたは次のようなレスキューディスクからユーティリティを実行する必要があるかもしれません。 Bob.Omb の修正版 Win10PEx64. また、 起動可能な Windows PE ベースのリカバリ ディスク のような ハイレンのBootCD PE緊急の場合は、Linux ライブ ブートからディスクをフォーマットしてみることもできます。

（書き直した投稿への追加）

上記の回答は、投稿者によって 2 年前に承認され、ディスクが交換されたようです。この部分は新しいディスクに関するものです。

新しいディスクは完璧な状態で欠陥もありませんが、badblocks は 1 つのエラー メッセージを表示します。

Badblocks は、おそらく Linux が存在する前から Linus Torvalds によって書かれた古いユーティリティです。このユーティリティは、一時ファイルを作成し、スペースの終わりに達するまで書き込み、データを再読み込みするだけです。ディスク テストとしてはひどいもので、ディスクの空き領域を「テスト」するだけです。

さらに、これは Windows ではなく Cygwin 上で実行されているため、Windows が返すエラー コードの理解は非常に疑わしいものです。実際のエラー コードを報告することすらできず、代わりに常に を-1 エラー コードとして報告します。Cygwin が Windows API エラー コードを、同等の Linux エラー コードであると想定されるコードに変換しようとした場合の結果がどうなるかは想像もつきません。

率直に言って、私はこの 1 つの誤ったエラーを意味のないものとして無視します。おそらく、badblocks または Cygwin のいずれかが「no-more-space」戻りコードを誤解したために発生したものでしょう。SMART ファームウェアによって返されるデータは、はるかに重要なものです。

ポストで Windows または DOS の badblocks に相当 いくつかの提案が提示されましたが、それらはすべて空き領域だけでなくディスク全体をテストするため、badblocks よりもはるかに優れています。

良い代替案の1つはchkdsk /r、Windowsユーティリティを使用する です。チェックディスク ディスク全体の物理ディスク エラーを分析して、不良セクタを見つけて読み取り可能な情報を回復します。

関連情報