From: maarten van den Berg <maarten@vbvb.nl>
To: linux-raid@vger.kernel.org
Subject: Re: RAID1 VS RAID5
Date: Mon, 27 Oct 2003 12:08:04 +0100 [thread overview]
Message-ID: <200310271208.04442.maarten@vbvb.nl> (raw)
In-Reply-To: <200310270927.32751.dusty@strike.wu-wien.ac.at>
On Monday 27 October 2003 09:27, Hermann Himmelbauer wrote:
> On Sunday 26 October 2003 17:16, maarten van den Berg wrote:
> > On Sunday 26 October 2003 15:45, Mario Giammarco wrote:
> > > Hello,
> > >
> > >
> > > My problem is: I have seen that RAID1 code does not interleave reads so
> > > it does not improve performance very much putting two hard disks.
> >
> > After thinking about your question for a minute, I think I found the
> > obvious reason for that. Raid1 being a mirror set it does not make sense
> > to interleave anything. Either disk1 reads it first or disk2 reads it
> > first. Once you get the data from either disk, then you're done; no need
> > to wait for the second disk (giving you the identical datablock).
> > Interleaving only makes sense with other raid levels, but not with level
> > 1.
>
> It seems you're missing something: Interleaving means here, reading one
> part of the data from one disk and another part from the other disk, not
> reading the same data from both.
I know what interleaving means; I just think it is counterproductive in Raid1.
> When reading a file from the RAID1, you could e.g. read the first block
> from the first disk, the second from the second disk, the third from the
> first disk and so on.
The way it works now, AFAIK, is that concurrent read commands are issued to
all the drives in Raid1. Because of seek times and the amount of rotation
needed to get the right sector underneath the head(s), one of the disks will
be first to transfer the data. This can be 'sooner' by a large amount.
If you instead want to interleave reads you lose the possibility to gain speed
from this mechanism described above. It would be a trade-off and I'm not sure
interleaving would come out as the winner here. Interleaving comes from for
instance RAM access. But a RAM chip has to 'recover' from a read, i.e. it
needs a little bit of time in between each read. Interleaving there is very
sensible since you can let one bank 'rest' while the other bank 'works'.
For disks, this is not so; once the right sector is under the head the hard
work is done; reading on onto following or adjacent sectors happens at or
near the theoretical full speed. If you switch drives after 128 blocks you
slow your transfer, not speed it up. This will depend on many many factors
like how large a read it is and how scattered the data is across the platter.
But, maybe I'm way off base here and new insights have changed this. :-)
Greetings,
Maarten
> This would *theoretically* double the read speed - like with RAID0.
>
> Practically this speed doubling would not occur as you have to add the seek
> times when reading files, but I assume with TCQ and things like that there
> could be some tricks to optimize the read behavior.
>
> Anyway - it seems no RAID1 implementation - be it hardware or software
> RAID1 - seems to make use of this read performance increase.
>
> Best Regards,
> Hermann
--
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
next prev parent reply other threads:[~2003-10-27 11:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-26 14:45 RAID1 VS RAID5 Mario Giammarco
2003-10-26 16:16 ` maarten van den Berg
2003-10-26 18:22 ` Mario Giammarco
2003-10-27 8:27 ` Hermann Himmelbauer
2003-10-27 9:54 ` Lars Marowsky-Bree
2003-10-27 10:16 ` Jeff Woods
2003-10-28 10:45 ` Mario Giammarco
2003-10-27 11:08 ` maarten van den Berg [this message]
2003-10-27 12:03 ` Jeff Woods
2003-10-26 16:55 ` Matti Aarnio
2003-10-28 10:46 ` Mario Giammarco
2003-10-27 8:33 ` Hermann Himmelbauer
2003-10-27 9:19 ` Gordon Henderson
2003-10-27 11:01 ` Hermann Himmelbauer
2003-10-27 13:40 ` Gordon Henderson
2003-10-27 15:34 ` Hermann Himmelbauer
2003-10-27 14:17 ` Lars Marowsky-Bree
2003-10-27 15:52 ` Andrew Herdman
2003-10-28 10:40 ` Mario Giammarco
-- strict thread matches above, loose matches on Subject: below --
2003-10-26 11:24 Mario Giammarco
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=200310271208.04442.maarten@vbvb.nl \
--to=maarten@vbvb.nl \
--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).