ブロックデバイスにいくつかの画像を書き換えていますが、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