sudo dd if=/dev/sda of=/dev/sda代わりに、私が誤って逃げたとしましょう。sudo dd if=/dev/sda of=/dev/sdb
システムが損傷しているかどうかを確認するために500 GBの操作が完了するのを待ちたくありません。
完了するまで落ち着いて待機または中断し、長い時間が経過した後に再インストールを開始できるように結果がどのようになるかを知っている人はいますか？
編集：結果の出力は次のとおりです。
$ time sudo dd if=/dev/sda of=/dev/sda bs=64K conv=sync,noerror status=progress
512001769472 bytes (512 GB, 477 GiB) copied, 9084 s, 56.4 MB/s
dd: error writing '/dev/sda': No space left on device
7814181+1 records in
7814181+0 records out
512110190592 bytes (512 GB, 477 GiB) copied, 9088.72 s, 56.3 MB/s
real 151m28.774s
user 0m28.459s
sys 5m33.146s
答え1
別に、dd if=/dev/sdx of=/dev/sdx既に存在する同じデータが記録される。害はなかった(*)
ただし、ファイルシステムなどでデバイスを積極的に使用すると、競合状態が発生する可能性があります。
ddはデータ（A）を読み込み、ファイルシステムはデータ（B）を書き、ddはデータ（A）を書き込むので（B）損失/損傷が発生します。
したがって、データの損失やシステムの競合が発生する可能性があります。
SSDストレージの場合に発生する可能性がある他の副作用は、書き込みサイクルが無駄になり、スパースファイル/シンボリューム/スナップショットがより多くのストレージスペースを占めることです。
また、ブロックデバイスの代わりに通常のファイルで同じ操作を実行すると、結果は空のファイルになり、すべてのデータが失われます。
$ dd if=foobar of=foobar
0+0 records in
0+0 records out
0 bytes copied, 0.000179684 s, 0.0 kB/s
conv=notruncこれは、出力ファイルをゼロバイトに切り捨てないと、ゼロバイトファイルddから読み取ることができるのはすべてゼロバイトであるためです。
seek(*) , skip, noerror, ... など、オフセットを変更できる他のオプションを使用する場合や、パーティショニングを通じてこれらのオフセットを導入するデバイスとはsync異なりますが、同じデバイスを使用する場合を除きます。if=/dev/sdx of=/dev/sdx1この場合、dd同じデータパターンを繰り返し作成します（以前はオフセットに書き込まれた内容を読み取ってください）。それはすべてを腐食させます。
デバイスが読み取りエラーとして正しく報告せず、誤ったデータを誤って返すよりも曖昧な場合があります。この場合、破損したデータがデバイスに書き換えられます。
答え2
データの読み取り、バッファリング、書き込みの順番で何も起こりません。