linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Robinson <john.robinson@anonymous.org.uk>
To: Shaochun Wang <scwang@ios.ac.cn>
Cc: Roman Mamedov <roman@rm.pp.ru>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Write-intent bitmap decreases or increase performance of RAID5?
Date: Fri, 02 Jul 2010 12:13:19 +0100	[thread overview]
Message-ID: <4C2DC9CF.4030107@anonymous.org.uk> (raw)
In-Reply-To: <20100702024927.21c4f814@natsu>

On 01/07/2010 21:49, Roman Mamedov wrote:
> On Thu, 1 Jul 2010 14:40:44 +0800
> Shaochun Wang <scwang@ios.ac.cn> wrote:
> 
>> 	-bash-4.1$ sudo dd if=/dev/zero of=test.dd bs=1M count=5000
>> conv=fdatasync,notrunc Password:
>> 	5000+0 records in
>> 	5000+0 records out
>> 	5242880000 bytes (5.2 GB) copied, 63.497 s, 82.6 MB/s
>>
>> 	-bash-4.1$ sudo dd if=/dev/zero of=test.dd bs=1M count=5000
>> conv=fdatasync,notrunc 5000+0 records in
>> 	5000+0 records out
>> 	5242880000 bytes (5.2 GB) copied, 18.1033 s, 290 MB/s
>> 	
>> I don't know why the second dd becomes 290MB/s and the first 82.6MB/s.
> 
> That's because the first time the filesystem had to increase the file's size
> 5000 times by allocating additional 1 MB, and the second time it was just
> writing to an already allocated file. If you see such a big difference here,
> run that test 3 or more times, and discard the first run's results.

Or use a proper filesystem benchmarking tool like bonnie++ and read its 
documentation so you know what it's telling you. dd is (in my opinion) 
only really any use for testing raw device streaming write/read speed.

And no, I don't understand why you get better performance with the 
write-intent bitmap turned on, unless you said that because you saw 
something like the above (as Roman says, your initial conditions were 
different so it's not a valid comparison). Usually, you need to tweak 
the write-intent bitmap's chunk size to suit your array and desired 
recovery speed to avoid it killing performance. I use a 16MB chunk on 
arrays with a few cheap drives, others go as high as 128MB on arrays 
with lots of high-performance quality drives.

Cheers,

John.

  reply	other threads:[~2010-07-02 11:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29 20:11 Write-intent bitmap decreases or increase performance of RAID5? Shaochun Wang
2010-06-30  5:18 ` Roman Mamedov
2010-06-30  5:54   ` Mikael Abrahamsson
2010-06-30  5:59     ` Roman Mamedov
2010-06-30  6:58       ` Mikael Abrahamsson
2010-06-30  8:23         ` Roman Mamedov
2010-06-30 18:31           ` CoolCold
2010-07-05  0:11         ` Bill Davidsen
2010-07-01  6:40     ` Shaochun Wang
2010-07-01 20:30       ` Majed B.
2010-07-01 20:50         ` Roman Mamedov
2010-07-05  0:14         ` Bill Davidsen
2010-07-01 20:49       ` Roman Mamedov
2010-07-02 11:13         ` John Robinson [this message]
2010-07-05  0:17         ` Bill Davidsen

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=4C2DC9CF.4030107@anonymous.org.uk \
    --to=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=roman@rm.pp.ru \
    --cc=scwang@ios.ac.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).