ddが存在するドライブにddを0にするとどうなりますか？

このコマンドdd if=/dev/zero of=/dev/sda bs=1Mは、ddコマンドが最初に/ dev / sdaにあった場合に成功しますか？ddがその時点でメモリ内にあるため、これは完了しますか？

起こり得ることが3つあります。

1. コマンドが開始され、完了するまで実行され、プロンプトに戻ります。ディスクは効果的にワイプされるため、その後はあまり実行できませんが、いくつかのシェルビルトインコマンドで幸運になるかもしれません。
2. コマンドが起動します。ある時点で、メモリの圧迫によりページアウトされます。通常、これは問題ではありません。その一部は、ディスク（変更されていないデータ）から、またはスワップからリロードできるためです。ただし、これらをワイプしただけでは、ディスクがいっぱいになってもddコマンドは部分的に失敗します。
3. 3番目のオプションは、BSDからのものです。マウントされたディスク上のMBRは上書きから保護されます。rootとしてコマンドを実行しても。数十のLinuxディストリビューションがあり、すべてがわずかに異なります。それらの一部がこれをエミュレートすることは十分に可能です。

これまでのところ、理論。実用的なテストのために。

VMに新しいUbuntu 12.10をインストールしました。（デフォルトのオプションと10 GBの仮想ディスクを使用したwin7-x64上のVMwareワークステーション）。

ddコマンドは正常に完了し、正常に機能しているように見えるプロンプトに戻りました。新しいコマンドを入力することはできましたが、明らかな理由で失敗しました。

Damn Small Linuxを使用した仮想マシンでの簡単な実験は、ddコマンドが実際に期待どおりに完了したことを示しています。プログラムは最初にメモリに読み込まれて実行されますが、プロセス中に実行可能ファイルを何度も読み込むことはほとんど意味がありません。最終的に、ddは終了し、「デバイスにスペースが残っていません」と報告します。

その後、オペレーティングシステムは一見正常に機能しているように見えますが、最初のコマンドの後でハングし、明らかな理由で実行できなくなり、応答しなくなります。ハードドライブの内容を簡単に調べると、パーティションが本当にゼロになっていることがわかります。

mmapLinux のページから：

MAP_SHARED Share this mapping.  Updates to the mapping are visible to other processes that map this  file,
           and  are  carried  through  to the underlying file.  The file may not actually be updated until
           msync(2) or munmap() is called.


MAP_PRIVATE
           Create a private copy-on-write mapping.  Updates to the mapping are not visible to other  pro‐
           cesses  mapping  the  same  file,  and  are  not carried through to the underlying file.  It is
           unspecified whether changes made to the file after the mmap() call are visible  in    mapped
           region.

実行可能ファイルは、mmap関数への内部呼び出しを介してカーネルによってメモリにマップされます。MAP_PRIVATE型マッピングは、（に見える要求されたfs/binfmt_elf.cカーネルソースツリーの）。

つまりmmap、ファイルの変更、またはそのファイルが参照されている基になるブロックデバイスが、既にページインされて存在しているマッピングのページに反映されるかどうかということになります。

そのページはカーネルの動作ではなくAPI標準に基づいているため、「未指定」です。実際の動作は、ファイルへの変更が既存のページに反映されないことです。もちろん、プログラムがページインされていないコードのページに突然ジャンプし、消去が既に行われている場合は、すべてゼロのページが取得されます。

しかし、おそらく、ddそれ自体が消去されるまでに、消去ループを継続するために必要なコードのすべてのページにページングされています。ループが終了すると、存在しないページにあるコードにヒットする可能性があります。たとえば、関数がページ境界をまたいでいるため、return命令に到達するには、ページをフェッチする必要があります。

しかし、そのページは以前のdd呼び出しからもキャッシュされる可能性があります。

はい。もちろん、ファイルシステムのほとんどのコストもかかりますが、おそらくあなたはすでにそれを知っています...

最近間違えました。2 GBのimgをSDカードに書き込むつもりでしたが、誤ってsdaにしましたdd if=rasberrypi.img of=/dev/sda。私の間違いに気づき、ddをキャンセルしましたが、それまでに（600GBを使用したディスクに）600MBが書き込まれていました。パーティションテーブルが破壊されました。

何も起こらなかったかのように、デスクトップ（10 GBのメモリを搭載し、最大で数週間）は数時間機能し続けました。最近変更された重要なファイルを通常どおりChromeで参照してDropboxに取り込むことができました。実際、私はもともと望んでいたようにSDカードをDDで実行でき、問題なく動作しました。

数時間後、ファイルシステムが読み取り専用モードになり、ランダムプログラムが停止し始めました。他の多くのシステムに接続されましたが、それらのセッションを引き続き使用できましたが、新しいセッションを作成すると、sshプログラムが見つからないというエラーが発生しました。現時点では、Chromeで開いているタブを切り替えることができましたが、タブのコンテンツが「ハング」しているようです。リフレッシュすると、白い画面がずっと表示されます。何らかの理由でrsyslogdが100％cpu（1コア）を使用していました。おそらく、ログをディスクにフラッシュできなかった理由が混乱していました...たぶん。

350 MBのビデオをVLCで開いて（そして一時停止して）いたのですが、それを再生して、ビデオの任意の部分にスキップすることができました。たぶん、最近のダウンロード以来。

私は通常GUIを使用してシステムをシャットダウンできましたが、エラーはありませんでした。

したがって、これはあなたの質問に正確に答えるものではありませんが、ディスクの先頭を消去するとどうなるかを示しています。

ディスク上のほとんどのものはまだ回復可能ですが、（願わくば）私が気にするすべてのものがバックアップされているので、気になりません。

他の実行中のコンポーネントが見つからないファイルを要求し、カーネルをパニックにするため、おそらく完了しません。ディスクをゼロにしたい場合は、ライブCDを使用してください。そうしないと、結果を保証できません。