Further to Richard and Malcolm's discussion:
When you set bs=XX in dd, you are actually setting in effect:
ibs (input block size)
and
obs (output block size)
Indeed, as Malcolm postulated, I did NOT specify a block size, nor did I
need to. I just wanted some random garbage, so I used simply
dd if=/dev/urandom of=myfile
Something else interesting to note is that we typically specify a block
size for the sake of reducing the number of I/O's required to do the
operation. In the case of urandom, it would likely feed me stuff at
exactly the same speed, regardless of the block size, (entropy
requirements and all that) so I did not specify it.
Had I know, for instance, that urandom could generate data at flay out
CPU speed, I *might* have then set an obs to minimise the number of
writes to the target filesystem, but again, I was not looking for that
much data... Just enough to foil ZFS's compression of nulls (and
potentially more generally compression overall.)
Enjoy!
Nathan.
On 20/03/09 12:00 PM, Malcolm Herbert wrote:
>
> On Fri, 20 Mar 2009 11:50 +1100, "Richard Smith" <Richard.Smith at Sun.COM>
> wrote:
>> Malcolm Herbert wrote:
>>> Wanting to generate some random-ish data to perform some disk io
>>> testing, in a similar vein to that which Nathan did on Wednesday.
>>> Discovered that /dev/urandom on this host seems to only allow a maximum
>>> read() of 1040 bytes per request:
>> Looks like its hardcoded via MAXRETBYTES macro:
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/random.c#61
>
> OK, that seems to be the explanation ...
>
>> In the case of /dev/urandom, since it is attempting to supply relatively
>> high-quality random
>> bits based on entropy from various sources in a system, you're like to
>> exhaust it very quickly
>> using it to fill i/o buffers. A pseudo-random number generator may be more
>> appropriate for this.
>
> sure - that was why the request was for only 1MB or so - as Nathan had,
> I was intending on duplicating that data to do the actual write tests
>
> no, the thing that had me confused was that I don't recall Nathan
> running into this issue during the talk and didn't think the command
> he'd used to generate the test data in the first place was anything
> other than the simple dd I'd given earlier, although he may have just
> used the default 512 byte blocks where I'd tried to be smart and raised
> that to 1MB ...
>
--
//////////////////////////////////////////////////////////////////
// Nathan Kroenert nathan.kroenert at sun.com //
// Senior Systems Engineer Phone: +61 3 9869 6255 //
// Global Systems Engineering Fax: +61 3 9869 6288 //
// Level 7, 476 St. Kilda Road //
// Melbourne 3004 Victoria Australia //
//////////////////////////////////////////////////////////////////
