dd if = / dev / xvdb of = / dev / null bs = 1M count = 1000 1048576000バイト（1.0 GB）コピー、1.229269秒、811 MB /秒 dd if = / dev / zero of = / dev / xvdb bs = 1k count = 1000 10240000バイト（10 MB）コピー、24.3481秒、421 kB /秒
がっかりする数字ですよね？ さらに、実験を繰り返すと、読み取り速度が低下し、書き込み速度が必要な60〜150Mb / sに増加します。
この理由は、Xen Cloud Platform上のblktapによって提供されるブロックデバイスのコピーオンライト動作モードです。
仮想マシンのディスク領域は完全に予約されていますが、ブロックへの最初の書き込みまで、そこから読み取るものはありません。代わりに、「インターフェース速度」のゼロが返されます。 そして、最初の記録では、ブロックは使用済みとしてマークされ、その全体が記録されます（1kが書き込まれた場合でも）。 ブロックは大きく、最大4Mであるため、キロバイトの記録では4MBの記録になります。 これにより、最初の録音中に特徴的なスローダウンが発生します。 変更されたデータのみを書き込む後続の試行-これは数桁速くなります。
ちなみに、mkfsが必要以上に長く続くのはこのためです-iノードとスーパーブロックが初めてディスクに書き込まれるとき、かなりのブロックがディスクに書き込まれます（記録されたデータの実際の量よりも多い）。
なぜこれが必要なのですか？
2つの理由があります。まず、顧客用の場所をストレージに割り当て、以前に別のクライアントのドライブがこの場所にあった場合、新しい所有者はドライブの内容を読むことができますか？ 答えは「いいえ」です。最初の録音の前に「空」があり（読み取る場所がない）、最初の録音ではブロックが全体として上書きされるためです。 したがって、この機能は、リモートディスク上のデータを第三者によるアクセスから確実に保護します。
第二に、一部のクライアントは大きなディスクを作成および削除します。 なぜこのためのフックでテラバイトを書くのですか？
どうする
最初の記録後、速度は正規化されるため、ほとんどの場合、特別な措置を講じる必要はありません。 大きな「漏れやすい」ファイル（ランダム）へのランダムアクセスのパフォーマンスに懸念がある場合は、ddで書き換えるとパフォーマンスを正規化できます。
オフトピック
ちなみに、この機会に、本当にプログラマが必要だということをお伝えしたいと思います。 この仕事のために人を見つけることができるかどうかは、新機能がどれだけ早く現れるかに依存します。