From: Jens Axboe <axboe@kernel.dk>
To: Danny Kukawka <dkukawka@suse.de>
Cc: fio@vger.kernel.org
Subject: Re: fio problems
Date: Thu, 05 Apr 2012 09:41:33 -0600 [thread overview]
Message-ID: <4F7DBD2D.4020602@kernel.dk> (raw)
In-Reply-To: <4F7DBA89.7080609@suse.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2012-04-05 09:30, Danny Kukawka wrote:
>>> 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.
Excellent, so it was down to reading un-written data. Thanks for
confirming.
- --
Jens Axboe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJPfb0qAAoJEPfTWPspceCmzawP/RLbtj62iOVuFJm5rK42Mmq0
Texy8U9RJz4D4h5oc9xAQkvlavBGPWnf0WgsnbkSr7tc/STtqVg5GW6Y8ybvfAkw
2OlZt5T/vb23uz8L9OKp+HCjV6p6Mq7lbksAcddeZdPp9GyzE+v/Cby7LMjIRgjd
OPtq759KCb/fr2gWYpxJyyyZlXost1RrRnE+OsnKhThqIYFg42G4IpdmaZGbLeTi
3EeXTNE5RDSplnuu1BsE9jffaTZuTbjm4HbCiMyixXEtp/dZBrS4tlmClC7bpjdt
SQMp68wBvji26f7K91JcjENvagGBEmi6SRJxCUgNmmZhKr3Kaf39JzbN9zEPIHOp
zOlWomS0D9Qpj0Sh24x81nlQXbWDP0aLmrggH6w5rlqLGl3pq1kz3Wgn+RkwcObw
ri8JYy8aVqT5YCVNIriIW5rQCg7kmJp170ZH6YaPd7+SeiifX8ICWFplbKHjF5Vs
vnnysT9gYEH0PLqpcoVHaYV2SFKEWVtHo7yvpqsyVevdP6uwFFXg83pAERDPsxcc
ro2VOhdJON+AhcgdgUmyfWxfcbDQnpyuw5v3/lMc2LB1oqgfKjXgW6CxqOh+tPmX
IUrpomRX+6B4WxPBxCm1Ivpr7Vja9DdFspKBZhRH4i7LErwWKTVMBKv6CaS+zxZn
bK8sy3IbjEeGP+Mv+aHs
=RYtK
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-04-05 15:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-04 6:39 fio problems Danny Kukawka
2012-04-04 19:50 ` Jens Axboe
2012-04-04 20:15 ` Jens Axboe
2012-04-05 9:24 ` Danny Kukawka
2012-04-05 14:45 ` Jens Axboe
2012-04-05 8:51 ` Danny Kukawka
2012-04-05 14:42 ` Jens Axboe
2012-04-05 15:30 ` Danny Kukawka
2012-04-05 15:41 ` Jens Axboe [this message]
2012-04-05 18:29 ` Usage of group reporting Lucian Grijincu
2012-04-05 22:01 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F7DBD2D.4020602@kernel.dk \
--to=axboe@kernel.dk \
--cc=dkukawka@suse.de \
--cc=fio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.