私のターゲットデバイスは4096bsハードドライブです。キャッシュを迂回し、ストレージに直接またはできるだけ早く書きたいです。速度は私の最大の関心事ではありません。 30時間は多すぎますが、4時間と7時間の違いは無視できます。
私の理解（100％正確ではないかもしれません）：
conv=fsync呼び出しの終わりに一度だけ実行されますdd。
しかし、同期を最後まで延期したくありません。できるだけ早くデータをストレージに記録したいと思います。 2つの異なるオプションがあります：oflag=directとoflag=sync。oflag=sync（1）テストすると非常に遅く、（2）まだメモリキャッシュを使用しているので気に入らないbs=4096。これは不要だと思います。
oflag=directカーネルのページキャッシュ（メモリキャッシュ）をバイパスし、ストレージに直接書き込みます。ただし、ストレージ自体がHDD（後書き）キャッシュにデータを格納できるため、conv=fsyncHDDキャッシュはまだ物理ストレージに書き込む必要があります。
それで、私はこれら2つのパラメータを次のように一緒に使用するのが理想的かどうか疑問に思います。
dd if=/dev/zero of=/dev/sdX bs=4096 status=progress oflag=direct conv=fsync
ベストアンサー1
問題はスピードのようです。すでに使用しているconv=fsyncので、セキュリティや「正確さ」の問題はないと思います。ハードウェアに特定のバグがある場合を除き、バグがどのように発生したかを正確に教えてください。
パフォーマンスに関する一般的なルールは、自分の状況をテストし、小さな違いを心配しないことです。 ddスピードを教えてください。count=たとえば、400Mを使用して書き込みをテストできますbs=4k count=100k。
比較的簡単なケースについて質問しています。 /dev/zeroデバイスよりもはるかに高速なので、読み取りパフォーマンスは無視されます。
を使用すると、oflag=sync各データブロックがコミットされた後にすべての一時キャッシュがクリアされるのを待ち、常にデータ転送を維持するという利点を失います。したがって、最高の速度を得るには、より大きなブロックサイズを指定する必要があります（例：bs=16M。
原則として、デバイスは一度に最大2つの要求を処理し、処理する要求が常に少なくとも1つ以上あるようにします。特にメカニカルドライブでは、フィードが乾くように放置すると、次の要求が正しい位置に書き込まれる前に完全に回転するまで待つ必要があります。 ddこれを保証するために、それ自体は何もしません。カーネルまたはデバイスの後書きキャッシュに依存します。
oflag=direct便利な中間オプションです。カーネルキャッシュの問題がある場合（以下を参照）、これはキャッシュをバイパスするのに最適な方法です。多くのデバイスには独自の後書きキャッシュが含まれているため、oflag=direct同じブロックサイズのデバイスよりも高速です。oflag=sync
カーネルキャッシュは、IOアクセス速度を遅くすることなく正常に動作するように設計されています。その他機器。たとえば、同時に使用するシステムドライブ:-)。しかし、この問題は時々起こり、人々はこれについて不平を言います。したがって、これらの問題を予想するか心配しているかによって異なります。 :-).
両方のオプションを試すには、を指定しますoflag=direct,sync。
そうでなくても、oflag=syncブロックサイズをさらに数回増やすと、CPU使用率が低下する可能性があります。たとえば、bs=16kまたはbs=1M。しかし、bs=4k/はbs=4096すでにかなり素晴らしいです。古代のデフォルトよりはるかに優れていますbs=512。