On Thu, Feb 07, 2002 at 03:08:49AM +0200, Cajoline wrote:
> Hello again.
> I am just writing to inform you about the results of some tests I ran
> today, since, as I noticed, you wrote that feedback from our experience
> with raidreconf is welcome.
> Even though this is getting boring, I must note again that your answers
> have been very helpful and enlightening :)
No problem, thanks :)
...
>
> Thanks, that clears up everything. I tried moving some devices around,
> to different slots, and so far it only worked some times, while other
> times it failed, the raid driver couldn't find the partition that was on
> the moved disk. Moving the drives onto the same channel (from one drive
> per channel per controller) worked, as well as switching them around
> between channels and master/slave on the same channel. However,
> strangely enough, moving the drive from the onboard ide controller to
> one of the Promise controllers failed. The kernel would find the drive
> and the partition on it, but the raid driver wouldn't. I thought this
> had to do with the sequence of the drives or something close to that,
> but now I understand it is probably a problem related to the controllers
> and the chipsets.
Do you have the promise controller driver compiled into the kernel, or
is it a loadable module ?
It sounds like a bug, nonetheless.
...
> I did another raidreconf test today, this time I used an array of two 30
> gb partitions, and tried to add another 50 gb partition to it.
> Raidreconf estimated it would take somewhat over 7 hours to complete. I
> let it run to the end. I monitored the process through top/ps most of
> the time. I'm not sure if this is accurate, but it never reported using
> more than 6% of cpu time and about 7% of memory (i.e. about 15 mb) at
> any time while it was running. Finally, it finished in 3h7m4s, which is
It will print out a message saying how much physical memory it detected
in the machine ("Detected XXX KB of physical..."), and a message saying
how many outstanding requests it will buffer ("A maximum of XXX outstanding
requsts is allowed").
raidreconf should use approx. 1/3 of the physical memory in the machine,
so 7% seems a little low...
> quite less than the estimate it was giving most of the time.
Indeed.
> So, if it took 3 hours to add 50 gb to a 60 gb array, a rough
> calculation says it will take about 19 hours to add 100 gb to a 380 gb
> array, which is close to your calculations, yet still lower.
My calculations was a very rough estimate - perhaps you will see a
performance degradation when moving to larger partitions (because average
seek time will be slightly higher), but I'm not sure if that is going
to be noticable at all.
> I should also note that in this test, all 3 partitions used were on the
> same disk, so that should probably not speed up things, if not slow down
> the process. I am really beginning to think (and hope) I can live with
It will probably slow down the process, yes.
> that if it only takes about 20 hours to do it :) that is, until you grow
> up and write that kernel patch that will allow raidreconf to work
> online, on an active md0 :)
;)
>
> On another note, I also noticed I currently use a 32 kb chunk-size,
> which is rather small for such a large array, while it also doesn't seem
> very useful since we don't have such a large number of small files. So I
> thought I should perhaps it would be wise to also convert to a 64 kb
> chunk-size.
> The question is a. is it safe to do such a conversion at the same time
> as adding the new device to the array and b. do you think it may
> severely affect the time it takes for raidreconf to finish?
It *should* be safe. But as you increase the complexity of the operations
that raidreconf has to perform, you increase the chance of hitting a bug
that I don't know about... I would try it, but keep good backups :)
It shouldn't significantly increase the time raidreconf takes to run, as
it does all of it's work in one pass.
>
> After I write this, I will also try running raidreconf for a
> chunk-resize on this now-110 gb array, see how long it takes and report
> tomorrow.
Please let me know about the memory/request numbers
And thanks a lot for the feedback !
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
