Re: fio problems

[Danny Kukawka <dkukawka@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Am 05.04.2012 16:42, schrieb Jens Axboe:
> On 2012-04-05 02:51, Danny Kukawka wrote:
>>>> 3) fio always reports minb == maxb and aggrb < minb as you can see
>>>> above. From my understanding this would be false info.
>>>
>>> Yeah, it's a cosmetic thing. I've never really taken the time to look at
>>> that...
> 
>> It's not cosmetic if you need correct values for your tests ...
> 
> Most people don't use the group reporting, but yes of course it should
> be correct. I have checked in a patch to correct it. The min/max group
> report bandwidth were off by 1.024, the aggregate was correct (and
> matched the "real" data output).
> 
>>>> 4) If we define rw=randrw, rwmixread=80, rwmixwrite=20 and the verify
>>>> options, what does the READ process if there isn't enough data written
>>>> out yet? Which data does READ read and verify?
>>>
>>> If you have a split workload like that and are also doing verifies, the
>>> read can be either a read verify or just an offset read. In the latter
>>> case, it doesn't verify anything. It'll just read a block (or multiple
>>> blocks) at some offset instead of writing it.
> 
>> That would may explain the fio over-report in 1).
> 
>> We create a new RBD on the cluster, mount it on the client and let fio
>> start it's test on the RBD. The RBD is completely empty at this moment.
>> Not sure what happens if fio reads some random offset that may isn't
>> filled with data at this moment. Or is fio only reading from a prior
>> written block/offset?
> 
> OK, if we back up a bit. If you have a workload that is rwmixread=50,
> hence doing equal amount of random reads and writes. Then the job will
> read 50% of the disk, and write 50% of the disk. None of the read and
> write offsets will be the same. So if the drive is initially empty, you
> are reading non-initialized data.
> 
> Same thing is true for your workload. So some of the reads you see will
> be the verifies, but some of them will also be for parts of the disk
> that you will then never write.

We solved it now by running an initial fio write over the full RBD
before running any verify tests:

 fio --name=fill-rbd --filename=/dev/rbd1 --direct=1 --rw=write \
     --bs=4M --size=25g --ioengine=libaio --iodepth=128

Now we don't see problems with over-reporting fio anymore.

Danny
-- 
Danny Kukawka
 SUSE LINUX Products GmbH
  Maxfeldstrasse 5, D-90409 Nuremberg, Germany
  GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]