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).