linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lutz Vieweg <lvml@5t9.de>
To: linux-raid@vger.kernel.org
Subject: SSDs vs. md/sync_speed_(min|max)
Date: Mon, 18 Jul 2011 20:42:04 +0200	[thread overview]
Message-ID: <j01ups$vbc$1@dough.gmane.org> (raw)

Hi,

just wanted to report some unexpected effects of the md/sync_speed_(min|max)
parameters when using MD RAID1 on SSDs:

While syncing from one SSD to another in a MD RAID1 (that was in use at that
time, but still had plenty of spare I/O bandwidth to spend),  I wanted to
increase the speed of that process. But md/sync_speed_max was already much
higher (200 MB/s) than the actual sync speed that MD reported (~ 30MB/s).
At the same time, the utilization of the SSD to read from was only at ~5 %.

So I wondered what was keeping MD from just reading faster.

I can only assume that MD is tuned for magnetic disks in that it assumes any
additional "reads" to some location on the source device will be pretty expensive,
so it is cautious about causing them.
But for SSDs, there's no extra cost for "seeking", so it would be perfectly fine
if the utilization of the source-device was e.g. 95% while synchronizing.

And with SSDs, reading tends to incur less "utilization" (as reported
by e.g. "iostat -dx 3") than writing - even if sequential reads/writes
appear to reach similar speeds.

I could help myself by setting md/sync_speed_min to 200 MB/s. That accelerated
the sync a lot while the source device still remained usable by others (~30%
utilization).


I would like to propose that if my assumption about the tuning for the penalty
of seeking on magnetic disks is right, implementation of some "SSD"-flag could
be a good idea to tune the algorithm otherwise.

Regards,

Lutz Vieweg



                 reply	other threads:[~2011-07-18 18:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='j01ups$vbc$1@dough.gmane.org' \
    --to=lvml@5t9.de \
    --cc=linux-raid@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 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).