Poor raid 1 performance?

Change odd and even sectors in odd and even strip(e)s and your story starts
to make some sense. Unfortunately strip(e)s are a hindrance in RAID1,
e.g. if a file is in 3 strips it is read in 3 chunks when it could have
been read faster in 2 (1+ strip by one drive, 1+ strip by the other).

"Antoine Leca" wrote in message
In , Bob Willard va escriu
Antoine Leca wrote:

But while considering only 256 sectors, you did not answer.
Will an actual drive deliver the same throughput when you ask it to
read 256 continuous sectors, as when you ask it to read all
even-numbered sectors from 100,000 to 100,510 (count is 256 too)?

I don't know of any HDs that support a command to read every other
sector.

Neither do I. But I believe (could be wrong) there is the possibility to
send "some" commands to be "queued" (not sure that is the correct term),
that is, without waiting for the precedent to be completed.
With that feature, one can send various otherwise independent commands in a
row, for example, 256 commands to read one sector each (the even-numbered
ones). As a result, you are asking the drive to read all even-numbered
sectors from 100,000 to 100,510.


Even if a hypothetical HD could be told to read every other sector,
it would read from the platter at half-speed, since it takes just as
much time to skip a sector as to read it.

That is what I thought too, and it seems we all agree at this point.


It seemed to me that a sequencial read (issued by the OS as various I/O
commands) from a RAID-1 array will be seen by one drive inside the array
just this way, as a successiveness queue of commands to read the
even-numbered sectors.

(And please do not tell me it is silly to cut into such small units as
sectors, and that it would be much more efficient to use bigger "block": it
was my point initially behind the word "stripe", admittedly misused here;
but it appeared it was misunderstood so I needed to simplify the scheme.
Vocabulary is a big problem for beginners.)


Now, if the OS is not stupid/silly, it will group the read commands into a
_unique_ one, for 512 sectors here (and the RAID controller can do it also,
just in case); and then the controller will only issue one command to the
drive, for half the sectors (one drive will provide sectors 100,000 to
100,255; and the second 100,256 to 100,511).

*Maybe* this was the point that Folkert was trying to make "initially"
freenews.net), when he
said I was too much focused ("fascinated") on hardware and I were missing
the overall picture, "IO-commands".

Could very well have been so, as seen when I re-read the thread (for
example, what Folkert said to Gerhard Fiedler in
reenews.net: I understand
it is almost exactly what I wrote just above.)


{Not true if the read is satisfied from the HD's cache, of course.
In that case, the answer would be "implementation-dependent".}

Of course. Which is why I tried to avoid this effect by referring to the
vagueness of "long" reads, thinking it will be clear.


Antoine

"Antoine Leca" wrote in message
In reenews.net, Folkert Rienstra va escriu
The second drive also transfers in bursts.
The second drive bursts in between the first drive's bursts.

I do not see why there would be a need for such temporal dichotomy,
assuming of course that both drives are not together on the same
physical link.

IDE is a 2 device bus interface.

For my enlightment, how common are RAID controllers using (paired) IDE
devices?

Very.
There are more expensive ones that have restricted themselfs to using
only 1 device per channel and they come with single device cables only.
Instead of 2 channels they come with 4 or even 8.


I learned reading
http://www.storagereview.com/guide20...lMultiple.html,
but it seems a bit old (2000?), particularly when it comes to disk interfaces.

In a nutshell that says: ATA can't multitask so lets rant about SCSI.
Not very useful.


Where can I find present-day informations?

Nothing much changed except maybe Overlapped and Queued feature set
which should bring ATA upto speed with SCSI but that never caught on.

IDE (I prefer to speak of IDE here, because ATA actually can)
cannot start simultanious reads from 2 devices on the same channel or start
a read and write simultaniously unless the write goes before the read.

What this boils down to is that you can't in some circumstances average your
access times (no parallel seeks) and can't use the full bandwidth of the channel
(empty bursts) so that your accesses appear simultanious (parallel), instead they
are serial (one access after the other) and you get only half the thruput per drive.

This isn't so much of a problem for long sequential reads (to start with: no seeks)
and no real need to start commands simultaniously(*) because when one drive reads
the other caches ahead and buffers, the whole transfer is at 100% interface speed
from buffer when the command that requests that data comes. So it looses half
by being serial but gains 100% by being able to use the full bandwidth for itself.
(*) Only the first commands are in serial, every next one is virtually parallel as
long as the read commands are sequencial.



For example, I imagine both are connected using SATA to different
channels.

Yes, I made a comment about that later, but as usual you snipped that
again.

About "single channel" vs. "separate channel", right?

Yes, and how they appear on the PCI bus.

I am sorry, I did not (then) match the terminology, now I did better (read
the above article, for once.)


OTOH, if you are considering SCSI-linked drives, I could see your
point.

No difference if you use dual channel SCSI.

I was assuming this would allow two transfers to occur simultaneously,
wouldn't it?

And this question is about IDE or SCSI or both?
Or dual channel SCSI only?


Thanks for your explanations, and your patience. As you can read in the
other post, I perhaps finally understood your point.

Perhaps.



Antoine

In reenews.net,
Folkert Rienstra va escriu
Where can I find present-day informations?

Nothing much changed except [...]

Thanks for your feedback (I snipped for the post, but I am actually
digesting it, seems much worth reading).


Antoine