GNU bug report logs -
#13135
Loss of data while copying
Previous Next
Reported by: xojoc <at> gmx.com
Date: Mon, 10 Dec 2012 15:00:02 UTC
Severity: normal
Tags: notabug
Done: Eric Blake <eblake <at> redhat.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 10 Dec 2012 08:09:44 -0700
with message-id <50C5FB38.6040209 <at> redhat.com>
and subject line Re: bug#13135: Loss of data while copying
has caused the debbugs.gnu.org bug report #13135,
regarding Loss of data while copying
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
13135: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13135
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
9924+76 records in
1951183+1 records out
*999005921* bytes (999 MB) copied, 21.6135 s, 46.2 MB/s
bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
9887+113 records in
1950792+1 records out
*998805894* bytes (999 MB) copied, 21.3409 s, 46.8 MB/s
bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
9890+110 records in
1950792+1 records out
*998805919* bytes (999 MB) copied, 21.5801 s, 46.3 MB/s
bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
9884+116 records in
1950011+1 records out
*998405915* bytes (998 MB) copied, 25.2695 s, 39.5 MB/s
WTF?!
Best regards,
Cojocaru Alexandru
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
tag 13135 notabug
thanks
On 12/10/2012 07:58 AM, Cojocaru Alexandru wrote:
> bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
> 9924+76 records in
Thanks for the report. Based on this output, short reads occurred. dd
transferred exactly 10000 reads as requested, but since some of those
were short, it transferred less than 10000*100001 bytes. This is
expected (and the behavior is described in that way by POSIX); the
solution you are looking for is to _also_ use the iconv=fullblock
option, to force dd to re-read until it has a full input block rather
than immediately transferring short input reads to output.
As such, I'm closing this as not a bug. Do feel free to add further
comments to this thread, though, if you have more questions about why dd
does this.
Oh, and by the way, 'echo -n' is not portable. You want to use
printf(1) instead.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 12 years and 160 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.