Archived from groups: comp.sys.ibm.pc.hardware.storage (
More info?)
On Thu, 15 Jul 2004 19:12:20 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:
>"Marc de Vries" <marcdevries@geen.spam.zonnet.nl> wrote in message news:gp7cf0dd6qjbbr1c0tuem00u21mvjhe7n2@4ax.com
>> On Wed, 14 Jul 2004 20:15:57 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>> > "Marc de Vries" <marcdevries@geen.spam.zonnet.nl> wrote in message news:4tj9f0looo37ameke4kvof9behakeb44ll@4ax.com...
>> > > On Tue, 13 Jul 2004 21:47:44 -0600, Eli <nobody@anywhere.com> wrote:
>> > >
>[snip]
>> > >
>> > > PATA and SATA controllers don't have this issue since you have a
>> > > dedicated ide channel for every disk.
>> >
>> > Not with PATA.
>> > It is still *your* choice to not use a second drive on same channel.
>>
>> I have never seen a PATA Raid5 controller where each drive didn't have
>> a dedicated ide channel.
>
>Which obviously is entirely firmware limited unless the IDE chip used is
>selfdesigned and doesn't support M/S.
Sure, but that doesn't matter. When the firmware in the Raid5 cards
don't give you that option, you have little choice but to accept that.
Adding a second drive will simple not work. So it's NOT your choice to
use a second drive on the same channel with Raid5 cards.
>> But you are right in the case of some Raid 0/1/10 controllers where
>> you can have two drives connected on a ide channel, although you then
>> loose the hotplug capability of those cards.
>
>What has that got to do with hotplugging?
Because You can't hotplug with two devices connected on IDE.
Actually hotplugging is not supported at all on IDE, but as long as
there is only one device present some companies can work around that
limitation.
>> > > Multiple spindles increase the performance of the array for two main
>> > > reasons:
>> > > 1) the sequeantial transfer rate increases with more spindles.
>> >
>> > That is for striped arrays.
>>
>> Raid5 is also a form of stiping, so it also applies here.
>
>Yes, and where did I say different?
You are responding to my statement. Now I have to assume that you
wanted to make a point with that reply. Aparantly I was wrong in
assuming that.
Your remark suggests that there was something wrong to what I said.
(especially when someone who doesn't know how raid works reads it). So
I had to make it clear for everyone that it does apply to Raid5.
>That is why I said "That is for striped arrays" and not "Raid0".
>Get it now?
I get it that you are making pointless remarks that have absolutely
nothing to do with the thread.
If you had said that the transfer rate increase doesn't apply to Raid1
you would have added something sensible. Although it still doesn't
apply to what we are talking about here: Raid5.
>> > > Might be usefull in some rare situations were you really need that. But
>> > > in those situations you will probably already saturate the pci bus with
>> > > 6 drives and won't gain anything more with 12 drives. (creating two ar-
>> > > rays also won't help then, because the pci bus is then the limiting factor
>> > >
>> > > 2) average seektimes decrease with more spindles.
>> >
>> > That is for mirrored arrays.
>>
>> Wrong. It applies to all forms of Raid. Although it also depends on
>> the implementation. Very old and/or cheap arrays didn't support this
>> in the past, not even in mirrors. But nowadays almost any controller
>> supports it.
>
>Supports what? What is "it"?
Support the necessary functions to make this work. For instance in a
Raid1 array the function that makes it possible to read a file from
disk2 while another file is being read from disk1. But there is no
need to dive into details here.
I've explained it to you in the past, but you didn't listen then, so I
will not explain it to you again.
A more detailed explanation than I have already given in the thread
here isn't interesting for the discussion. Although I might give it if
the op asks for it.
>> > > The reason for this is that while part of the array is retrieving a file,
>> > > other parts of the array that don't contain the data for that file can
>> > > retrieve another file at the same time.
>> >
>> > So that's not really seek time. Just another way of how transfer rate increases.
>>
>> No. It has nothing at all to do with transfer rate. I can retrieve
>> multiple small files simultaneously, but since the files are small it
>> is not something that is determined by transfer rate, so not something
>> for which I need the bigger transfersrates of Raid arrays. I won't
>> even exceed the transferrate of a single disk with those files.
>
>> But the perceived
>
>Right, "perceived".
>
>> seek time of the array will be smaller than the minimum seek time of
>> a single disk. So it is exactly as I said:
>
>> the average seektime of the entire array decrease with more spindles.
>
>Which obviously is false when it is "perceived" like that.
>Perceived, as the word means, is a false assumption.
Pffff. You obviously have no idea what you are talking about.
The seektime for reading a single file from the array stays the same
as on a single disk. But total time spend on seeks when you read many
files on the array is must lower then when you read many files on a
single disk.
I've explained in simple terms how that works. In my opinion perceived
seektime is a good way to talk about this lower total seektime. But if
you know a better word I welcome you to tell me what word I should
use.
The facts are that the total seektime is reduced so I have a
performance gain. So there are no false assumptions.
>If transfer rate exists of STR divided by (seektime and actual
>transfer time) per time unit and you then increase the STR you could
>also say that that is perceived as if the seektime was decreased com-
>pared to the old STR just because the total transfer time decreased.
>It's not so.
If you don't know how raid arrays work, you could make that
conclusion, but you would be completely wrong and you would be saying
something completely different from what I am saying.
>> Of course this only works if you open more then one file.
>
>Thanks for confirming that this is
>"Just another way of how transfer rate increases".
Wrong again. You just don't get it.
When I open small files the total time to read the file is determined
for 90% by the seektime. Increasing the transferrates can therefore
never give a large performance gain.
But because you can read multiple files at the same time you are
effectively reducing the seektime and are creating a huge performance
gain.
Again a simple example. I can read two small files at once from the
array.
90% of the time T to read that small file is spend on the seektime.
Now I read two of those files from a single disk.
The total time spend is: 2T
2 x (0,9 x T + 0,1 x T)
Now I quadrouble the transferrate of that disk by putting them in a
raid array. Now for 10% of time T I need only a quarter of the time.
Now the total time needed is 2 x (0.9 x T + 0.025 x T) = 1.85 T
So although I made a huge transferrate increase I got only a very
small performance gain.
Now I don't do anything about the transferrate of the disk when I put
it in a raid array. I just read both files at the same time, as I can
do with larger arrays. (or with a raid1 array)
Now the total time to read both files is:
1 x (0,9 x T + 0,1 x T) = 1T
Now I have made a 100% performance gain and it is not because of the
transferrate. We all know (or should know) that seektime is the
limiting factor when you are reading small files.
So we have a huge performance gain. It is the sort of performance gain
we would get when we halve the seektime.
It's not an actual seektime decrease, but real-life performance
figures of the array make it look like the seektime has been halved.
So the array behaves as if the seektime has halved, and thus I state
that the "perceived" seektime has decreased.
>And btw, just as well you can say that when seektime (total time spent
>in seeks) decreases that that is "perceived" as increased transfer rate.
No you can't.
Simply because a perceived seektime decrease corresponds well with the
actual performance figures and an increased transferrate does not.
Even when I increase the trasnferrate a million times the minimum time
to read those files will still be 1.8T
And for large files we also know that the transferrate isn't that big.
A perceived seektime does work will with the real-life data:
For large files it has little impact and for little files it has a big
impact.
Exactly what we see on our array:
For large files the performance increase is determined by the
transferrate increase and not the perceived seektime And for small
files it's just the other way around.
>> > > When your array has more spindles the chance of this becomes bigger.
>> >
>> > > (It is of course also dependent on the size of your files, the stripesize,
>> > > and whether your server opens a lot of files, or just one at a time)
>> >
>> > So no.
>>
>> You will now understand
>
>You have no say in that whatsoever.
Yeah, I forgot that I was talking to someone who doesn't WANT to
understand.
>> that the correct answer is: So yes.
>
>So no (hint: stripesize on mirrors?).
So yes.
Hint: We are talking about Raid5 arrays and not mirrors.
My statement was about Raid5 arrays. Of course such a statement cannot
automatically be applied to all other type of arrays. I've never
stated that it could be applied to a two disk mirrorer array.
Marc
Facebook
Twitter
Instagram