ドライブにランダムデータを入力するときに、GNUがddよりも速くシュレッドされるのはなぜですか？
廃止する前にハードドライブを安全に消去していると、dd if=/dev/urandom of=/dev/sdaはほぼ丸一日かかるのに対し、shred -vf -n 1 /dev/sdaは同じコンピューターと同じドライブで数時間しかかからないことに気づきました。
これはどのように可能ですか？ボトルネックは/dev/urandomの限られた出力だと思います。シュレッドは、ランダム性が低く、urandomよりも単一の目的（つまり、より効率的）にのみ十分な疑似ランダム性ジェネレーターを使用しますか？
シュレッド 内部疑似乱数ジェネレーターを使用
デフォルトでは、これらのコマンドは、少量のエントロピーによって初期化された内部疑似ランダムジェネレーターを使用しますが、-random-source = fileオプションを使用して外部ソースを使用するように指示できます。ファイルに十分なバイトが含まれていない場合、エラーが報告されます。
たとえば、デバイスファイル/ dev/urandomをランダムデータのソースとして使用できます。通常、このデバイスは、デバイスドライバーやその他のソースからエントロピープールに環境ノイズを収集し、プールを使用してランダムビットを生成します。プールのデータが不足している場合、デバイスは内部プールを再利用して、暗号的に安全な疑似乱数ジェネレーターを使用して、より多くのビットを生成します。ただし、このデバイスはバルクランダムデータ生成用に設計されておらず、は比較的遅いことに注意してください。
以前の内容を隠すのに、ランダムデータが シングルパス の ゼロ （または他のバイト値）よりも効果的であると私は確信していません。
ドライブを確実に廃止するために、私は大きな磁石と大きなハンマーを使用します。
ddが小さなチャンクを使用してデータを書き込むことが原因だと思います。 dd if=... of=... bs=(1<<20)を試して、パフォーマンスが向上するかどうかを確認してください。