RAID 5 Question
Forum Storage : General Storage - RAID 5 Question
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
"Peter Hucker" <hucker@clara.co.uk> wrote in message news
psa69qmwbaiowgp@blue
> On Thu, 15 Jul 2004 17:47:09 -0400, J. Clarke <jclarke@nospam.invalid> wrote:
> > Peter Hucker wrote:
> > > On Thu, 15 Jul 2004 13:40:09 +0200, Marc de Vries <marcdevries@geen.spam.zonnet.nl> wrote:
> > > > On Thu, 15 Jul 2004 11:35:33 +0100, "Peter Hucker" <hucker@clara.co.uk> wrote:
> > > > > On Thu, 15 Jul 2004 08:24:18 +0200, Marc de Vries <marcdevries@geen.spam.zonnet.nl> wrote:
> > > > > > On Wed, 14 Jul 2004 17:24:50 GMT, "dg" <dan_gus@hotmail.com> wrote:
> <snip>
> > > > > > Who says that he will be using 250GB disks?
> > > > > >
> > > > > > It's common practice to use small disks in arrays with many spindles
> > > > > > to increase performance of the array. For example: my servers have
> > > > > > Raid6 arrays consisting of 14 disks of 36GB each.
> > > > >
> > > > > What have you found speedwise? I seem to get about the same transfer
> > > > > rate off a 160GB disk than off a striped pair of 80s, as the 160 is
> > > > > inherently faster. Hence I only stripe if it's cheaper to do so (or
> > > > > impossible not to - like you canot get a 500GB IDE)
> > > >
> > > > Why would the 160 be inherently faster? Or are the 80s older drives?
> > > >
> > > > Drives of the same series should have the same transferrate no matter
> > > > the size.
> > >
> > > Because bigger drives are newer technology, or if they are the same
> > > technology, they have more platters - hence it's almost a raid in itself.
> >
> > That's a common misconception. Drives with multiple platters do not in
> > general perform parallel reads on those platters--while there might on some
> > occasions be a slight performance gain if the data pattern is such that
> > access can be by a head-switch and short seek rather than a long seek, the
> > gain is going to be very, very minor unless the data is carefully
> > structured to match the drive.
>
> Well I've generally found the bigger the faster.
> Probably because when you get a bigger drive it's usually newer technology.
Even in the same model range a bigger drive (x2) is faster in roughly the middle
half of its capacity when it nears the end of the smaller drives capacity as the
smaller drive will be at the slowest zone but the bigger drive is only halfway
at faster zones. The difference maybe as much as 50%.
E.G., on a 80GB and a 160GB drive of same model range that both can do ~60MB/s
at start and 30MB/s at end, a file that is at around the 80GB mark on both drives
transfers at 30MB/s on the smaller drive but transfers at 45MB/s on the bigger one.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
On Fri, 16 Jul 2004 12:43:51 +0200, Folkert Rienstra <see_reply-to@myweb.nl> wrote:
> "Peter Hucker" <hucker@clara.co.uk> wrote in message newspsa69qmwbaiowgp@blue
>> On Thu, 15 Jul 2004 17:47:09 -0400, J. Clarke <jclarke@nospam.invalid> wrote:
>> > Peter Hucker wrote:
>> > > Because bigger drives are newer technology, or if they are the same
>> > > technology, they have more platters - hence it's almost a raid in itself.
>> >
>> > That's a common misconception. Drives with multiple platters do not in
>> > general perform parallel reads on those platters--while there might on some
>> > occasions be a slight performance gain if the data pattern is such that
>> > access can be by a head-switch and short seek rather than a long seek, the
>> > gain is going to be very, very minor unless the data is carefully
>> > structured to match the drive.
>>
>> Well I've generally found the bigger the faster.
>
>> Probably because when you get a bigger drive it's usually newer technology.
>
> Even in the same model range a bigger drive (x2) is faster in roughly the middle
> half of its capacity when it nears the end of the smaller drives capacity as the
> smaller drive will be at the slowest zone but the bigger drive is only halfway
> at faster zones. The difference maybe as much as 50%.
>
> E.G., on a 80GB and a 160GB drive of same model range that both can do ~60MB/s
> at start and 30MB/s at end, a file that is at around the 80GB mark on both drives
> transfers at 30MB/s on the smaller drive but transfers at 45MB/s on the bigger one.
Plus if you put 80GB on an 80GB drive, seeks are up to full distance. 80GB on a 160GB drive (if defragged), seeks are up to half distance.
--
*****TWO BABY CONURES***** 15 parrots and increasing http://www.petersparrots.com
93 silly video clips http://www.insanevideoclips.com
1259 digital photos http://www.petersphotos.com
Served from a pentawatercooled dual silent Athlon 2.8 with terrabyte raid
"These stretch pants come with a warranty of one year or 500,000 calories... whichever comes first."
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Geez, took me a whole day to respond. This is very tricky stuff.
"Marc de Vries" <marcdevries@geen.spam.zonnet.nl> wrote in message news
83ff0ditafbqmigvs95bn36vuu0bj3ddk@4ax.com
> 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.
Yes, you just repeated what you said without explanation.
>
> 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.
So what is 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.
You obviously got that wrong as it was *you* who responded 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.
Yes, as pointless as it is now. You seem to enjoy repeating yourself.
>
> Your remark suggests that there was something wrong to what I said.
Nope, *your* remark suggested that there was something wrong to what *I* said.
> (especially when someone who doesn't know how raid works reads it).
I second that.
> So I had to make it clear for everyone that it does apply to Raid5.
Which is a striped array, like I said.
>
> > 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.
Ah yeah, and now it is my fault how this thread suddenly grew from
a 4kB post to a 10kB post to an 18kB post. Who are you trying to kidd.
>
> If you had said that the transfer rate increase doesn't apply to Raid1
> you would have added something sensible.
Well, apparently it would have been clearer for you.
Most people that read the replies would just see
> > > > That is for striped arrays.
> > > > That is for mirrored arrays
and conclude that the one excludes the other.
> Although it still doesn't apply to what we are talking about here: Raid5.
And now you contradicted yourself when you earlier said that it does.
>
> > > > > 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.
Not for mirrors, no. That one is crystal clear.
> I've explained it to you in the past, but you didn't listen then,
It is not uncommon that people run away from a conversation when so-
meone maintains that the earth is flat and the posts grow exponentially.
> so I will not explain it to you again.
Well you did it anyway, at the end.
>
> A more detailed explanation than I have already given in the thread
> here isn't interesting for the discussion.
Yes it is when the assumptions are wrong.
> 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.
That is the standard troll response when they have been caught.
Actually, I do. You use official words that have a specific meaning and
then you (mis)use them for something else, changing that official meaning.
>
> The seektime for reading a single file from the array stays the same
> as on a single disk.
There you go.
Seektime is the time spent to seek from a specific or random position to
a specific or random block, not time spent seeking in the total retrieval
time of a file.
Minimum seektime, maximum seektime and average seektime are specific
to a (=one) block, not a file. It's a measurement range for a single seek.
And apart from that you mean access time, not seektime.
You misuse the terms. If you want to convey something, use the proper
terms or at least refrain from using improper terms.
> But total time *spend on seeks*
Now you got it.
> when you read many files on the array is much lower than when you
> read many files on a single disk.
Though you got that wrong. When you read from a striped array you
read in parallel (and at higher combined transfer rate).
When you read from a single disk you read in a serial manner.
The fact that you can only read the second file after the first one
does not constitute a seek.
Now if you read in parallel fashion from a single disk by issuing parallel
IOs for several files at once, that then get serialized and scattered, you
may have a point.
Reading several sequential files at once may result in random(ish) retrieval
of said files if they are bigger than the maximum IO size, and the smaller
the IO size or the bigger the files, the more accesses (seeks+latencies) are
possibly involved.
On the other hand, if the disk supports tagged queueing (or the OS does
some reordering in the system queue) the queue will get reordered and
the files read one after the other without that overdose of extra seeks.
>
> I've explained in simple terms how that works.
Far too simple when you leave out some essentials.
Then it is not really an explanation.
> In my opinion perceived seektime is a good way to talk about this
> lower total seektime.
It's confusing and on top of that, it's wrong.
> But if you know a better word I welcome you to tell me what
> word I should use.
Increased transfer rate, because that is what lower seektimes or the
absence of unnecessary accesses is leading to.
And the performance gain is twofold as parallel transfer also increases
performance. What contributes the most depends on the IO size.
>
> The facts are
Are they? See later. *
> that the total seektime
I would call that 'aggregated seektime' if you must use the word "seektime".
> is reduced
> so I have a performance gain.
That's not disputed, now is it.
But performance constitutes the number of data transferred per time
unit and that's MB/s. Both STR and access time play a role in that.
> So there are no false assumptions.
Then it is not perceived.
>
> > 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.
Users get it.
They just notice how their files transfer faster and that is what increa-
sed performance means to them, more MB/s aka better transfer rate.
They don't give a damn about milliseconds access time or IO/s.
>
> 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.
You can't increase transfer rate, transfer rate is what you get. You can
influence it by better access time and better sustained transfer rate.
>
> But because you can read multiple files at the same time you are effec-
> tively reducing the seektime
*
No, you are reintroducing parallel reading of files that by themselfs
wouldn't have parallel read because they are to small to fill a stripe.
> and are creating a huge performance gain.
Actually you are pulling a long nose to the operating system that intro-
duced all those seeks in the first place by cutting files up in small IO
and then parallelized them.
Actually you are taking your performance back again that was trashed
by the OS in the first place.
>
> Again a simple example.
Oh, where is the first one?
> I can read two small files at once from the array.
That depends.
> 90% of the time T to read that small file is spend on the seektime.
So we are talking 52MB/s, 12 ms access, 13 ms total transfer time
amounts to 4kB files. So we are talking *VERY* small file.
> Now I read two of those files from a single disk.
> The total time spend is: 2 x (0,9 x T + 0,1 x T) = 2T
The transfer rate is 1/13 * 52MB/s = 4MB/s
> Now I quadruple the transferrate of that disk by putting them in a
> raid array.
So let's assume 4 drive Raid0 then.
> Now for 10% of time T I need only a quarter of the time.
If your stripe size is 4K or less.
>
> Now the total time needed is 2 x (0.9 x T + 0.025 x T) = 1.85 T
I believe that that is not entirely correct as you have now two
different values of T in the same equation, but that aside.
>
> So although I made a huge transferrate increase
No, you didn't, you made a huge STR increase.
> I got only a very small performance gain.
Yes, you got only a small *transferrate* gain.
>
> Now I don't do anything about the transferrate of the disk when I put
> it in a raid array.
Of course, you do. But let's go with it for the moment.
And let's assume 2 drive Raid0.
> I just read both files at the same time, as I can do with larger arrays.
Or with any (striped) array. Let's assume you meant larger number of
drives in the array instead of larger size array. It's not the size of
the array but the size of the stripe that makes it possible or not.
And it depends on where in a stripe these files sit.
With that 4KB they may well sit on a single drive but there's a 50-50
chance with a 2 drive array that they sit on the same one.
> (or with a raid1 array)
Now that makes sense.
>
> Now the total time to read both files is:
> 1 x (0,9 x T + 0,1 x T) = 1T
If you are lucky.
The transfer rate per file is still 4kB/s though.
>
> Now I have made a 100% performance gain
Oh? Where is it when the transfer rate per file is still 4kB/s?
> and it is not because of the transferrate.
Yes, because of the transferrate. Just not because of the STR.
If both files were destined for you then you have doubled the
transfer rate for the total of them (8kB/s). *
> 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.
(Or halve the transfer time, i.e. double the transfer rate).
Yes, but only 50% of the time and for files smaller to equal than half
the stripe size or more generally stripe divided by number of drives.
>
> It's not an actual seektime decrease, but real-life performance
> figures of the array make it look like the seektime has been halved.
No, small files aren't read in parallel and transfer at single drive speeds.
Combining small files restores parallel reading and aggregating back
transfer rate.
> So the array behaves as if the seektime has halved,
No, it behaves like the files are bigger and behave like striped instead
of some form of JBOD. and transfer time has halved.
> and thus I state that the "perceived" seektime has decreased.
No, combined transfer rate has increased because transfer time was 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.
Yes, you can. When you allow your "perceived", then you have to allow
my "perceived" as well when both are wrong.
>
> Simply because a perceived seektime decrease corresponds well with the
> actual performance figures and an increased transferrate does not.
And that is not what I said.
Transfer rate (rate of transfer, MB/s) IS performance.
>
> 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.
Again, I know what you mean to say but thats not what you say.
>
> A perceived seektime does work well 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.
Nope.
What you see is what you see but it not what you contribute it to.
Combining files brings back striping (parallel reading) to small files.
>
> > > > > 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.
Well, then we must have something in common because I am under the
exact same impression that you don't want to understand what I am
saying. Part of the confusion I believe is just in the language and
definitions of words.
>
> > > 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.
You were and I changed it to mirrors.
Generally mirrors have better access time because one drive is always
closer to the data than the other drive so average latency on a mirror
is less (less than 1/2 rev) than on a single drive.
That's why I said "on 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.
Now you've lost me again. Assuming that the implementation does allow it,
that is where it works all the time irrespective of number of drives or stripe
sizes or what ever.
>
> Marc
Please mind
You are about to answer a thread that has been inactive for more than 6 months.
If you still wish to proceed, please ensure that your posting is original and does not duplicate or overlap any prior responses to this thread.
