On Mon, Jan 28, 2008 at 10:50:23PM -0700, Bob Proulx wrote:
> Michael Stone wrote:
> > Rogier Wolff wrote:
> > > dd if=somebigfile | dd count=100 of=/dev/null
> > >
> > >both dd's should report that they copied 100 records. This worked in
> > >debian sarge. Debian Etch, the first dd stopped reporting the number
> > >of records copied. The script I wrote then stopped working.
> > >(The above is an example, my script of course used something else
> > >than "dd count=100" to limit the size copied.)
> >
> > I haven't replied yet because I'm not sure what to make of it. It
> > definitely does behave this way. Anyone else know if this was an
> > intentional change or a bug? I don't see anything obvious in the
> > changelog, and my reading of posix suggests that it's a bug; am I
> > missing something?
>
> I can't reproduce this behavior. This is what I see:
>
> $ dd if=/dev/zero | dd count=100 of=/dev/null
> 100+0 records in
> 100+0 records out
> 51200 bytes (51 kB) copied, 0.00245 seconds, 20.9 MB/s
>
> $ dd --version
> dd (coreutils) 5.97
>
> $ $ uname -rm
> 2.6.18-5-amd64 x86_64
>
> $ uname -rm
> 2.6.22-3-686 i686
Yes, you /can/ reproduce the bad behaviour. Your output shows the
bad behaviour. :-)
Good behaviour:
driepoot:~> dd if=/dev/zero | dd count=100 of=/dev/null
100+0 records in
100+0 records out
51200 bytes transferred in 0.000553 seconds (92582676 bytes/sec)
129+0 records in
128+0 records out
65536 bytes transferred in 0.002203 seconds (29747044 bytes/sec)
driepoot:~> dd --version
dd (coreutils) 5.2.1
[...]
driepoot:~>
There are two "dd" processes. The second one will copy over exactly
100 blocks, and then exit. It should report 100 blocks in, 100
blocks out. This works.
The other dd has an unlimited amount of input data (/dev/zero), and
it's output pipe is closed after 100 blocks of dat is consumed. The
"pipe" can hold a little more data, so actually it will have read
and subsequently written more than 100 blocks (in my case 128).
So, when 100 blocks were written and consumed by the other side of
the pipe, 28 more blocks were in the pipe, when the system noticed
that the other side of the pipe was closed, and returned EPIPE
to the first dd.
Let me reiterate: It is the first "dd" that is misbehaving, when it
recieves a write error and SIGPIPE, it simply exits instead of
reporting the stats.
using strace on the first dd shows (good behaviour on an older
system!):
[...]
read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = -1
EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
close(0) = 0
close(1) = 0
write(2, "101+0 records in\n", 17101+0 records in
) = 17
write(2, "100+0 records out\n", 18100+0 records out
) = 18
gettimeofday({1201594453, 321231}, NULL) = 0
write(2, "51200 bytes transferred in 0.025"..., 6451200 bytes transferred in
0.025491 seconds (2008543 bytes/sec)
) = 64
gettid() = 13885
tgkill(13885, 13885, SIGPIPE) = 0
sigreturn() = ? (mask now [])
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
driepoot:~>
or (bad behaviour at an upgraded system):
[...]
read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = -1
EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
Process 11355 detached
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
