bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9734: [solaris] `dd if=/dev/urandom of=file bs=1024k count=1' gets a


From: Eric Blake
Subject: bug#9734: [solaris] `dd if=/dev/urandom of=file bs=1024k count=1' gets a file of 133120 bytes
Date: Wed, 12 Oct 2011 08:14:15 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15

tag 9734 notabug
thanks

On 10/12/2011 02:22 AM, Clark J. Wang wrote:
I'm not sure if it's a bug but it's not reasonable to me. On Solaris 11
(SunOS 5.11 snv_174, i86pc):

$ uname -a
SunOS sollab-242.cn.oracle.com 5.11 snv_174 i86pc i386 i86pc
$ pkg list gnu-coreutils
NAME (PUBLISHER)                                  VERSION
IFO
file/gnu-coreutils                                8.5-0.174.0.0.0.0.504
i--
$ /usr/gnu/bin/dd if=/dev/urandom of=file bs=1024k count=1
0+1 records in

Notice that this means you read a partial record - read() tried to read 1024k bytes, but the read ended short at only 133120 bytes.

0+1 records out

And because you didn't request dd to group multiple short reads before doing a full write, you got a single (short) record written.

I'm new to Solaris but I've never seen this problem whe I use Linux so it
really suprises me.

Solaris and Linux kernels differ on when you will get short reads, and magic files like /dev/urandom are more likely to display the issue than regular files. That said, Linux also has the "problem" of short reads; it's especially noticeable when passing the output of dd to a pipe.

You probably wanted to use this GNU extension:

dd if=/dev/urandom of=file bs=1024k count=1 iconv=fullblock

where the iconv flag requests that dd pile together multiple read()s until it has a full block, so that you no longer have a partial block output.


I found this in the man page of /dev/urandom on Solaris: "The limitation per
read for /dev/random is 1040 bytes. The limit for /dev/urandom is (128 *
1040 = 133120)." That seems to be the reason but I think dd should handle
that and check the return value of the read() system call and make sure
1024k bytes have really been read from /dev/urandom.

Only if the iconv=fullblock flag is specified, since it is a violation of POSIX to do more than one read() without an explicit flag requesting multiple reads per block.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]