Geez, took me a whole day to respond. This is very tricky stuff.
Marc de Vries said:
Marc de Vries said:
[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.
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'.
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.
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 seeand 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.
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.
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.
Are they? See later. *
I would call that 'aggregated seektime' if you must use the word "seektime".
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 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.
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.
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.
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
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.
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.
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.
