ddは、入力/出力されたレコードのランダム数を表示します。

ddは、入力/出力されたレコードのランダム数を表示します。

ブロックデバイスにいくつかの画像を書き換えていますが、dd以前見たことのない非常に奇妙な出力が表示されます。

# xz -dc goren.img.xz | dd bs=1M of=/dev/storage2/goren
35+2475166 records in
35+2475166 records out
21474836480 bytes (21 GB) copied, 222.912 s, 96.3 MB/s
# xz -dc gronn.img.xz | dd bs=1M of=/dev/storage2/gronn
50+2413782 records in
50+2413782 records out
21474836480 bytes (21 GB) copied, 233.478 s, 92.0 MB/s
# xz -dc grummle.img.xz | dd bs=1M of=/dev/storage2/grummle
63+2443466 records in
63+2443466 records out
21474836480 bytes (21 GB) copied, 222.898 s, 96.3 MB/s
# xz -dc hozen.img.xz | dd bs=1M of=/dev/storage2/hozen
19+2556787 records in
19+2556787 records out
21474836480 bytes (21 GB) copied, 250.989 s, 85.6 MB/s

それぞれの場合に表示されると予想される出力(および画像ファイルを生成したときに得られる出力)は次のとおりです。

20480+0 records in
20480+0 records out

私が知っている限り、表示されるレコードの数が心配ですが、画像が正しく作成されました。これはどんな状況でも明らかに正しくありません。しかし、私が言ったように、作成された画像は元の画像と一致し、ファイルシステムのチェックなどを通過します。

私はFedora 21 x86_64とcoreutils 8.22を使用しています。

ベストアンサー1

これは不完全な読み取りです。 。を追加するとiflag=fullblock消えます。

デフォルトでは、ddデータが利用できなくなると、パイプラインのより小さなチャンクが許可されます。 iflagを使用すると、ddデータブロック全体が収集またはEOFされるまで待ちます。

データの一貫性については問題がないはずなので、どちらも正しい結果を得る必要があります。

問題はを使用する理由ですdd。例を次のように単純化することもできます。

xz -dc goren.img.xz > /dev/storage2/goren

おすすめ記事