I'm writing some images back to block devices, with dd, and getting very strange output I've never seen before.# xz -dc goren.img.xz | dd bs=1M of=/dev/storage2/goren35+2475166 records in35+2475166 records out21474836480 bytes (21 GB) copied, 222.912 s, 96.3 MB/s# xz -dc gronn.img.xz | dd bs=1M of=/dev/storage2/gronn50+2413782 records in50+2413782 records out21474836480 bytes (21 GB) copied, 233.478 s, 92.0 MB/s# xz -dc grummle.img.xz | dd bs=1M of=/dev/storage2/grummle63+2443466 records in63+2443466 records out21474836480 bytes (21 GB) copied, 222.898 s, 96.3 MB/s# xz -dc hozen.img.xz | dd bs=1M of=/dev/storage2/hozen19+2556787 records in19+2556787 records out21474836480 bytes (21 GB) copied, 250.989 s, 85.6 MB/sThe output I expected to see in each case (and what I got when creating the image files) is:20480+0 records in20480+0 records outAs far as I can tell the images are being written correctly, though I am concerned with the number of records shown. This is obviously not correct in any of the cases. Though, as I said, the written images match the originals, pass filesystem checks, etc.I'm using Fedora 21 x86_64 with coreutils 8.22.
dd shows a random number of records in/out
linux;dd
Those are incomplete reads. It should go away if you add iflag=fullblock.By default, dd will happily accept smaller blocks from a pipe, if there isn't more data readily available. With the iflag, dd will wait until a full block of data has been gathered, or EOF.In regards to data consistency there should be no issue, so you should be getting correct results either way.The question is why are you using dd at all, your example can just as well be reduced to:xz -dc goren.img.xz > /dev/storage2/goren