From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: David Rees <drees76@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: raind-1 resync speed slow down to 50% by the time it finishes
Date: Wed, 5 Aug 2009 10:08:36 +0200 [thread overview]
Message-ID: <20090805080836.GC23696@rap.rap.dk> (raw)
In-Reply-To: <4A78C1AE.9040002@anonymous.org.uk>
On Wed, Aug 05, 2009 at 12:18:06AM +0100, John Robinson wrote:
> On 04/08/2009 23:21, David Rees wrote:
> [...]
>> As I mentioned earlier, I was having a hard time visualizing the data
>> layout. So here's a simple diagram that shows near/far layout and why
>> Keld was right - with a far layout, reads can be isolated to the fast
>> half of the disk.
> [...]
>> Near layout, 4 disks, 2 copies:
>> a b c d
>> 0 0 1 1
>> 2 2 3 3
>> 4 4 5 5
>> 6 6 7 7
>>
>> Far layout, 4 disks, 2 copies
>> a b c d
>> 0 1 2 3
>> 4 5 6 7
>> 7 0 1 2
>> 3 4 5 6
>
> But I don't think I'd want reads isolated to the first half of the disc.
> If I wanted a block read, and the drive which has its near copy is
> already busy, but the drive with the far copy is idle, I'd probably
> rather the read came from the far copy, than wait for the drive with the
> near copy to come free.
>
> For example, say I want block 0, and there's a write pending for block
> 3. I want block 0 from drive b now, not drive a later.
That is not how IO works for disks. There is a queue for each physical
disk, and your reads are put into that queue. An elevator algorithm then
orders the requests in the queue, normally by taking the requests in the
sequence of their sector numbers. In this way the head movement is
minimized and thus speeding up total transfers by a factor of maybe 4.
So there is not something about getting IO "now", you are always in a
queue, at least on a system with some load. Systems without loads are
probably not interesting, then you get your data immediately.
> Or will I actually get more IOPS by waiting, if I'm doing a lot of small
> reads and writes?
Yes, you get many times more IOPS by having an elavator algorithm in
place, also with small reads and writes. Confining the reads to only to
the faster half gets you even more speed improvements, also for IOPS.
Maybe not that much, like a little more than half of the total head
movement from start to end per queue run of the elevator, maybe about 5 %
best regards
keld
next prev parent reply other threads:[~2009-08-05 8:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 6:25 raind-1 resync speed slow down to 50% by the time it finishes Tirumala Reddy Marri
2009-07-30 7:35 ` Robin Hill
2009-07-30 10:18 ` Keld Jørn Simonsen
2009-07-30 20:11 ` David Rees
2009-07-31 17:54 ` Keld Jørn Simonsen
2009-07-31 18:10 ` Keld Jørn Simonsen
2009-07-31 20:10 ` David Rees
2009-08-01 13:00 ` Keld Jørn Simonsen
2009-08-01 15:13 ` David Rees
2009-08-01 17:57 ` Keld Jørn Simonsen
2009-08-04 22:21 ` David Rees
2009-08-04 23:18 ` John Robinson
2009-08-04 23:42 ` David Rees
2009-08-05 8:20 ` Keld Jørn Simonsen
2009-08-05 8:08 ` Keld Jørn Simonsen [this message]
2009-08-05 7:44 ` Keld Jørn Simonsen
2009-08-05 8:18 ` NeilBrown
2009-07-30 8:44 ` Mikael Abrahamsson
2009-07-30 18:35 ` Tracy Reed
2009-07-30 20:28 ` David Rees
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=20090805080836.GC23696@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=drees76@gmail.com \
--cc=john.robinson@anonymous.org.uk \
--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).