linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* SSDs vs. md/sync_speed_(min|max)
@ 2011-07-18 18:42 Lutz Vieweg
  0 siblings, 0 replies; only message in thread
From: Lutz Vieweg @ 2011-07-18 18:42 UTC (permalink / raw)
  To: linux-raid

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



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2011-07-18 18:42 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-18 18:42 SSDs vs. md/sync_speed_(min|max) Lutz Vieweg

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