Re: [BUG] fill_random_bytes broken

On Thu, Jul 26 2007, Shawn Lewis wrote:
> On 7/26/07, Jens Axboe <jens.axboe_at_oracle.com> wrote:
>>
>> On Thu, Jul 26 2007, Jens Axboe wrote:
>> > On Wed, Jul 25 2007, Shawn Lewis wrote:
>> > > verify.c: fill_random_bytes() doesn't work as intended.
>> > >
>> > > drand48 on linux returns a double whose value is evenly distributed
>> between
>> > > 0.0 and 0.1. This is not the same as having an 8-byte value where each
>> bit
>> > > has the same chance of being 0 as it does of being 1.
>> > >
>> > > I'd fix this but it should probably be done in a cross-platformish way
>> and
>> > > I'm not quite sure how to do it. Maybe just use smaller randoms? Have
>> an
>> > > os_random_uint32?
>> >
>> > Hmm indeed, that looks problematic. If you have a suggested fix, fire
>> > away :-)
>>
>> OK, I just got rid of os_random_double() and used os_random_long() for
>> the verify stuff. It looks like it's working fine, can you confirm?
>
>
> Hmm, almost ok. But os/os-linux.h is broken also. lrand48 returns a
> non-negative long, so the high bit is never touched. How about using
> mrand48, patch upcoming :)

Irk, the pain...

Regarding the *rand48() usage for verify buffers, I gather you had
pattern fill plans in that area. I think we should default to using a
range of patterns, the current fully random buffers are really slow to
generate. If I test it here on my notebook using a null io engine, it
can fill and sum only about ~60MiB/sec. Replacing it with a memset()
with 0x5a, I get ~220MiB/sec throughput.

It'd probably be better to do repeated loops using fixed patterns, also
allowing you to detect certain types of corruption. I'm much looking
forward to your patches in this area! Being able to write blocks of eg
64k but have sums at 512b granularity would be awesome as well. I'm
tempted to just add that, but the wise thing todo is probably to just
wait for you to post your stuff. No point in reinventing the same code.
IOW, please post it :-)

Bonus points for including an example job file that one would use for
this type of testing. The examples/ directory has a very weak selection
of good job files, it could really benefit from actual useful job files.

I added crc16 and crc7 functions today as well, mainly for testing
purposes.

-- 
Jens Axboe